原生Kubernetes容器云平台运维

案例——原生Kubernetes容器云平台运维

 

 

一、案例目标

(1)了解Node节点的隔离、恢复与扩容。

(2)了解Pod的调度方式。

(3)了解Kubernetes应用的滚动升级。

二、案例分析

1.规划节点

主机名

节点

master

master节点

node

node节点

node2

新增节点

2.基础准备

Kubernetes集群已部署完成。

三、案例分析

1. Node的隔离与恢复

(1)隔离Node

在硬件升级、硬件维护等情况下,需要将某些Node隔离。使用kubectl cordon <node_name>命令可禁止Pod调度到该节点上,在其上运行的Pod并不会自动停止,管理员需要手动停止在该Node上运行的Pod。

 

查看Node的状态,可以观察到在node的状态中增加了一项SchedulingDisabled,对于后续创建的Pod,系统将不会再向该Node进行调度。

 

(2)恢复Node

通过kubectl uncordon命令可完成对Node的恢复。

 

可以看到Node节点已恢复调度,允许Pod调度到该节点上。

(3)驱逐Node

通过kubectl drain <node>命令可实现对node节点的驱逐,该命令会删除该节点上的所有Pod(DaemonSet除外),在其他Node上重新启动它们。

2. Node扩容

在实际生产系统中会经常遇到服务器容量不足的情况,这时就需要购买新的服务器,然后将应用系统进行水平扩展来完成对系统的扩容。

在Kubernetes集群中,对于一个新Node的加入是非常简单的。可以在Node节点上安装Docker、Kubelet和kube-proxy服务,然后将Kubelet和kube-proxy的启动参数中的Master URL指定为当前Kubernetes集群master的地址,最后启动这些服务。基于Kubelet的自动注册机制,新的Node将会自动加入现有的Kubernetes集群中

 

Kubernetes Master在接受了新Node的注册之后,会自动将其纳入当前集群的调度范围内,在之后创建容器时,就可以向新的Node进行调度了。

(1)基础环境配置

部署集群

(2)配置Kubernetes Yum源

所有节点配置Kubernetes源。

 

(3)安装工具

Kubelet负责与其他节点集群通信,并进行本节点Pod和容器生命周期的管理。Kubeadm是Kubernetes的自动化部署工具,降低了部署难度,提高效率。Kubectl是Kubernetes集群管理工具。

所有节点安装Kubernetes工具并启动Kubelet。

# yum install -y kubelet-1.14.1 kubeadm-1.14.1 kubectl-1.14.1

# systemctl enable kubelet && systemctl start kubelet

// 此时启动不成功正常,后面初始化的时候会变成功

(4)生成Token

Kubernetes默认的Token有效期为24小时,当过期之后,该Token就不可用了。登录master节点,生成一条永久有效的Token。

 

(5)获取hash值

登录master节点,获取CA证书sha256编码hash值。

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

 

(6)加入集群

登录node2节点,使用kubeadm join命令加入集群。

kubeadm join 10.24.2.10:6443 --token nhbdlm.n4x86kxi5z2ugg2l  --discovery-token-ca-cert-hash sha256:

(7)查看集群节点

登录master节点,查看集群所有节点状态。

3. Pod动态扩容和缩放

在实际生产系统中,经常会遇到某个服务需要扩容的场景,也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。此时可以利用kubectl scale deployment命令来完成这些任务。

(1)运行Deployment

以Nginx Deployment为例,已定义的最初副本数量为1。

[root@master ~]# kubectl run nginx --image=nginx:latest

kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.

deployment.apps/nginx created

[root@master ~]# kubectl get pods

NAME                    READY   STATUS    RESTARTS   AGE

nginx-ccb467dc5-jlr4c   1/1     Running   0          40s

(2)Pod扩容

通过执行下面的命令将Nginx Deployment控制的Pod副本数量从初始的1更新为5。

[root@master ~]# kubectl scale deployment nginx --replicas=5

deployment.extensions/nginx scaled

执行kubectl get pods命令来验证Pod的副本数量增加到5。

[root@master ~]# kubectl get pods

NAME                    READY   STATUS    RESTARTS   AGE

nginx-ccb467dc5-2f6n2   1/1     Running   0          34s

......

(3)Pod缩容

将--replicas设置为比当前Pod副本数量更小的数字,系统将会“杀掉”一些运行中的Pod,即可实现应用集群缩容。

[root@master ~]# kubectl scale deployment nginx --replicas=2

deployment.extensions/nginx scaled

[root@master ~]# kubectl get pods

NAME                    READY   STATUS    RESTARTS   AGE

nginx-ccb467dc5-bl4jp   1/1     Running   0          2m50s

nginx-ccb467dc5-jlr4c   1/1     Running   0          5m21s

