一个屌丝靠阿里云逆袭的故事

我是一个屌丝,没读过大学.资深网管.后面自学阿里云完成了从网吧网管到企业运维的转变,我之前在杭州工商大学的红苹果网吧做网管的.后面去过杭州大剧院.数字银行.银联.最后在外资公司待着.一路走来多亏有好心人的帮忙.最近有意转行.直到有一天听说了阿里云大学才知道原来云计算还可以这么玩.立马就报名学习了阿里云大学的四门专业课程.云计算.大数据分析,大数据开发,云计算安全.并且都已经毕业合格了。不光我自己学了我还鼓动我身边的人参加学习.

这段时间云计算导师的指导下,终于完成了教学内容的考试,在此特别感谢我们班级那些认真负责的教服人员,感谢他们半夜11点还在跟我们一起讨论,因此才有了以下这个文章,大家为我奉献,我为大家奉献,希望同行一起交流,包括已经入行的和正在学习的人.因为接触云计算不多。如果还有表达错误的,请多多担待.

前言

无论是传统的自建idc还是当前流行的上云,都避免不了在业务突发增长,在业务爆发增长的情况下.公司对业务可用性以及稳定性的追求,对于许多运维人员来说都是困扰.业务量少.体现不出价值.业务量大怕自己没经验.幸好有阿里云的云计算课程.教会了我们很多技术手段来应对业务的爆发性增长,而对于自建机房来说,这是他们心痛的,没有相应完好的技术架构来应对业务的爆发增长.


我去过一家保险公司.20多个开发人员2台ecs.没有业务业务增长.也就不需要横向扩容.2台服务器够用了,这样的架构对于小企业来说是没有什么问题,如果业务爆发增长后我们服务器不够时再买一点,也不在乎那么一点时间和金钱,但是对于依靠互联网增值业务来为公司服务的公司来说是不允许的时间就是金钱呀,如果是你的服务中断了那么老板会跳起来的,你看着办吧。没办法,老板就是那么难伺候,又需要你来给企业节省成本。又需要

你给公司节省成本.这个时候我们的k8s就可以登场了。

那么.什么时候我们才需要用到k8s技术呢?比如说游戏服务器.比如淘宝双十一的这些访问量比波动比较大的业务,可能前一秒钟有1000人,再访问下一秒钟就突破2000w人次了。再这样访问量的情况下面总不可能你让我手工一台上服务器吧,要这样的话就不如关门大吉了。所以我们迫切需要运维自动化

阿里云的edas服务控制台提供自建k8s服务.


技术演示,我们以一台服务器来做简单的运行演示,首先我们创建一台网站服务器的IP v47.101.181.321。

并访问一下页面是否正常。


好的,现在一切正常,接下来我们给应该给这些服务器做一个镜像

这样后面的话docker调用的时候就会用到,用这个镜像来做,docker说我们在创建自定义服务器中输入镜像名称,写好备注后直接点击创建。

dockerfile命名如下

--------------

FROM node:8

WORKDIR /opt/apps/p8h_backend

COPY package*.json ./

RUN npm install

COPY . .

CMD ["node", "server.js"]

--------------

docker build -f Dockerfile.esbjm ./ -t jim/p8h-esb-qa:1

运行命令就可以生成一个docker images的镜像. 创建好后.

创建好后,我们在k8s上创建相应的服务.

esb企业业务总线

-------------------

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

    name: esb-p8h-esb-dev

    annotations:

      nginx.ingress.kubernetes.io/proxy-body-size: 600M

spec:

    minReadySeconds: 60

    progressDeadlineSeconds: 600

    replicas: 1

    revisionHistoryLimit: 10

    strategy:

      rollingUpdate:

        maxSurge: 2

        maxUnavailable: 0

      type: RollingUpdate

    template:

      metadata:

        labels:

          app: aesbp8h-esb-dev

      spec:

        imagePullSecrets:

        - name: myregistrykey

        containers:

        - name: esbp8h-esb-dev

          image: jim/p8h-esb-qa:1

          resources:

            requests:

              memory: "1000Mi"

              cpu: "200m"

          ports:

          - containerPort: 80

          env:

          - name: SERVER_TYPE

            value: "esb"

          - name: REDIS_HOST

            value: "prod-redis"

          - name: BUILD_ENV

            value: "prod"

          - name: PORT

            value: "80"

