deployment管理pod

发表于 分类于 ，
CKS学习笔记Deployment部分：

deployment管理pod

软件版本
docker最新版
kubernetes1.23.1
calico3.25
节点IP系统功能CPU内存硬盘
node110.80.10.1centos7.9k8s-master4核心8GB20GB
node210.80.10.2centos7.9k8s-node4核心8GB20GB

deployment概述：

deployment是kubernetes中最常用的资源对象，为replicaset和pod的创建提供了一种声明式的定义方法，在deployment对象中描述一个期望的状态，deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个deployment控制器会创建一个新的replicaSet控制器，通过replicaset创建pod，删除deployment控制器，也会删除deployment控制器下对应的replicaset控制器和pod资源。

使用deployment而不直接创建replicaset是因为deployment对象拥有许多replicaset没有的特性，例如滚动升级和回滚。

deployment工作原理：

deployment可以使用声明式定义，直接在命令行通过纯命令的方式完成对应资源版本的内容的修改，也就是通过打补丁的方式进行修改。deployment能提供滚动式自定义自控制的更新。对deployment来讲，我们在实现更新时还可以实现控制更新节奏和更新逻辑。

通过deployment对象，你可以轻松的做到以下事情：

  • 创建replicaset和pod。

  • 滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）。

  • 平滑地扩容和缩容。

  • 暂停和继续deployment。

node1

查看deployment字段：

1
# kubectl explain deployment

deployment创建web：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# mkdir /root/deployment && cd /root/deployment
# vim deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
  namespace: default
  labels:
    name: myapp-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
1
2
3
4
# kubectl apply -f deploy-demo.yaml
# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   2/2     2            2           38s

  • NAME：列出名称空间中deployment的名称。

  • READY：显示deployment有多少副本数。它遵循ready/desired的模式。

  • UP-TO-DATE：显示已更新到所需状态的副本数。

  • AVAILABLE：显示你的可以使用多少个应用程序副本。

  • AGE：显示应用程序已运行的时间。

访问测试：

1
2
3
4
5
6
 kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE    IP             NODE        NOMINATED NODE   READINESS GATES
myapp-v1-5557789c4d-h5nlk   1/1     Running   0          107s   10.244.36.88   k8s-node1   <none>           <none>
myapp-v1-5557789c4d-msw7w   1/1     Running   0          107s   10.244.36.89   k8s-node1   <none>           <none>
# curl -s 10.244.36.88 | grep background-color
      background-color: blue;

deployment扩容：

1
2
3
# vim deploy-demo.yaml
# 9行，修改配置
  replicas: 3
1
2
3
4
# kubectl apply -f deploy-demo.yaml
# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   3/3     3            3           3m3s

deployment缩容：

1
2
3
# vim deploy-demo.yaml
# 9行，修改配置
  replicas: 2
1
2
3
4
# kubectl apply -f deploy-demo.yaml
# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   2/2     2            2           3m33s

deployment更新，默认更新逻辑是25%：

1
2
# kubectl describe deployment myapp-v1 | grep RollingUpdateStrategy
RollingUpdateStrategy:  25% max unavailable, 25% max surge
1
2
3
# vim deploy-demo.yaml
# 22行，修改配置
        image: janakiramm/myapp:v2
1
2
3
4
5
6
7
# kubectl apply -f deploy-demo.yaml
# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
myapp-v1-674dc5bd49-cxkxd   1/1     Running   0          29s   10.244.36.92   k8s-node1   <none>           <none>
myapp-v1-674dc5bd49-g4zjv   1/1     Running   0          28s   10.244.36.93   k8s-node1   <none>           <none>
# curl -s 10.244.36.92 | grep background-color
      background-color: green;

deployment查看历史版本：

1
2
3
4
5
# kubectl rollout history deployment myapp-v1
deployment.apps/myapp-v1 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

deployment回滚版本1：

1
2
3
4
5
6
7
# kubectl rollout undo deployment myapp-v1 --to-revision=1
# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
myapp-v1-5557789c4d-lnn54   1/1     Running   0          20s   10.244.36.95   k8s-node1   <none>           <none>
myapp-v1-5557789c4d-n5l8g   1/1     Running   0          21s   10.244.36.94   k8s-node1   <none>           <none>
# curl -s 10.244.36.95 | grep background-color
      background-color: blue;
1
# kubectl delete -f deploy-demo.yaml

自定义滚动更新策略：

1
2
3
4
5
6
7
8
9
10
11
12
13
maxSurge和maxUnavailable用来控制滚动更新的更新策略
取值范围
数值
1. maxUnavailable: [0, 副本数]
2. maxSurge: [0, 副本数]
注意：两者不能同时为0。
比例
1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；
注意：两者不能同时为0。
建议配置
1. maxUnavailable == 0
2. maxSurge == 1

deployment资源清单详解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
apiVersion: apps/v1
kind: Deployment 
metadata:
  name: portal
  namespace: ms 
spec:
  replicas: 1
  selector:
    matchLabels:
      project: ms
      app: portal
  template:
    metadata:
      labels:
        project: ms 
        app: portal
    spec:
      containers:
      - name: portal
        image: portal:v1
        imagePullPolicy: Always
        ports:
          - protocol: TCP
            containerPort: 8080 
        resources: # 资源配额
          limits: # 资源限制，最多可用的cpu和内存
            cpu: 1
            memory: 1Gi
         requests: # 最少需要多少资源才可以运行pod
            cpu: 0.5
            memory: 1Gi
        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 10
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 10

livenessprobe：存活性探测

用于判断容器是否存活，即pod是否为running状态，如果livenessprobe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略是否重启。如果一个容器不包含livenessprobe探针，则kubelet认为容器的livenessprobe探针的返回值永远成功。

1
2
3
4
tcpSocket: 
  port: 8080 #检测8080端口是否存在
initialDelaySeconds: 60 #Pod启动60s执行第一次检查
periodSeconds: 10 #第一次检查后每隔10s检查一次

readinessprobe：就绪性探测

有时候应用程序可能暂时无法接受请求，比如pod已经running了，但是容器内应用程序尚未启动成功，在这种情况下，如果没有readinessprobe，则kubernetes认为它可以处理请求了，然而此时，我们知道程序还没启动成功是不能接收用户请求的，所以不希望kubernetes把请求调度给它，则使用readinessprobe探针。

readinessprobe和livenessprobe可以使用相同探测方式，只是对pod的处置方式不同，readinessprobe是将pod ip:port从对应的endpoint列表中删除，而livenessprobe则kill容器并根据pod的重启策略来决定作出对应的措施。

readinessprobe探针探测容器是否已准备就绪，如果未准备就绪则kubernetes不会将流量转发给此Pod。

1
2
3
4
tcpSocket:
  port: 8080
    initialDelaySeconds: 60
    periodSeconds: 10