4. 将Pod调度到指定的Node

Kubernetes的Scheduler服务(kube-scheduler进程)负责实现Pod的调度,整个调度过程通过执行一系列复杂的算法最终为每个Pod计算出一个最佳的目标节点,这一过程是自动完成的,用户无法知道Pod最终会被调度到哪个节点上。有时可能需要将Pod调度到一个指定的Node上。此时,可以通过Node的标签(Label)和Pod的nodeSelector属性相匹配,来达到上述目的。

(1)添加Label

Label(标签)作为用户可灵活定义的对象属性,在已创建的对象上,仍然可以随时通过kubectl label命令对其进行增加、修改、删除等操作。使用kubectl label给node打标签的用法如下:

# kubectl label nodes <node-name> <label-key>=<label-value>

下面的示例,为node打上一个project=gcxt的标签。

[root@master ~]# kubectl label nodes node project=gcxt

node/node labeled

如果想删除Label,只需要在命令行最后指定Label的key名,并加一个减号即可。

[root@master ~]# kubectl label node node project-

node/node labeled

(2)调度Pod到指定Node节点

在Pod中加入nodeSelector定义,示例如下。

[root@master ~]# cat nginx.yaml

apiVersion: v1

kind: ReplicationController

metadata:

  name: memcached-gcxt

  labels:

    name: memcached-gcxt

spec:

  replicas: 1

  selector:

    name: memcached-gcxt

  template:

    metadata:

      labels:

        name: memcached-gcxt

    spec:

      containers:

      - name: memcached-gcxt

        image: memcached

        command:

        - memcached

        - -m 64

        ports:

        - containerPort: 11211

      nodeSelector:

        project: gcxt

运行kubectl create -f命令创建Pod,scheduler就会将该Pod调度到拥有project=gcxt标签的Node上去。

[root@master ~]# kubectl create -f nginx.yaml

replicationcontroller/memcached-gcxt created

查看Pod。

[root@master ~]# kubectl get pods -owide

NAME                   READY   STATUS    RESTARTS   AGE   IP          NODE   NOMINATED NODE   READINESS GATES

memcached-gcxt-hdt5x   1/1     Running   0          14s   10.24.9.2   node   <none>           <none>

可以看到,Pod已成功调度到指定的Node节点。

这种基于Label标签的调度方式灵活性很高,比如,可以把一组Node分别贴上“开发环境”、“测试环境”、“生产环境”这3组标签中的一种,此时一个Kubernetes集群就承载了3个环境,这将大大提高开发效率。

注意:如果指定了Pod的nodeSelector条件,且集群中不存在包含相应标签的Node时,即使还有其他可供调度的Node,这个Pod也最终会调度失败。

5. 应用滚动升级

当集群中的某个服务需要升级时,需要停止目前与该服务相关的所有Pod,然后重新拉取镜像并启动。如果集群规模比较大,这个工作就变成了一个挑战。如果采取先全部停止,然后逐步升级的方式,会导致较长时间的服务不可用。Kubernetes提供了rolling-update(滚动升级)功能来解决上述问题。

滚动升级通过执行kubectl rolling-update命令一键完成,该命令创建了一个新的Deployment,然后自动控制旧的Deployment中的Pod副本数量逐渐减少到0,同时新的Deployment中的Pod副本数量从0逐步增加到目标值,最终实现了Pod的升级。

注意:系统要求新的Deployment需要与旧的Deployment在相同的命名空间(Namespace)内,即不能把别人的资产偷偷转移到自家名下。

下面的示例在第一次部署时使用httpd:2.2.31,然后使用滚动升级更新到httpd:2.2.32。

(1)启动Deployment

定义httpd.yaml文件。

[root@master ~]# cat httpd.yaml

apiVersion: apps/v1beta1

kind: Deployment

metadata:

  name: httpd

spec:

  replicas: 3

  template:

    metadata:

      labels:

        run: httpd

    spec:

      containers:

        - name: httpd

          image: httpd:2.2.31

          ports:

            - containerPort: 80

启动Deployment。

[root@master ~]# kubectl create -f httpd.yaml

deployment.apps/httpd created

[root@master ~]# kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE

httpd-5ddb558f47-46tf5   1/1     Running   0          49s

httpd-5ddb558f47-5dg96   1/1     Running   0          49s

httpd-5ddb558f47-672sk   1/1     Running   0          49s

查看Deployment。

[root@master ~]# kubectl get deployments httpd -o wide

NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR

httpd    3/3      3           3        93s    httpd     httpd:2.2.31  run=httpd

可以看到,IMAGES为httpd:2.2.31。

(2)滚动升级

把配置文件中的httpd:2.2.31改为httpd:2.2.32,再次启动。

[root@master ~]# cat httpd.yaml