---

#mbl移动api

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

    name: mbl-p8h-esb-dev

spec:

    minReadySeconds: 60

    progressDeadlineSeconds: 600

    replicas: 1

    revisionHistoryLimit: 10

    strategy:

      rollingUpdate:

        maxSurge: 2

        maxUnavailable: 0

      type: RollingUpdate

    template:

      metadata:

        labels:

          app: amblp8h-esb-dev

      spec:

        imagePullSecrets:

        - name: myregistrykey

        containers:

        - name: mblp8h-esb-dev

          image: jim/p8h-esb-qa:1

          resources:

            requests:

              memory: "1000Mi"

              cpu: "200m"

          ports:

          - containerPort: 80

          env:

          - name: SERVER_TYPE

            value: "mbl"

          - name: REDIS_HOST

            value: "prod-redis"

          - name: BUILD_ENV

            value: "prod"

          - name: PORT

            value: "80"

---

#webapi

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

    name: web-p8h-esb-dev

spec:

    minReadySeconds: 60

    progressDeadlineSeconds: 600

    replicas: 1

    revisionHistoryLimit: 10

    strategy:

      rollingUpdate:

        maxSurge: 2

        maxUnavailable: 0

      type: RollingUpdate

    template:

      metadata:

        labels:

          app: awebp8h-esb-dev

      spec:

        imagePullSecrets:

        - name: myregistrykey

        containers:

        - name: webp8h-esb-dev

          image: jim/p8h-esb-qa:1

          resources:

            requests:

              memory: "1000Mi"

              cpu: "200m"

          ports:

          - containerPort: 80

          env:

          - name: SERVER_TYPE

            value: "web"

          - name: REDIS_HOST

            value: "prdo-redis"

          - name: BUILD_ENV

            value: "prod"

          - name: PORT

            value: "80"

-------------------

写好这个app.yml

运行

rancher kubectl apply -f ~/app.yml

就在k8s上运行好这些业务了.然后我们再创建一个hpa业务伸缩实例.实例中。我们根据CPU时间占用率来进行自动伸缩,默认为10,最大为100。当docker cpu利用率超过50%时新建新的容器.其他如果不需要改动,就设置成默认。

-------------

rancher kubectl autoscale deployment esb-p8h-esb-dev --min=1 --max=10 --cpu-percent=80

-------------

下面我们来测试设置的k8s自动伸缩实例是否正常生效?我们来运行一个结jmeter的压力测试程序。

未生效前我们看到现在k8s集群只有一台服务器在工作。



生效之后,我们看到已经有两台服务器在工作了。



我们再回到ecs控制台,来看一下服务器的状态,可以看到之前的实例中只是cpu有些波动.并不需要新购买ecs服务器.但对于我们用户来说.业务的负载能力又是真实提升了.而且我们的业务可以混合部署.比如我们可以买1台200m带宽特价的服务器demo.这个服务器上的流量费用特别便宜.然后调用api购买一个竞价实例mbl-竞价1.这个服务器的cpu内存单价特别低.这样的话便宜的价格.高效的服务器性能.两全其美.老板当初教育我.运维人员就是互联网时代的企业会计.需要为企业开源节流.一个好的运维.公司的隐形支出至少可以节省一半以上.这个就是我的经验.





总结在这篇文章中,我们一起学习并讨论了什么是k8s,什么情况下使用k8s,最后展示了如何配置和使用k8s。

总结如下,

1.k8s是一个虚拟化的企业云平台服务.可以对阿里云提供的ecs资源进行二次划分.

2.k8s在服务压力大的情况下会自动伸缩.把不需要的服务关闭掉.把需要的服务进行扩容.以应对高峰期的访问.

3.k8s有简单的特点,不需要有过多的操作技术就可以简单使用。

你可能感兴趣的:(一个屌丝靠阿里云逆袭的故事)