apiVersion: apps/v1beta1

kind: Deployment

metadata:

  name: httpd

spec:

  replicas: 3

  template:

    metadata:

      labels:

        run: httpd

    spec:

      containers:

        - name: httpd

          image: httpd:2.2.32    //将2.2.31更改为2.2.32

          ports:

            - containerPort: 80

[root@master ~]# kubectl apply -f httpd.yaml

deployment.apps/httpd configured

再次查看Deployment。

[root@master ~]# kubectl get deployments httpd -o wide

NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR

httpd    3/3      3       3            7m53s   httpd   httpd:2.2.32  run=httpd

查看Deployment的详细信息。

[root@master ~]# kubectl describe deployment httpd

…...

Events:

  Type    Reason             Age   From                   Message

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

  Normal  ScalingReplicaSet  22m   deployment-controller  Scaled up replica set httpd-5ddb558f47 to 3

  Normal  ScalingReplicaSet  15m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 1

  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 2

  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 2

  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 1

  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 3

  Normal  ScalingReplicaSet  13m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 0

上面的日志信息就描述了滚动升级的过程:

① 启动一个新版Pod。

② 把旧版Pod数量降为2。

③ 再启动一个新版,数量变为2。

④ 把旧版Pod数量降为1。

⑤ 再启动一个新版,数量变为3。

⑥ 把旧版Pod数量降为0。

这就是滚动的意思,始终保持副本数量为3,控制新旧Pod的交替,实现了无缝升级。

(3)回滚

kubectl apply每次更新应用时,kubernetes都会记录下当前的配置,保存为一个revision,这样就可以回滚到某个特定的版本。

创建3个配置文件,内容中唯一不同的就是镜像的版本号。

httpd.v1.yaml:

[root@master ~]# cat httpd.v1.yaml

apiVersion: apps/v1beta1

kind: Deployment

metadata:

  name: httpd

spec:

  revisionHistoryLimit: 10  # 指定保留最近的几个revision

  replicas: 3

  template:

    metadata:

      labels:

        run: httpd

    spec:

      containers:

        - name: httpd

          image: httpd:2.2.16

          ports:

            - containerPort: 80

httpd.v2.yaml:

[root@master ~]# cat httpd.v2.yaml

apiVersion: apps/v1beta1

kind: Deployment

metadata:

  name: httpd

spec:

  revisionHistoryLimit: 10  # 指定保留最近的几个revision

  replicas: 3

  template:

    metadata:

      labels:

        run: httpd

    spec:

      containers:

        - name: httpd

          image: httpd:2.2.17

          ports:

            - containerPort: 80

httpd.v3.yaml:

[root@master ~]# cat httpd.v3.yaml

apiVersion: apps/v1beta1

kind: Deployment

metadata:

  name: httpd

spec:

  revisionHistoryLimit: 10  # 指定保留最近的几个revision

  replicas: 3

  template:

    metadata:

      labels:

        run: httpd

    spec:

      containers:

        - name: httpd

          image: httpd:2.2.18

          ports:

            - containerPort: 80

部署Deployment。

[root@master ~]# kubectl apply -f httpd.v1.yaml --record

deployment.apps/httpd configured

[root@master ~]# kubectl apply -f httpd.v2.yaml --record

deployment.apps/httpd configured

[root@master ~]# kubectl apply -f httpd.v3.yaml --record

deployment.apps/httpd configured

--record的作用是将当前命令记录到revision中,可以知道每个revision对应的是哪个配置文件。

查看Deployment。

[root@master ~]# kubectl get deployments -o wide

NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR

httpd    3/3        1           3      31m      httpd   httpd:2.2.18 run=httpd

查看revision历史记录。

[root@master ~]# kubectl rollout history deployment httpd

deployment.extensions/httpd

REVISION  CHANGE-CAUSE

1         <none>

2         <none>

3         kubectl apply --filename=httpd.v1.yaml --record=true

4         kubectl apply --filename=httpd.v2.yaml --record=true

5         kubectl apply --filename=httpd.v3.yaml --record=true

CHANGE-CAUSE即-record的结果。

执行如下操作,回滚到指定版本revision 1。

[root@master ~]# kubectl rollout undo deployment httpd --to-revision=1

deployment.extensions/httpd rolled back

[root@master ~]# kubectl get deployments -o wide

NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR

httpd    3/3       3            3      35m     httpd    httpd:2.2.31 run=httpd

再次查看Deployment可以看到httpd版本已经回退了。

查看revision历史记录,可以看到revision记录也发生了变化。

[root@master ~]# kubectl rollout history deployment httpd

deployment.extensions/httpd

posted @ 2021-07-09 08:15  哆啦丢了梦  阅读(434)  评论(0编辑  收藏  举报