kubernetes 资源对象

  • kubernets 资源对象
    • k8s 基础应用
    • Pod 生命周期
    • Pod 资源限制
    • deployment
    • daemonset
    • job、cronjob
    • service
    • ingress
    • configmap
    • secret
    • statefulset
    • 授权与认证（RBAC）
    • 准入控制（ResoucesQuta、LimitRange）

1.0 k8s 基础应用

1.1 deploy

1
2
// 空跑 deploy def-www 资源来获取模版
# kubectl create deploy default-www --image=nginx --replicas=3 --dry-run=client -o yaml

upload successful

1.2 pod 镜像拉取策略

  • imagePullPolicy: 容器的镜像拉取策略:
    • IfNotPresent: 本地有镜像则使用本地镜像，本地不存在则拉取镜像 (默认)
    • Always: 每次都会尝试拉取镜像
    • Never: 永不拉取，如果镜像已经在本地，kubelet 会尝试使用镜像启动容器；否则,会启动失败
1
2
3
4
5
6
7
8
9
10
11
...
    spec:
      containers:
      - name: demo-container                           # 容器的名称
        image: harbor.inadm.com/demo/demoapp:v1.1
        imagePullPolicy: Always                        # 指定容器镜像拉取策略

// 默认镜像拉取策略，当控制器向API服务器提交新的Pod时，集群会满足特定条件时设置 imagePullPolicy 字段
    如果你省略了 imagePullPolicy 字段，并且容器镜像的标签是 :latest ，imagePullPolicy 会自动设置为 Always
    如果你省略了 imagePullPolicy 字段，并且没有指定容器镜像的标签，imagePullPolicy 会自动设置为 Always
    如果你省略了 imagePullPolicy 字段，并且为容器镜像指定了非 :latest 的标签，imagePullPolicy 就会自动设置为 IfNotPresent

1.3 获取私有仓库镜像

1.3.1 创建 secret 认证

  • ImagePullSecrets 拉取私有仓库中的镜像
1
2
3
4
5
6
7
8
9
10
// 将 harbor 的认证信息保存到 k8s secret 资源中
# kubectl create secret docker-registry harbor-registry-auth \
  --docker-server=harbor.inadm.com \
  --docker-username=admin \
  --docker-password=ink8s.comA \
  [email protected]                            # 可选
// 查看 harbor-registry-auth 内容
# kubectl get secret harbor-registry-auth --output=yaml
// harbor-registry-auth 数据转换为可读格式
# kubectl get secret harbor-registry-auth --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode

upload successful

1.3.2 yaml 部署验证

1
2
3
4
5
6
7
8
...
    spec:
      imagePullSecrets:                                    # 指定 harbor 认证凭据
      - name: harbor-registry-auth
      containers:
      - image: harbor.inadc.com/java-demo/java-demo:v1
        name: java-demo
        resources: {}

1.4 传递环境变量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# cat mysql-demo-env.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mysql-demo-env
spec:
  containers:
  - name: mysql-demo-env
    image: mysql:5.7.37
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "inadm.com"
    - name: MYSQL_DATABASE
      value: "testdb"

# kubectl get pod -o wide
# mysql -h 10.1.135.133 -uroot -pinadm.com
MySQL [(none)]>

1.5 自定义容器命令与参数

  • command: 为容器指定启动命令，会覆盖容器启动的默认命令，不指定则默认容器的启动命令
  • args: 为命令提供选项或参数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# cat pod-busybox-command.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-busybox-command
spec:
  containers:
  - name: busy
    image: busybox
    # command: [ "/bin/sh", "-c", "sleep 999999" ]
    command:
    - "/bin/sh"
    - "-c"
    - "sleep 999999"

# kubectl apply -f pod-busybox-command.yaml 
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
// 重点在于颜色 args
# cat redis-leader.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: redis-leader
  labels:
    role: leader
spec:
  containers:
  - name: redis-leader
    image: redis
    ports:
    - containerPort: 6379

# kubectl apply -f redis-leader.yaml

# cat redis-slave.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: redis-slave
  labels:
    role: slave
spec:
  containers:
  - name: redis-slave
    image: redis
    command: ["redis-server"]
    args:
    - --port 6380
    - --slaveof  10.1.135.134 6379		# redis_leader_pod_ip
    ports:
    - containerPort: 6380

# kubectl apply -f redis-slave.yaml
# redis-cli -h redis_leader_pod_ip info

2.0 Pod 生命周期

2.1 初始化容器

  • init container 是用来做初始化工作的容器，可以有一个或多个，如果多个按照定义的顺序依次执行，只有所有的执行完成后，主容器才启动，由于一个 pod 里的存储卷是共享的，所以 init container 里产生的数据可以被主容器使用到，但它仅仅是在启动时，在主容器启动前执行，做初始化工作。如果 pod 的 init 容器失败，kubernetes 会不断重启该 pod，直到 init 容器成功为止。如果 pod 对应的 restartPolicy 值为 Never， kubernetes 不会重新启动 pod。
  • 应用场景:
    • app 容器依赖 mysql 的数据交互，所以可以启动一个初始化容器检查 mysql 服务是否正常，如果正常则启动主容器
    • 在启动主容器之前，使用初始化容器对系统内核参数进行调优，然后共享给主容器使用
    • 获取集群成员节点地址，为主容器生成对应配置信息，这样主容器启动后，可以通过配置信息加入集群环境

2.1.1 场景1-端口检查

  • 编写 yaml，使用初始化容器对 mysql 端口进行检查，如果存活则运行 pod，否则就一直重启尝试
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# cat init-check-mysql.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: init-check-mysql
spec:
  imagePullSecrets:
  - name: harbor-registry-auth
  initContainers:
  - name: check-mysql
    image: harbor.inadm.com/inadm_kubernetes/tools:latest
    command: ["sh", "-c", "nc -z MYSQL_POD_IP 3306"]
    securityContext:                                    # 特权模式运行容器，否则无法修改内核参数
      privileged: true
  containers:
  - name: app-mysql
    image: nginx
    ports:
    - containerPort: 80

// 这里的 "MYSQL_POD_IP" 是使用的 1.4 mysql-demo-env 容器 IP 地址,主要是为了演示初始化容器场景的实现
# kubectl apply -f init-check-mysql.yaml

2.1.2 场景2-内核参数优化

  • 使用初始化容器对内核参数进行优化
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# cat init-sysctl-nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: init-sysctl-nginx
spec:
  initContainers:
  - name: set-sysctl
    image: alpine:3.13
    command: ["sh", "-c", "sysctl -w net.core.somaxconn=32769; sysctl -w net.ipv4.ip_local_port_range='1024 65000'"]
    securityContext:
      privileged: true
  containers:
  - name: app-sysctl
    image: nginx
    ports:
    - containerPort: 80

# kubectl apply -f init-sysctl-nginx.yaml 
// 检查验证
# kubectl exec -it init-sysctl-nginx -c "app-sysctl" -- /bin/bash -c "cat /proc/sys/net/core/somaxconn"		# 值为 "32769"

2.2 钩子函数

  • 钩子函数用来监听容器生命周期的特定事件，并在事件发生时执行已注册的回调函数
    • 当一个容器启动后，kubernetes 将立即执行 postStart 事件关联的动作
    • 在容器被终结之前，kubernetes 将立即执行 preStop 事件关联的动作
  • 两种钩子
    • postStart: 容器创建后立即执行，由于是异步执行，它无法保证在容器之前运行。如果失败，容器会杀死，并根据 RestartPolicy 决定是否重启
    • preStop: 在容器终止前执行。用于: 释放占用的资源、清理注册过的信息、优雅的关闭进程。在其完成之前会阻塞删除容器的操作，默认等待时间为 30s，可以通过 terminationGracePeriodSeconds 宽限时间

2.2.1 钩子示例

postStart 示例
1
2
3
4
5
6
7
8
// 通过 postStart 设定端口重定向，将请求本机的 8080 调度到本机 80 端口
lifecycle:
  postStart:
    exec:
      command:
      - "/bin/bash"
      - "-c"
      - "iptables -t nat -A REROUTING -p tcp --dport 8080 -j REDIRECT --to-ports 80"
preStop 示例
1
2
3
4
5
6
7
8
9
// runner 主要用来编译打包提高 CI 效率。启动后会注册到 gitlab 上，后续不需要可以删除 Pod，然后清理注册信息
// 通过 preStop 清理 runner 注册信息
lifecycle:
  preStop:
    exec:
      command:
      - "/bin/bash"
      - "-c"
      - "/usr/bin/gitlab-runner unregister -n $RUNNER_NAME"

2.2.2 钩子场景1

  • postStart 命令在容器的 /usr/share/nginx/html/index.html 自定义一段内容
  • preStop 负责优雅地终止 nginx 服务
  • terminationGracePeriodSeconds 宽限期，如果超过宽限期 pod 还没有终止，则会由 SIGKLL 强制关闭信号介入。
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
# cat 1-pod-postStart.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-nginx
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command:
          - "/bin/sh"
          - "-c"
          - "echo Hello from the postStart handler... > /usr/share/nginx/html/index.html"
      preStop:
        exec:
          command:
          - "/bin/sh"
          - "-c"
          - "sleep 10; nginx -s quit"

# kubectl apply -f 1-pod-postStart.yaml
# kubectl exec -it lifecycle-nginx -- cat /usr/share/nginx/html/index.html	# postStart 演示结果
// preStop 演示,在删除时使用 describe 可查看到 Killing 在 11s 时完全删除完毕,如图
// sleep 10s + pod 自身1s 时间
# kubectl describe pod lifecycle-nginx

upload successful

2.2.3 钩子场景2

  • postStart 命令负责将默认页面拷贝至 /usr/local/tomcat/webapps
  • preStop 负责给容器发送 SIGTERM 信号，从而优雅地终止 tomcat 服务
  • terminationGracePeriodSeconds 宽限期，如果超过宽限期 pod 还没有终止，则会由 SIGKILL 强制关闭信号介入
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
# cat 2-pod-postStart.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-lifecycle-2
  labels:
    app: tomcat
spec:
  terminationGracePeriodSeconds: 120                        # 超过宽限期,优雅关闭未执行完情况下，强制SIGKILL
  containers:
  - name: tomcat-web
    image: tomcat
    ports:
    - containerPort: 8080
    lifecycle:
      postStart:
        exec:
          command:
          - "/bin/bash"
          - "-c"
          - "cp -rp /usr/local/tomcat/webapps.dist/* /usr/local/tomcat/webapps/"
      preStop:
        exec:
          command:
          - "/bin/sh"
          - "-c"
          - "/usr/local/tomcat/bin/shutdown.sh"                # 优雅关闭

# kubectl apply -f 2-pod-postStart.yaml 
# kubectl expose pod pod-lifecycle-2 --port=9999 --target-port=8080 --type=NodePort
// 浏览器访问: http://10.16.41.24:30597/
// 下图表示,删除 Pod 时,的优雅关闭

upload successful

2.3 检测探针

  • 为何需要探针: 当容器进程运行时如出现异常退出，k8s 则会认为容器发生故障，会尝试进行重启解决该问题。但有些情况是发生了故障，但进程没有退出。比如访问 web 服务时出现 500 错误，可能是系统超载，也可能资源死锁，但 nginx 进程并没有异常退出，在这种情况下重启容器是最佳方法，如何来实现检测
  • kubernetes 使用探针(probe)方式来保障容器正常运行，实现零宕机。它通过 kubelet 定期对容器进行健康检查 (exec 、tpc、http)，当探针检测到容器状态异常时，会通过重启策略来进行重启或重建完成修复。修复后继续进行探针检测，以确保容器稳定运行

2.3.1 探针检测类型

  • 针对运行中的容器，kubelet 可以选择一下三种探针来探测容器的状态
    • startupProbe 启动探针: 用于检测容器中的应用是否已经正常启动。如果使用了启动探针，则所有其它探针都会被禁用，需要等待启动探针检测成功之后才可以执行。如果启动探针探测失败，则 kubelet 会将容器杀死，而容器以其重启策略进行重启。如果容器没有提供启动探测，则默认状态为 Success。
    • livenessProbe 存活探针: 用于检测容器是否存活，如果存活探测检测失败， kubelet 会杀死容器，然后根据容器重启策略，决定是否重启该容器。如果容器不提供存活探针，则默认状态为 Success
    • readinessProbe 就绪探针: 指容器是否准备好接收网络请求，如果就绪探测失败，则将容器设定为未就绪状态，然后将其从负载均衡列表移除，这样就不会有请求会调度到该 Pod 上。如果容器不提供就绪探针，则默认状态为 Success

2.3.2 探针检查机制

  • 使用探针来检查容器 [只能任选其一]
    • exec: 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功
    • httpGet: 对指定的 IP、端口，执行 HTTP 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的
    • tcpSocket: 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的
  • 每次探测都获得以下三种结果之一
    • Success：容器通过诊断
    • Failure：容器未通过诊断，可能会触发重启操作
    • Unknown：诊断失败，因此不会采取任何行动

2.3.3 startupProbe

  • 有时会有一些应用在启动时需要较长的初始化时间。若要不影响对死锁做出快速响应的探测，设置存活探测参数是要技巧的。技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对最糟糕情况下的启动时间

2.3.3.1 exec

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
42
# kubectl create ns inadm
# kubectl create secret docker-registry harbor-auth \
 --docker-server=harbor.inadm.com \
 --docker-username=admin \
 --docker-password=ink8s.comA \
 -n inadm

# cat pod-startupProbe-exec.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-startupprobe
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-startupprobe-exec
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    startupProbe:
      exec:
        command:
        - "/bin/sh"
        - "-c"
        - "netstat -nlput | grep 80"
      initialDelaySeconds: 10                    # 容器启动多久后开始探测，默认0
      periodSeconds: 5                           # 探测频率
      timeoutSeconds: 10                         # 探测超时时长
      successThreshold: 1                        # 成功多少次则为成功
      failureThreshold: 3                        # 失败多少次则为失败

// 第一次探测识别多久会重启 (对所有探测有用)
initialDelaySeconds + (periodSeconds + timeoutSeconds) * failureThreshold
10 + (5 + 10) * 3 = 55s
// 程序启动完成后: 此时不需要计入 initialDelaySeconds (对 livenessprobe、readiness 有用)
(periodSeconds + timeoutSeconds) * failureThreshold
// 应用将会有(failureThreshold * periodSeconds = 15s)的时间来完成启动过程

 
# kubectl apply -f pod-startupProbe-exec.yaml

2.3.3.2 httpGet

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
# cat pod-startprobe-httpget.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-startupprobe-httpget
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-startupprobe-httpget
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    startupProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-startprobe-httpget.yaml

2.3.3.3 tcpSocket

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# cat pod-startupprobe-tcp.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-startupprobe-tcp
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-startupprobe-tcp
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    startupProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-startupprobe-tcp.yaml

2.3.4 livenessProbe

2.3.4.1 exec

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
# cat pod-livenessprobe-exe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-livenessprobe-exec
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-livenessprobe-exec
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    livenessProbe:
      exec:
        command:
        - "/bin/sh"
        - "-c"
        - '[ "$(curl -s 127.0.0.1/aaaalivez)" == "OK" ]'
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-livenessprobe-exe.yaml 
# kubectl exec -n inadm -it pod-livenessprobe-exec -- curl -s 127.0.0.1/livez


upload successful

2.3.4.1 httpGet

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
# cat pod-livenessprobe-httpget.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-livenessprobe-httpget
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-livenessprobe-httpget
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: '/livez'
        port: 80
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-livenessprobe-httpget.yaml 
// 检测存活状态检测效果，可以手动将 /livez 接口响应内容修改为任意值
# kubectl exec -n inadm -it pod-livenessprobe-httpget -- curl -s -X POST -d 'livez=error' 127.0.0.1/livez

// 程序启动完成后: 此时不需要计入 initialDelaySeconds (对 livenessprobe、readiness 有用)
(periodSeconds + timeoutSeconds) * failureThreshold
( 5 + 10 ) * 3 = 45s

// 等待3个检测周期结束，容器会因健康检测失败而被重启，重启后 /livez 响应内容会被重置为 ok，后续存活状态检测不会出现错误

upload successful

2.3.4.2 tcpSocket

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# cat pod-livenessprobe-tcp.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-livenessprobe-tcp
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-livenessprobe-tcp
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-livenessprobe-tcp.yaml

2.3.5 readinessProbe

  • 有些程序启动需要加载配置或数据，甚至有些程序需要运行预热的过程，需要一定时间。所以需要避免 Pod 启动成功后立即让其处理客户端请求，而应该让其初始化完成后转为就绪状态，在对外提供服务。此类应用就需要使用 readinessProbe 探针

2.3.5.1 exec

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
# cat pod-readinessprobe-exec.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-readiness-exec
  namespace: inadm
  labels:
    app: readiness
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-readiness-exec
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    readinessProbe:
      exec:
        command:
          - "/bin/sh"
          - "-c"
          - '[ "$(curl -s 127.0.0.1/readyz)" == "OK" ]'
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-readinessprobe-exec.yaml

2.3.5.2 httpGet

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
// 需要有 svc 服务配合，此处简略不加入 svc 验证
# cat pod-readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-readiness-httpget
  namespace: inadm
  labels:
    app: readiness
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-readiness-httpget
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: '/readyz'
        port: 80
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-readiness-httpget.yaml 

// 将接口修改为 error ，状态会变为未就绪，节点就会被提除出 endpoints
# kubectl exec -it -n inadm pod-readiness-httpget -- curl -s -X POST -d 'readyz=error' 127.0.0.1/ready

2.3.5.3 tcpSocket

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
# cat pod-readinessprobe-tcp.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-readiness-tcp
  namespace: inadm
  labels:
    app: readiness
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-readiness-tcp
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    ports:
    - containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 10
      successThreshold: 1
      failureThreshold: 3

# kubectl apply -f pod-readinessprobe-tcp.yaml

3.0 Pod 资源限制

  • kubernetes 通过 Requests 和 Limits 字段来实现对 Pod 的资源限制
    • Requests: 启动 Pod 时申请分配的资源大小 (Pod在调度时requests比较重要)
    • Limits: 限制 Pod 运行时最大可用的资源大小 (Pod在运行时limits比较重要)
  • CPU 限制单位
    • 1 核 CPU 等于 1000 毫核，当定义容器为 0.5 时，所能用到的 CPU 资源是 1 核心 CPU 的一半，对于 CPU 资源单位，表达式 0.1 等价于表达式 100m，可以看做 100 millicpu
1
2
1C = 1000 millicpu (1 coer = 1000m)
0.5C = 500 millicpu (0.5 coer = 500m)
  • 内存分配单位: 内存的基本单位是字节数(Bytes)，也可以加上国际单位，十进制的 E、P、T、G、M、K、m，或二进的 Ei、Pi、Ti、Gi、Mi、Ki
1
2
1MB = 1000KB = 1000000 Bytes
1Mi = 1024KB = 1048576 btyes

3.1 cpu 资源限制

3.1.1 cpu 请求和限制

  • 创建一个 Pod，容器将请求 0.5 个 CPU，最多限制使用 1 个 CPU
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# cat cpu-requests-limits.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: inadm
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    args:
    - -cpus                        # 模拟压力测试，可以使用到2个cpu。但下面有设定限制，最多只能使用到1个
    - "2"
    resources:
      requests:
        cpu: "500m"                # 限制启动pod时最多申请0.5核的cpu
      limits:
        cpu: "1000m"               # 限制pod最多使用1核cpu

# kubectl apply -f cpu-requests-limits.yaml 
# kubectl top pod cpu-demo -n inadm

upload successful

3.1.2 超过节点 cpu 请求

  • 创建一个pod，设置该pod中容器的请求为100核，这个值会大于集群中的任何一个节点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# cat pod-requests-limints.yaml 
apiVersion: v1
kind: Pod
metadata:
  namespace: inadm
  name: cpu-demo-2
spec:
  containers:
  - name: cpu-demo-ctr-2
    image: vish/stress
    args:
    - -cpus
    - "2"
    resources:
      requests:
        cpu: "100"
      limits:
        cpu: "100"

# kubectl apply -f pod-requests-limints.yaml 
# kubectl describe pod -n inadm cpu-demo-2

upload successful

3.1.2 不指定cpu limits

  • 如果没有为容器指定cpu限制，那么容器在可以使用的cpu资源是没有上限。因而可以使用所在节点上所有的可用cpu资源，这样会造成一个pod占用大量cpu，可能会导致其它pod的正常运行，从而造成业务的不稳定
  • kubernetes中，可以通过 LimitRange 自动为容器设定，所使用的CPU资源和内存资源最大最小值

3.2 内存资源限制

3.2.1 mem 请求和限制

  • 创建一个Pod，容器将会请求 100MiB 内存，并且内存会被限制在 200MiB 以内
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
# cat pod-mem-requests-limits.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mem-demo-1
  namespace: inadm
spec:
  containers:
  - name: mem-demo-1
    image: polinux/stress
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
    resources:
      requests:
       memory: "100Mi"
      limits:
        memory: "200Mi"
    resources:
      limits:
        memory: 200Mi
      requests:
        memory: 100Mi

// 获取该Pod指标数据，输出结果显示Pod正在使用的内存约为 150MiB，这大于Pod请求的100Mib，但又在Pod限制的200MiB之内
# kubectl apply -f pod-mem-requests-limits.yaml 
# kubectl top pod -n inadm mem-demo-1

upload successful

3.2.2 超过容器mem限制的应用

  • 当节点有足够的内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。如果容器的内存超过其限制，该容器会成为被终止的候选容器。如果容器继续消耗超过其限制的内存，则终止容器。如果终止的容器可以被重启，则 kubelet 会重新启动它。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 创建一个pod，其拥有一个容器，该容器的内存请求为 100MiB，内存限制为200MiB，尝试分配超出其限制的内存
# cat pod-mem-requests-limist.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mem-demo-3
  namespace: inadm
spec:
  containers:
  - name: mem-demo-3
    image: polinux/stress
    command: ["stress"]                                            # 容器会尝试分配 250MiB 内存，这远高于 100MiB 的限制
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]    # 模拟1个进程产生 250M 内存
    resources:
      requests:
       memory: "100Mi"
      limits:
        memory: "200Mi"

# kubectl apply -f pod-mem-requests-limist.yaml 
# kubectl get pod -n inadm mem-demo-3 -o yaml | grep reason        # 内存溢出 00M

upload successful

3.2.3 超过节点mem分配

  • pod 的调度基于请求。只有当节点拥有足够满足Pod内存请求的内存时，才会将pod调度至节点上运行
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 创建一个pod，其拥有一个请求 100GiB内存的容器，这应该超过了集群中任何一台节点所拥有的内存
# cat pod-requests-limits.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mem-demo-4
  namespace: inadm
spec:
  containers:
  - name: mem-demo-4
    image: polinux/stress
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]
    resources:
      requests:
       memory: "100Gi"
      limits:
        memory: "200Gi"

# kubectl apply -f pod-requests-limits.yaml

upload successful

3.2.4 未指定内存限制

  • 如果没有为容器指定内存限制，容器可无限制地使用其所在节点的所有可用内存，进而可能导致该节点调用 OOM Killer。此外，如果发生 OOM Kill，没有配置资源限制的容器将被杀掉的可行性更大
  • 不用担心，在 kubernetes中，可以通过 LimitRange 自动为其容器设定，所使用的内存资源最大最小值

3.3 Qos 服务质量

  • Qos [服务质量等级] or [服务质量保证]，是作用在pod上的一个配置，当kubernetes创建一个pod时，它就会给这个pod分配一个Qos等级

  • 在k8s环境中，k8s允许节点的pod过载使用资源，这意味着节点无法同时满足所有pod以过载方式运行。因此在内存资源紧缺情况下，k8s需要借助pod对象的服务质量和优先级等完成判定，进而挑选对应的pod杀死。k8s根据pod的requests和limits属性，把pod对象归类为 BestEffort、BurStable、Guaranteed

  • Qos 类别:

    • Guaranteed: pod对象为每个容器都设置了cpu资源需求和资源限制，且两者的值相同；还同时为每个容器设置了内存需求和内存限制，并且两者的值相同。这类pod对象具有最高级别服务质量
    • Burstable: 至少有一个容器设置了cpu或者内存资源requests属性，但不满足Guaranteed，这类pod具有中级服务质量
    • BestEffort: 没有为任何容器设置requests和limits属性，这类pod对象服务质量是最低级别

  • 当k8s集群内存资源紧缺，优先杀死 BestEffort 类别的容器，因为系统不为该资源提供任何服务保证，但此类资源最大的好处就是能够尽可能使用资源

  • 当k8s集群内存资源紧缺，优先杀死 BestEffort 类别的容器，因为系统不为该资源提供任何服务保证，但此类资源最大的好处就是能够尽可能使用资源

  • 对于 Guaranteed 类别容器拥有最高优先级，他们不会被杀死，除非其它内存资源需求超限，或者 OOM 时没有其它更低优先级的 pod 对象存在，才会干掉 Guaranteed 类容器

3.3.1 创建Guaranteed的pod

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// pod中的每个容器都必须指定内存请求和内存限制，且pod中每个容器内存请求必须等于内存限制
// pod中的每个容器都必须指定cpu请求和cpu限制，且pod中每个容器cpu请求必须等于内存限制
// 创建一个pod，容器设置了内存请求和内存限制，值都是200MiB。容器设置了CPU请求和CPU限制，值都是700 milliCPU

# cat pod-qos-guaranteed.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-qos-guaranteed
  namespace: inadm
spec:
  containers:
  - name: pod-qos-guaranteed
    image: nginx
    resources:
      requests:
        cpu: "700m"
        memory: "200Mi"
      limits:
        cpu: "700m"
        memory: "200Mi"

# kubectl apply -f pod-qos-guaranteed.yaml 
# kubectl describe pod -n inadm pod-qos-guaranteed

upload successful

3.3.2 创建Burstables的pod

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 如果满足下面条件，将会指定pod的Qos类型为Burstable:
    1. pod不符合Guaranteed Qos类型标准
    2. pod中至少一个容器指定了，内存或cpu的请求或限制
// 创建一个pod，容器设置了内存请求100MiB，以及内存限制200MiB

# cat pod-qos-burstable.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-qos-burstable
  namespace: inadm
spec:
  containers:
  - name: pod-qos-burstable
    image: nginx
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"

# kubectl apply -f pod-qos-burstable.yaml 
# kubectl describe pod -n inadm pod-qos-burstable

upload successful

3.3.2 创建BestEffort的pod

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 对于Qos类为 BestEffort 的 pod，pod 中的容器必须没有设置内存和cpu限制或请求
// 创建一个pod，容器没有设置内存和cpu限制或请求

# cat pod-qos-besteffort.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-qos-besteffort
  namespace: inadm
spec:
  containers:
  - name: pod-qos-besteffort
    image: nginx

# kubectl apply -f pod-qos-besteffort.yaml 
# kubectl describe pod -n inadm pod-qos-besteffort

upload successful

3.3.3 创建多个容器pod

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 创建一个pod，一个容器指定了内存请求 200MiB。另外一个容器没有指定任何请求和限制。此pod满足burstable Qos类的标准。但它不满足 Guaranteed Qos 类标准，因为它的一个容器没有内存请求

# cat pod-qos-mutil.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-qos-mutil
  namespace: inadm
spec:
  containers:
  - name: pod-qos-mutil
    image: nginx
    resources:
      requests:
        memory: "100Mi"
  - name: redis-qos
    image: redis

# kubectl apply -f pod-qos-mutil.yaml 
# kubectl describe pod -n inadm pod-qos-mutil | grep QoS

upload successful

3.4 downward api

  • 什么是 DownwardAPI: DownwardAPI 可以让容器获取pod的相关元数据信息，比如pod名称、pod_ip、pod的资源限制等，获取后通过env、volume的方式将相关的环境信息注入到容器中，从而让容器通过这些信息，来设定容器的运行特性
    • 例如: nginx 进程根据节点的cpu核心数量自动设定要启动的worker进程数
    • 例如: jvm虚拟根据pod的内存资源限制，来设定对应容器的堆内存大小
    • 例如: 获取pod名称，以pod名称注册到某个服务，当pod结束后，调用prestop清理对应名称的注册信息

3.4.1 可注入元数据信息

  • 使用 pod.spec.containers.env.valueFrom.fieldRef 可以注入的字段有:
    • metadata.name: Pod 对象的名称
    • metadata.namespace: Pod 对象隶属于名称空间
    • metadata.uid: Pod 对象的 UID
    • metadata.labels “KEY”: 获取 Label 指定 KEY 对应的值
    • metadata.annotations “KEY”: 获取 Annotations 对应 KEY 的值
    • status.podIP: Pod 对象的IP地址
    • status.hostIP: 节点IP
    • status.nodeName: 节点名称
    • spec.serviceAcconuntName: Pod 对象使用的 ServiceAccount 资源名称
  • 使用 pod.spec.containers.env.valueFrom.resourceFieldRef 可以注入的字段有:
    • requests.cpu
    • requests.memory
    • limits.cpu
    • limits.memory

3.4.2 环境变量注入元数据

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
42
43
44
45
46
47
48
49
50
51
52
// 创建Pod容器，将Pod相关环境变量注入到容器中，比如(pod名称、命名空间、标签、以及cpu、内存的请求和限制)

# cat pod-downward.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-downward
  namespace: inadm
  labels:
    app: pod-app  
spec:
  containers:
  - name: pod-downward
    image: nginx
    command: ["/bin/bash", "-c", "env"]
    resources:
      requests:
        cpu: "200m"
        memory: "32Mi"
      limits:
        cpu: "200m"
        memory: "64Mi"
    env:
    - name: K8S_POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: K8S_POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: K8S_POD_LABELS
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['app']
    - name: K8S_POD_CPU_LIMITS
      valueFrom:
        resourceFieldRef:
          resource: limits.cpu
    - name: K8S_POD_MEMORY_REQUESTS
      valueFrom:
        resourceFieldRef:
          resource: requests.memory
          divisor: 1Mi

# kubectl apply -f pod-downward.yaml
# kubectl logs -n inadm pod-downward | grep ^K8S
K8S_POD_NAME=pod-downward
K8S_POD_NAMESPACE=inadm
K8S_POD_MEMORY_REQUESTS=32          # 单位为兆，默认字节
K8S_POD_CPU_LIMITS=1                # 200毫核，不足1核，则进行取整
K8S_POD_LABELS=pod-app

3.4.3 存储卷注入元数据

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
42
43
44
45
46
47
48
49
50
51
# cat pod-downward-api.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-downward-volumes
  namespace: inadm
  labels:
    app: pod-app
    zone: shenzhen
    role: backend
spec:
  containers:
  - name: pod-downward-volumes
    image: nginx
    resources:
      requests:
        cpu: "200m"
        memory: "32Mi"
      limits:
        cpu: "200m"
        memory: "64Mi"
    volumeMounts:                # 将环境变量挂载到 /etc/info目录中，注入一条元数据都会产生一个文件
    - name: podinfo
      mountPath: /etc/info

  volumes:
  - name: podinfo
    downwardAPI:
      items:
      - path: pod_name
        fieldRef:
          fieldPath: metadata.name
      - path: pod_labels
        fieldRef:
          fieldPath: metadata.labels
      - path: pod_namespace
        fieldRef:
          fieldPath: metadata.namespace
      - path: mem_limits
        resourceFieldRef:
          resource: limits.memory
          containerName: pod-downward-volumes
          divisor: 1Mi
      - path: mem_requests
        resourceFieldRef:
          resource: requests.memory
          containerName: pod-downward-volumes
          divisor: 1Mi

# kubectl apply -f pod-downward-api.yaml 
# kubectl exec -it -n inadm pod-downward-volumes -- /bin/bash

upload successful

3.4.4 为注册服务注入pod名称

  • 使用 DownwardAPI 实现注册与卸载
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
# cat pod-register.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-downward-register
  namespace: inadm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: tools
  template:
    metadata:
      labels:
        app: tools
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: register
        image: harbor.inadm.com/inadm_kubernetes/tools:latest
        imagePullPolicy: IfNotPresent
        command:
        - "/bin/bash"
        - "-c"
        - |
          mysql -h 10.16.41.152 -uroot -pink8s.com -e "create database ${POD_NAME//-/_}"
          sleep 999999
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        lifecycle:
          preStop:
            exec:
              command:
              - "/bin/bash"
              - "-c"
              - mysql -h 10.16.41.152 -uroot -pink8s.com -e "drop database ${POD_NAME//-/_}"

---
# 引入外部 MySQL 需要用到自定义 endpoint
apiVersion: v1
kind: Endpoints
metadata:
  name: svc-mysql-external
  namespace: inadm
subsets:
  - addresses:
    - ip: 10.16.41.152
    ports:
    - protocol: TCP
      port: 3306

---
apiVersion: v1
kind: Service
metadata:
  name: svc-mysql-external
  namespace: inadm
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 3306
    targetPort: 3306


# kubectl apply -f pod-register.yaml 

# MySQL 赋予相应权限
mysql> grant all privileges on *.* to 'root'@'10.16.41.%' identified by 'ink8s.com' with grant option;
mysql> flush privileges;

// 应用前后，数据库的创建演示效果。仅仅演示效果，生产或测试不可操作
# kubectl delete -f pod-register.yaml 	# 登录MySQL后 apply 和 delete 之后前后对比

upload successful

3.4.5 为Tomcat注入对内存限制

  • 默认Tomcat应用会使用Pod所在的物理节点内存，初始堆内存为1/64，最大堆内存为1/4

  • 1、运行一个默认的Tomcat，检查初始jvm堆内存大小

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# cat pod-tomcat-1.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-downward-tomcat
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-downward-tomcat
    image: harbor.inadm.com/inadm_kubernetes/tomcat:9.0.63
    ports:
    - containerPort: 8080

// 查看默认tomcat的内存堆大小
# kubectl apply -f pod-tomcat-1.yaml 
# kubectl exec -it -n inadm pod-downward-tomcat -- /bin/bash
root@pod-downward-tomcat:/usr/local/tomcat# jps                    # 查看进程 [进程为 1]
root@pod-downward-tomcat:/usr/local/tomcat# jinfo 1                # 查看进程为 1 的 jvm 堆内存大小
    InitialHeapSize=262144000    初始内存: 250M
    MaxHeapSize=4164943872       最大可用: 3972M
// 上面 2 个值，是通过本机节点的 1/64 1/4 获得的
root@pod-downward-tomcat:/usr/local/tomcat# free -m

upload successful

  • 2.对Tomcat设定资源限制，看看这个资源限制对Tomcat分配内存有没有影响
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
# cat pod-tomcat-2.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-downward-tomcat-2
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-downward-tomcat-2
    image: harbor.inadm.com/inadm_kubernetes/tomcat:9.0.63
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: 100Mi
      limits:
        memory: 200Mi

# kubectl apply -f pod-tomcat-2.yaml 
# kubectl exec -it -n inadm pod-downward-tomcat-2 -- /bin/bash
root@pod-downward-tomcat:/usr/local/tomcat# jps
root@pod-downward-tomcat:/usr/local/tomcat# jinfo 1
    InitialHeapSize=8388608 字节            8M
    MaxHeapSize=104857600 字节              100M
// 说明资源限制对堆内存jvm的分配是有一定影响，不是使用的物理节点进行的分配的了

upload successful

  • 3.手动为Tomcat指定堆内存，500M，对pod限制100M
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
# cat pod-tomcat-3.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-downward-tomcat-3
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-downward-tomcat-3
    image: harbor.inadm.com/inadm_kubernetes/tomcat:9.0.63
    ports:
    - containerPort: 8080
    env:
    - name: JAVA_OPTS
      value: -server -Xms500m -Xmx500m -XX:+UseConcMarkSweepGC
    resources:
      requests:
        memory: 100Mi
      limits:
        memory: 100Mi

# kubectl apply -f pod-tomcat-3.yaml 
// 让jvm使用500Mi，但实际最大是能使用到100Mi。使用 ab 压力测试验证，ab 过程中,pod就会被频繁 kill
# kubectl exec -it -n inadm pod-downward-tomcat-3 -- /bin/bash
root@pod-downward-tomcat:/usr/local/tomcat# jinfo 1                    			# jvm 内存堆是设定的 500

// 压测
[root@szbwx-ops-sly-k8s-master01 ~]# kubectl top -n inadm pod pod-downward-tomcat    # 已经使用 75Mi
pod-downward-tomcat   2m           75Mi
# watch -n 1 kubectl top -n inadm pod pod-downward-tomcat-3                            # 只要内存上到100Mi，pod 就会被 kill
# ab -n 10000 -c 10 http://10.1.58.224:8080/                                     	# 将 pod 压挂了

upload successful

  • 4.将 request limits 值，传递给 jvm 内存设定
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
# cat pod-tomcat-4.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-downward-tomcat-4
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-downward-tomcat-4
    image: harbor.inadm.com/inadm_kubernetes/tomcat:9.0.63
    ports:
    - containerPort: 8080
    env:
    - name: JAVA_OPTS
      value: -server -Xms${JVM_XMS} -Xmx${JVM_XMX} -XX:+UseConcMarkSweepGC
    - name: JVM_XMS
      valueFrom:
        resourceFieldRef:
          resource: requests.memory
    - name: JVM_XMX
      valueFrom:
        resourceFieldRef:
          resource: limits.memory
    resources:
      requests:
        memory: 200Mi
      limits:
        memory: 500Mi

# kubectl apply -f pod-tomcat-4.yaml 
# kubectl exec -it -n inadm pod-downward-tomcat-4 -- /bin/bas
root@pod-downward-tomcat-4:/usr/local/tomcat# jinfo 1

upload successful

4.0 deployment

4.1 replicaset

  • ReplicaSet 控制器包含了3个基本组成部分
    • selector 标签选择器: 匹配并关联 Pod 对象，并加入控制器的管理中
    • replicas 期望的副本数: 期望在集群中所运行的 Pod 对象数量
    • template Pod 模板: 定义 Pod 规范，相当于把一个 Pod 的描述以模板形式嵌入到了 ReplicaSet
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
// RS 控制器更新缺点：更新时会统一 kill 掉 Pod 然后统一拉起
# cat rs-deploy.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-deploy               # RS 控制器名称
  namespace: inadm 
spec:                           # 定义 RS 规范
  replicas: 3                   # 定义 Pod 副本数量，默认为 1 个
  selector:                      # RS 通过 Selector 选择一组 Pod，并进行管理
    matchLabels:
      app: nginx
  template:                     # 定义Pod模板，当RS需要创建Pod时就通过模板来创建
    metadata:
      labels:                   # 所有通过该模板运行的Pod都有 app=nginx 这个标签
        app: nginx
    spec:
      containers:
      - name: rs-container
        image: nginx:1.16
        ports: 
        - name: http
          containerPort: 80

# kubectl apply -f rs-deploy.yaml

4.2 deploy

  • Deployment 控制器包含 3 个基本组成部分
    • selector 标签选择器: 匹配并关联 Pod 对象，并加入控制器的管理中
    • replicas 期望的副本数: 期望在集群中所运行的 Pod 对象数量
    • template Pod 模板: 定义 Pod 规范，相当于把一个 Pod 的描述以模板形式嵌入到了 ReplicaSet
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
# cat deploy-demo.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-demo               # deploy 控制器名称
  namespace: inadm 
spec:
  replicas: 3                     # 定义 Deploy 控制 Pod 副本数量
  minReadySeconds: 10             # Pod 就绪后，多少秒内任一容器无崩溃视为 "就绪"，默认 0s
  selector:
    matchLabels:
      app: web
  template:                       # 定义Pod模板，申明 Pod 名称，使用惊喜那个、拥有哪些标签等
    metadata:
      labels:                     # Pod标签
        app: web
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: deploy-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports: 
        - name: http
          containerPort: 80

# kubectl apply -f deploy-demo.yaml

upload successful

  • 检查集群 Deployment
    • NAME：列出了集群中的 Deployment 的名称
    • READY：显示应用程序的可用副本数。显示的模式是 “就绪个数”/“期望个数”
    • UP-TO-DATE：显示为了达到期望状态已经更新的副本数
    • AVAILABLE：显示应用程序可供用户使用的副本数
    • AGE：显示应用程序运行的时间

4.3 svc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# cat deploy-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: demo-svc
  namespace: inadm
spec:
  selector:
    app: web
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f deploy-svc.yaml 
# curl POD_IP/version
# curl SVC_IP/version            # 重复操作会轮询

upload successful

4.4 hpa

  • 什么是 HPA：k8s 实现 Pod 的扩容缩容需要通过手动来实现，但线上业务情况复杂，依赖于纯手动方式不太现实。所以希望系统能自动感知 Pod 的压力来完成扩缩容，比如: 当 Pod 的 CPU 达到 50% 则扩容，当 Pod 的 CPU 低于 50% 自动缩容。为此 k8s 提供了一个资源对象 HPA（horizontal-pod-autoscaler），专用来实现 Pod 的水平自动扩缩容。HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量
  • 自动扩缩容算法(基于 metricserver):
    • 当前指标：当前 Pod 已经达到百分之多少的压力
    • 期望指标：当前 Pod 达到期望的指标百分比时就要进行扩容
    • 例如：当前副本数 1，当前指标值 200%，期望指标值 50%，则副本数为 1 * （200% / 50%） = 4
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# cat hpa-deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hpa-deploy
  namespace: inadm
spec:
  selector:
    matchLabels:
      run: hpa-deploy
  replicas: 1
  template:
    metadata:
      labels:
        run: hpa-deploy
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: php-apache-hpa
        image: harbor.inadm.com/inadm_kubernetes/hpa-example:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 200m
          limits:
            cpu: 500m

---
apiVersion: v1
kind: Service
metadata:
  name: hpa-deploy
  namespace: inadm
spec:
  selector:
    run: hpa-deploy
  ports:
  - port: 80
    targetPort: 80

---
# 创建 hpa，设定 cpu 超过 50%，则触发自动创建 Pod 副本；
# 可以采用 -o yaml 方式获取文本方式编辑
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-deploy
  namespace: inadm
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-deploy
  targetCPUUtilizationPercentage: 50

# kubectl apply -f hpa-deploy.yaml 
// 命令创建扩缩容: kubectl autoscale deploy hpa-deploy --min=1 max=10 --cpu-percent=50
# kubectl get pod -l run=hpa-deploy -n inadm
# kubectl get hpa -n inadm
# while sleep 0.01; do curl http://SVC_IP; done                # 模拟增加负载模拟；如暂停压力测试之后，5分钟后才会恢复设定的初始 rs 值状态

upload successful

upload successful

4.5 recreate 重建策略

  • 什么是 Recreate：当更新策略设定为 Recreate，在更新镜像时，它会先杀死正在运行的 Pod，等彻底杀死后，重新创建的 RS，然后启动对应的 Pod，在更新过程中，会造成服务一段时间停止提供服务
    • 1.同时杀死所有旧版 Pod，此时 Pod 无法正常对外提供服务
    • 2.创建新的 RS，启动新的 Pod
    • 3.等待 Pod就绪，对外提供服务
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
42
43
44
45
46
47
48
49
50
51
# cat deploy-recreate.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate-demo
  namespace: inadm
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: demoapp
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: recreate-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports: 
        - name: http
          containerPort: 80

---
 apiVersion: v1
 kind: Service
 metadata:
   name: svc-demo
   namespace: inadm
 spec:
   selector:
     app: demoapp
   ports:
   - name: http
     port: 80
     targetPort: 80

# kubectl apply -f deploy-recreate.yaml
# watch -n1 kubectl get pod -n inadm
# while sleep 1; do curl http://SVC_IP/version; done
// 当将 image 的版本更新到 demoapp:v1.1 后观察如下图变化，会统一将 Pod Kill 掉，然后将统一拉起新的 Pod
// 通常只有当应用的新旧版本不兼容(例如依赖的后端数据格式不同且无法兼容)时才会使用 Recreate 重建策略

# kubectl edit deploy -n inadm recreate-demo
...
      - image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.1

upload successful

upload successful

upload successful

4.6 rollingupdate

  • 什么是滚动更新：一次仅更新一批 Pod，当更新的 Pod 就绪后，在更新另一批，知道全部更新完成为止；该策略实现了不间断服务的目标，在更新过程中可能会出现不同的应用版本并存且同时提供服务的情况
    • 1.创建新的 ReplicaSet，然后根据新的镜像运行新的 Pod
    • 2.删除旧 Pod，启动新 Pod，新 Pod 就绪后，继续删除旧 Pod，启动新 Pod
    • 3.持续第二步过程，直到所有 Pod 都被更新成功
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
42
43
44
45
46
47
48
# cat deploy-rollingupdate.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate-demo
  namespace: inadm
spec:
  replicas: 3
  strategy:
    type: RollingUpdate               # 滚动更新，默认策略
  selector:
    matchLabels:
      app: demoapp
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: recreate-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports: 
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: svc-demo
  namespace: inadm
spec:
  selector:
    app: demoapp
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f deploy-rollingupdate.yaml 
# watch -n1 kubectl get pod -n inadm
# while sleep 0.5; do curl http://10.96.184.87/version; done	# 不会中断
// 当将 image 的版本更新到 demoapp:v1.1 后观察如下图变化，会滚动将单个 Pod Kill 掉，再将单个 Pod 拉起，依此类推知道完全启动成功
# kubectl edit deploy -n inadm recreate-demo
...
      - image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.1

upload successful

4.7 rollout

  • 可以通过修改 revisionHistoryLimit 调整保留的数量，默认 10 条
1
2
3
4
# kubectl rollout history deploy -n inadm recreate-demo                        # 查看历史版本
# kubectl rollout history deploy -n inadm recreate-demo --revision=3           # 查看对应 version 对应的具体信息
// 通过命令回滚到特定版本 "1.0" 版本
# kubectl rollout undo deploy -n inadm recreate-demo --to-revision=3

upload successful

upload successful

4.8 deploy 更新策略

  • Deplolyment 会在 .spec.strategy.type=RollingUpdate 时，采取滚动更新方式更新 Pod。可以指定 maxUnavailable 和 maxSurge 来控制滚动更新过程。
    • maxSurge 最大可用 Pod
      • 用来指定可以创建超出期望 Pod 个数的 Pod 数量。可以是数字，可以是百分比。此字段默认值 25%
      • 例如：当此值为 20% 时，启动滚动更新后，会立即对新的 ReplicaSet 扩容，同时保证新旧 Pod 的总数不超过所需 Pod 总数的 120%。一旦旧 Pod 被杀死，新的 ReplicaSet 可以进一步扩容，同时确保更新期间任何时候运行的 Pod 总数最多为所需 Pod 总数的 120%。计算公式: 10+(10*20%)=12
    • maxUnavailable 最大可用 Pod
      • 用来指定更新过程中不可用的 Pod 的个数上线。
      • 例如：当此值设置为 20% 时，滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的 70%。新 Pod 准备就绪后，继续缩容旧的 ReplicaSet，然后对新 ReplicaSet 扩容，确保更新期间可用的 Pod 总数任何时候都是所需的 Pod 个数的 70%。计算公式: 10-(10*20%)=8
  • maxSurge 和 maxUnavailable 两个属性协同工作，可以组合定义出 3 种不同策略完成多批次应用更新
    • 先增新，后减旧：将 maxSurge 设置为 30%，将 maxUnavailable 的值设为 0
    • 先减旧，后增新：将 maxUnavailable 设置为 30%，将 maxSurge 值设置为 0
    • 同时增减，将 maxSurge 和 maxUnavailable 分别设置为 20%，期望是 12 Pod，至少就绪 8 个 Pod

4.8.1 maxSurge

  • 指定升级期间存在的总 Pod 对象数量最多可超出期望值的个数，可以是 0，也可以是整数，也可以是一个百分比
  • 例如：副本数为 10，maxSurge 属性为 2，则表示 Pod 对象总数不能超过 12 个。计算公式: 10+(10*20%)=12
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
42
43
44
45
46
47
48
49
50
# cat pod-maxsurge.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: maxsurge-demo
  namespace: inadm
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxSurge: 20%
      maxUnavailable: 0
  selector:
    matchLabels:
      app: demoapp
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: recreate-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports: 
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: svc-demo
  namespace: inadm
spec:
  selector:
    app: demoapp
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f pod-maxsurge.yaml 
# kubectl get rs -n inadm
// 当将 image 的版本更新到 demoapp:v1.1 后观察如下图变化
// DESIRED 为 12 个
# kubectl edit -n inadm deploy maxsurge-demo
...
      - image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.1

upload successful

4.8.2 maxUnavailable

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
42
43
44
45
46
47
48
49
50
51
# cat deploy-maxUnavailable.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: maxunavailable-demo
  namespace: inadm
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 20%
  selector:
    matchLabels:
      app: demoapp
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: recreate-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports: 
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: svc-demo
  namespace: inadm
spec:
  selector:
    app: demoapp
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f deploy-maxUnavailable.yaml 

// 当将 image 的版本更新到 demoapp:v1.1 后观察如下图变化
// READY 为 8 个
# kubectl edit -n inadm deploy maxunavailable-demo
...
      - image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.1

upload successful

4.8.3 surge 和 unavailable

  • 同时设定 maxsurge 和 maxunavailable
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
42
43
44
45
46
47
48
49
50
51
# cat deploy-max.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: max-demo
  namespace: inadm
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxSurge: 20%
      maxUnavailable: 20%
  selector:
    matchLabels:
      app: demoapp
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: recreate-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports: 
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: svc-demo
  namespace: inadm
spec:
  selector:
    app: demoapp
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f deploy-max.yaml 

// 当将 image 的版本更新到 demoapp:v1.1 后观察如下图变化
DESIRED: 12 个
READY: 8 个
# kubectl edit -n inadm deploy max-demo
...
      - image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.1

upload successful

4.8.4 paused 暂停更新

  • 例如在滚动更新时，发现异常，可以进行更新暂停操作
1
2
3
4
5
6
7
8
9
10
11
# cat deploy-paused.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: max-demo
  namespace: inadm
spec:
  paused: true            # 当更新后，发现异常。及时开启 puased 这个配置选项并 apply，则更新暂停
  replicas: 10
  ......

4.8.5 minreadyseconds

  • deploy 支持使用 spec.minReadySeconds 字段来控制滚动更新的速度，默认值为 0，表示新建的 Pod 对象一旦 “就绪” 将立即被视作可用，随后即可开始下一轮更新过程。如果设定了 spec.minReadySeconds: 5 及表示新建的 Pod 对象至少要成功运行多久才会被视作可用，及就绪之后还要等待指定的 5s 才能开始下一批次的更新。在一个批次内新建的所有 Pod 就绪后再转为可用状态前，更新操作会被阻塞，并且任何一个 Pod 就绪探测失败，都会导致滚动更新被终止。因此，为 minreadySeconds 设定一个合理的值，不仅能够减缓更新的速度，还能够让 deploy 提前发现一部分程序因为 bug 导致的升级故障。
1
2
3
4
5
6
7
8
9
10
11
# cat deploy-minready.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: max-demo
  namespace: inadm
spec:
  # paused: true
  minReadySeconds: 5            # 5s
  replicas: 10
  ......

4.8.6 revisionhistorylimit

  • deploy 保留一部分更新历史中旧版本的 ReplicaSet 对象，当我们执行回滚操作的时候，就直接使用旧版本的 ReplicaSet，在 deploy 资源保存历史版本数量有 spec.revisionHistoryLimit 属性进行定义。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# cat deploy-revi.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: max-demo
  namespace: inadm
spec:
  minReadySeconds: 5            # 5s
  revisionHistoryLimit: 5       # 保留历史版本 5 个。经测试重复的不算入历史记录里
  replicas: 3
...

# kubectl rollout history deploy max-demo -n inadm            # 查看当前指定空间的指定 deploy 保留的更新历史，有 2 次
REVISION  CHANGE-CAUSE
1         <none>
2         <none

4.8.7 progressdeadlineSeconds

  • 滚动更新故障超时时长，默认 600s，k8s 在升级过程中有可能由于各种原因升级卡主（这时还没明确的升级失败），比如在拉取被墙的镜像，权限不够等错误。如果配置 progressDeadlineSeconds，当达到时间还卡着，则会上报这个异常情况，这时 deploy 状态就被标记为 False，并且注明原因。但是它并不会阻止 deploy 继续进行卡住后面的升级操作
1
2
3
4
5
6
7
8
9
10
11
# cat deploy-progress.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: max-demo
  namespace: inadm
spec:
  minReadySeconds: 5              # 5s
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 600    # 默认 600s
...

4.9 deploy 灰度发布

  • 灰度发布（又名金丝雀发布）是指黑与白之间，能够平滑过渡的一种发布方式

4.9.1 deploy v1.0

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
42
# cat deploy-demo-a.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-a
  namespace: inadm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demoapp
      version: v1.0
  template:
    metadata:
      labels:
        app: demoapp
        version: v1.0
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: recreate-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports: 
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: svc-demo
  namespace: inadm
spec:
  selector:
    app: demoapp
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f deploy-demo-a.yaml

4.9.2 deploy v1.1

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
42
# cat deploy-demo-b.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-b
  namespace: inadm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demoapp
      version: v1.1
  template:
    metadata:
      labels:
        app: demoapp
        version: v1.1
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: recreate-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.1
        ports: 
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: svc-demo
  namespace: inadm
spec:
  selector:
    app: demoapp
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f deploy-demo-b.yaml

4.9.3 实现方式

  • 先增加 v1.1 版本的 replicas 副本数量，然后减少 v1.0 版本 replicas 的副本数量，逐步进行切换
  • 其中 deploy 中 selector 有2个标签，svc 中有一个标签
  • 最后在清除下线的 deploy 时，注意不要删除 svc 服务

5.0 daemonset

  • 什么是 DaemonSet：DaemonSet 控制器是用来保证在所有节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod
  • DaemonSet 典型用法:
    • 在每个节点上运行集群存储守护进程：gluster、ceph
    • 在每个节点上运行日志收集守护进程：fluentd、filebeat、logstash
    • 在每个节点上运行监控守护进程：prometheus、node_exporter
    • 在每个节点上运行网络插件为 Pod 提供网络服务：flannel、calico
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: <string>
  namespace: <string>
spec:
  minReadySeconds: <integer>              # Pod 就绪后多少秒内容器无崩溃视为"就绪"
  revisionHistoryLimit: <integer>         # 滚动更新历史记录数量
  selector: <object>                      # 标签选择器
  updateStrategy: <object>                # 滚动更新策略
    type: <string>                        # 滚动更新类型，可用值有 OnDelete 和 RollingUpdate
    rollingUpdate: <object>               # 滚动更新参数，专用于 RollingUpdate 类型
      maxSurge: <string>                  # 滚动更新参数，更新期间存在的总 Pod 对象数量最多可超出期望值的个数
      maxUnavailable: <string>            # 滚动更新参数，升级期间不可用的 Pod 副本数
  template: <object>                      # Pod 模板
    metadata: <object>                    # Pod 名称
    spec: <object>                        # Pod 详情

5.1 示例

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
# cat ds-demo.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ds-demo
  namespace: inadm
spec:
  selector: 
    matchLabels:
      app: nginx
  template: 
    metadata: 
      labels:
        app: nginx
    spec: 
      nodeSelector:                        # 节点选择器，通过标签来选择
        type: ssd-nginx                    # 节点必须存在的标签： key=type、value=ssd-nginx
      containers:
      - name: nginx-container
        image: nginx:1.16
        ports:
        - name: http
          containerPort: 80
        livenessProbe:                     # 存活探针，监听 80端口，如果 80 端口不存在则重启
          tcpSocket:
            port: 80
          initialDelaySeconds: 3
        readinessProbe:                    # 就绪探针，监听 80 端口，如果 80 不存在则重启
          httpGet:
            path: "/"
            port: 80
            scheme: HTTP
          initialDelaySeconds: 5

// 添加节点的标签
# kubectl get nodes --show-labels                            # 查看节点标签
# kubectl label nodes k8s-node01 type=ssd-nginx              # 给节点 node01 打标签
# kubectl get nodes --show-labels k8s-node01                 # 查看 node01 节点的标签信息
// 去掉节点上的标签命令
# kubectl label nodes k8s-node01 type-                       # key=type，将 type 减去

upload successful

5.2 部署 node_exporter

  • 为每个节点运行一份 node_exporter，采集当前节点信息
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# cat ds-nodexport.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-export
  namespace: inadm
  labels:
    app: node-export
spec:
  selector: 
    matchLabels:
      app: node-export
  template: 
    metadata: 
      labels:
        app: node-export
    spec: 
      imagePullSecrets:
      - name: harbor-auth
      hostNetwork: true                   # 共享主机网络
      hostPID: true                       # 获取主机 PID
      hostIPC: true
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: monitor-node-export
        image: harbor.inadm.com/ops_monitor/node-exporter:v1.3.1
        ports:
        - name: node-ex-port
          containerPort: 9100                  # 监听在节点的 9100 端口上
          hostPort: 9100

        livenessProbe:
          tcpSocket:
            port: node-ex-port
          initialDelaySeconds: 3
        readinessProbe:
          httpGet:
            path: "/metrics"
            port: node-ex-port
            scheme: HTTP
          initialDelaySeconds: 5

        resources:
          requests:
            cpu: 150m
            memory: 180Mi
          limits:
            cpu: 150m
            memory: 180Mi
        securityContext:
          runAsNonRoot: true
          runAsUser: 65534

# kubectl apply -f ds-nodexport.yaml 
// 浏览器访问: http://NODE_IP:9100/metrics

upload successful

upload successful

5.3 ds 更新策略

  • ds 也支持更新策略，它支持 OnDelete 和 RollingUpdate：
    • OnDelete：是在相应节点的 Pod 资源被删除后重建新版本，从而运行用户手动编排更新过程
    • RollingUpdate：滚动更新，工作逻辑和 deploy 滚动更新类似

5.3.1 RollingUpdate

  • 将此前创建的 node-expoter 中的 Pod 模板镜像修改为 v1.4.0，测试其更新过程
  • 安装默认的 RollingUpdate 策略，node-exports-ds 资源将采用一次更新一个 Pod 对象，待新建 Pod 的对象就绪后，在更新下一个 Pod 对象，直到全部完成
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
# cat ds-node-expoter.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-export
  namespace: inadm
  labels:
    app: node-export
spec:
  minReadySeconds: 3
  revisionHistoryLimit: 5
  updateStrategy:
    type: RollingUpdate                   # 滚动更新(默认更新策略)
    rollingUpdate:
      maxUnavailable: 1
  selector: 
    matchLabels:
      app: node-export
  template: 
    metadata: 
      labels:
        app: node-export
    spec: 
      imagePullSecrets:
      - name: harbor-auth
      hostNetwork: true                  # 共享主机网络
      hostPID: true                       # 获取主机 PID
      hostIPC: true
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: monitor-node-export
        image: harbor.inadm.com/ops_monitor/node-exporter:v1.4.0
        ports:
        - name: node-ex-port
          containerPort: 9100
          hostPort: 9100                  # 监听在节点的 9100 端口上
        livenessProbe:
          tcpSocket:
            port: node-ex-port
          initialDelaySeconds: 3
        readinessProbe:
          httpGet:
            path: "/metrics"
            port: node-ex-port
            scheme: HTTP
          initialDelaySeconds: 5
        resources:
          requests:
            cpu: 150m
            memory: 180Mi
          limits:
            cpu: 150m
            memory: 180Mi
        securityContext:
          runAsNonRoot: true
          runAsUser: 65534

# kubectl apply -f ds-node-expoter.yaml

upload successful

5.3.2 OnDelete

  • 将此前创建的 node-expoter 中的 Pod 模板镜像更新为 v1.5.0，由于升级版本跨度过大，无法确保升级过程中稳定性，我们就不得不适用 OnDelete 策略来替换默认的 RollingUpdate 策略
  • 由于 OnDelete 并非自动完成升级，它需要管理员手动删除 Pod，然后重新拉起新的 Pod，才能完成更新。（对于升级有着先后顺序的软件这种方法就非常有用）
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
# cat ds-node-expoter.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-export
  namespace: inadm
  labels:
    app: node-export
spec:
  minReadySeconds: 3
  revisionHistoryLimit: 5
  updateStrategy:
    type: OnDelete                   # 使用 OnDelete 更新策略
  selector: 
    matchLabels:
      app: node-export
  template: 
    metadata: 
      labels:
        app: node-export
    spec: 
      imagePullSecrets:
      - name: harbor-auth
      hostNetwork: true                   # 共享主机网络
      hostPID: true                       # 获取主机 PID
      hostIPC: true
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: monitor-node-export
        image: harbor.inadm.com/ops_monitor/node-exporter:v1.5.0
        ports:
        - name: node-ex-port
          containerPort: 9100
          hostPort: 9100                  # 监听在节点的 9100 端口上

        livenessProbe:
          tcpSocket:
            port: node-ex-port
          initialDelaySeconds: 3
        readinessProbe:
          httpGet:
            path: "/metrics"
            port: node-ex-port
            scheme: HTTP
          initialDelaySeconds: 5

        resources:
          requests:
            cpu: 150m
            memory: 180Mi
          limits:
            cpu: 150m
            memory: 180Mi
        securityContext:
          runAsNonRoot: true
          runAsUser: 65534

# kubectl apply -f ds-node-expoter.yaml 
// 手动删除老的 Pod
# kubectl get pod -l app=node-export -n inadm
# kubectl delete pod -l app=node-export -n inadm
// 浏览器访问验证: http://NODE_IP:9100/metrics

upload successful

6.0 job、cronjob

  • 什么是 Job：Job 控制器常用于管理那些运行一段时间就能够 “完成” 的任务，例如离线数据分析，数据备份等，当任务完成后，由 Job 控制器将该 Pod 对象至于 Complete 完成状态，在完成一定时间后，当达到用户指定的生存周期，由系统自动删除任务。如果容器中的进程因 “错误” 而终止，则需要依赖 RestartPolicy 配置来确定是否重启，如果是因为节点故障造成 Pod 意外终止的话，会被重新创建起来继续运行。
    • Pod 执行，退出状态为 0，则表示执行成功，而后将该 Pod 状态置于 Complete
    • Pod 执行，退出状态码为非 0，检查 restartpolicy 为 Never，表示永不重启，而后该 Pod 状态置于 Failure
    • Pod 执行，退出状态码为非0，检查 restartpolicy 为 OnFailure，表示退出状态码如果不为 0 时重启该 Pod，所以会尝试重新拉取 Pod，直到执行成功为止
  • Job 工作方式：
    • 实际生产环境中，有些任务可能需要运行不止一次，用户可以配置他们以串行或并行方式运行起来。
      • 串行 Job：将一个作业串行执行多次知道满足期望的次数
      • 并行 Job：设定工作队列数，同时运行，而每个队列仅运行一个作业
    • 注意：对于有严格次序要求的作业，只能选择串行执行，而没有严格次序要求的可以选择并行来运行的效率和速度
  • job: 运行完便结束：消费者–> 程序 –> Dockerfile –> job –> pod
  • cronjob: 定时执行：消费者–> 程序 –> Dockerfile –> cronjob –> job –> pod

6.1 job 基础资源

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# cat job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: <string>
  namespace: <string>
spec:
  selector: <Object>
  completions: <integer>                    # 期望成功完成作业的次数
  parallelism: <integer>                    # 作业的最大并行度，默认为 1
  backoffiLimit: <integer>                  # 将作业标记为 Failed 之前的重试次数，默认为 6
  activeDeadlineSeconds: <integer>          # 作业启动后可处于活动状态的时长，超出则会被标记为 Failed
  ttlSecondsAfterFinished: <integer>        # 作业的最大生存时长，超期将被删除，0 表示立即删除
  template: <Object>
  spec: <object>
    containers: <Object>
    restartpolicy: <string>

6.2 job 示例代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# cat job-demo.yaml 
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
  namespace: inadm
spec:
  completions: 5                            # 需要成功运行 5 次
  parallelism: 2                            # 并行执行为 2
  backoffLimit: 2                           # 失败后，允许重试 2 次
  activeDeadlineSeconds: 120                # 总活跃时间为 120s，包含运行 Pod 时间+异常重试次数时间
  ttlSecondsAfterFinished: 100              # Job-demo 在结束 100s 之后，会被系统自动删除 (无论执行成功或失败)
  template:
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: job-container
        image: harbor.inadm.com/inadm_kubernetes/tools:latest
        command: ["/bin/bash", "-c", "sleep 3"]
      restartPolicy: OnFailure

# kubectl apply -f job-demo.yaml

upload successful

6.3 并行读取RabbitMQ数据演示

  • 本例中，运行包含多个并行工作进程的 k8s job。文档中，每个 Pod 一旦被创建，会立即从任务重取走一个消息，然后将消息从队列中删除并退出本次任务
  • 示例主要步骤：
    • 启动一个消息队列服务：使用 RabbitMQ
    • 创建一个队列，放上消息数据：每个消息表示一个要执行的任务
    • 启动一个 Job，该 Job 启动多个 Pod：每个 Pod 从消息队列中读走一个任务，处理它，然后重复执行，知道队列的队尾

upload successful

6.3.1 创建 RabbitMQ 服务

  • RabbitMQ 消息队列服务
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
# cat job-rabbitmq-server.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: job-rabbitmq
  namespace: inadm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rbtmq
  template:
    metadata:
      labels:
        app: rbtmq
    spec:
      containers:
      - name: mq-container
        image: rabbitmq
        ports:
        - name: rbt
          containerPort: 5672
        resources:
          limits:
            cpu: 300m

---
apiVersion: v1
kind: Service
metadata:
  name: job-rabbitmq
  namespace: inadm
spec:
  selector:
    app: rbtmq
  ports:
  - name: rbt
    port: 5672
    targetPort: 5672

# kubectl apply -f job-rabbitmq-server.yaml

6.3.2 消息发布者

  • 启动临时容器测试
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 启动 ubuntu18.04 镜像，然后安装一些工具
# kubectl run -it amqp-consume --image ubuntu:18.04
root@temp:/# apt-get update
root@temp:/# apt-get -y install curl ca-certificates amqp-tools python dnsutils

// 验证 RabbitMQ 服务 [手动方式]
root@temp:/# nslookup job-rabbitmq.inadm.svc.cluster.local
root@temp:/# export BROKER_URL=amqp://guest:[email protected]:5672
root@temp:/# /usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo                            // 创建队列
root@temp:/# /usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b inadm                      // 向它推送一条消息
root@temp:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && echo                 // 取消息
    inadm

// 为队列增加任务，创建一个 job1 队列，然后给队列中填充 8 个消息 [脚本方式]
export BROKER_URL=amqp://guest:[email protected]:5672
/usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1
for i in aa bb cc dd ee ff gg hh; do /usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $i; done

6.3.3 消息订阅

  • 创建镜像，获取数据，然后以 Job 方式运行起来
  • 编写获取队列程序
1
2
3
4
5
6
7
// 获取队列数据，然后等待 10s，结束
# cat worker.py
#!/usr/bin/env python
import sys
import time
print("Processing " + sys.stdin.readlines()[0])
time.sleep(10)
  • 编写 Dockerfile
1
2
3
4
5
6
7
8
9
10
11
12
13
// 编写 Dockerfile 文件，制作为镜像，然后推送到自己的仓库；(注意镜像中需要传递的变量)
# cat Dockerfile 
FROM ubuntu:18.04
RUN apt-get update && \
  apt-get -y install curl ca-certificates amqp-tools python dnsutils --no-install-recommends \
  && rm -rf /var/lib/apt/lists/*
COPY ./worker.py /worker.py
RUN chmod +x /worker.py
CMD /usr/bin/amqp-consume --url=$BROKER_URL -q $QUEUE -c 1 /worker.py

# docker build -t rabbit-mq-consumer-job .
# docker tag rabbit-mq-consumer-job:latest harbor.inadm.com/inadm_kubernetes/rabbit-mq-consumer-job:latest
# docker push harbor.inadm.com/inadm_kubernetes/rabbit-mq-consumer-job:latest
  • 编写 Job 任务：每个 Pod 使用队列中的一个消息然后退出。这样， Job 的完成计数就代表了完成的工作项的数量
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
# cat job-rabbitmq-consumer.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: rabbitmq-consumer
  namespace: inadm
spec:
  completions: 8                    # 总共运行 8 次，因为队列中有 8 条消息
  parallelism: 2                    # 并行执行 2 个任务
  ttlSecondsAfterFinished: 1000     # 结束后 1000s 删除
  template:
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: mq-consumer-work
        image: harbor.inadm.com/inadm_kubernetes/rabbit-mq-consumer-job:latest
        env:
        - name: BROKER_URL
          value: amqp://guest:[email protected]:5672
        - name: QUEUE
          value: job1
      restartPolicy: OnFailure

# kubectl apply -f job-rabbitmq-consumer.yaml
1
2
3
4
5
6
7
8
# kubectl describe jobs rabbitmq-consumer -n inadm
# kubectl logs reabbitmq-consumer-xxxx -n inadm            # 通过检查 Pod 的 logs，可以看到消息被取走了
# kubectl describe jobs -n inadm rabbitmq-consumer         # 检查 Job
// 如果设置的完成数量小于队列中的消息数量，会导致一部分消息项不会被执行
// 如果设置的完成数量大于队列中的消息数量，当队列中的所有的消息都处理完成后，Job 也会显示为未完成。Job 将创建 Pod 并阻塞等待消息输入。
// 当发生下面两种情况时，即使队列中所有消息都处理完成了，Job 也不会显示为完成状态
    1. 在 amqp-consume 命令拿到消息和容器成功退出之间的时间段内，执行杀死容器操作
    2. 在 kubectl 向 api-server 传回 Pod 成功运行之前，发生节点崩

upload successful

upload successful

6.4 并行读取redis数据

  • 运行一个 K8s Job，其中 Pod 会运行多个并行工作进程
  • 在例子中，当每个 Pod 被创建时，它会从一个任务队列中获取一个工作单元，处理它，然后重复，直到达到队列尾部
    • 启动 Redis 存储服务用于保存工作队列：在上一个例子中，使用了 RabbitMQ，但无法提供一个良好的方式来检测一个有限长度的工作队列是否为空，所以本次使用 Redis，和一个自定义的工作队列客户端。
    • 创建一个队列，然后向其中填充消息：每个消息表示一个将要被处理的工作任务
    • 启动一个 Job 队列中的人物进行处理：这个 Job 启动了若干个 Pod。每个 Pod 从消息队列中取出一个工作任务，处理它，然后重复，直到到达队列的尾部

upload successful

6.4.1 创建 Redis 服务

  • 部署 redis 消息队列服务
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
# cat job-redis-server.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-deploy
  namespace: inadm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis-server
        image: redis
        ports:
        - containerPort: 6379

---
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: inadm
spec:
  selector:
    app: redis
  ports:
  - port: 6379
    targetPort: 6379

# kubectl apply -f job-redis-server.yaml

6.4.2 消息发布者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 启动临时可交互的 Pod 用于运行 Redis 命令行
# kubectl run -it tmp-redis -n inadm --image redis --command "/bin/sh"

// 连接 Redis 服务，人啊后王队列中添加任务，job2 列表，就是工作队列
redis-cli -h redis.inadm
redis.inadm:6379> rpush job2 "inadm01"
redis.inadm:6379> rpush job2 "inadm02"
redis.inadm:6379> rpush job2 "inadm03"
redis.inadm:6379> rpush job2 "inadm04"
redis.inadm:6379> rpush job2 "inadm05"
redis.inadm:6379> rpush job2 "inadm06"
redis.inadm:6379> rpush job2 "inadm07"
redis.inadm:6379> rpush job2 "inadm08"

redis.inadm:6379> LRANGE job2 0 -1        # 查看输入的值

upload successful

6.4.3 消息订阅

  • 创建镜像，获取数据，然后以 Job 方式运行起来
  • 编写获取队列程序：使用一个带有 Redis 客户端的 python 工作程序从消息队列中读出消息
  • rediswq.py 制作镜像中的一个文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 这里提供了一个简单的 Redis 工作队列客户端库，叫 rediswq.py。然后 Job 中每个 Pod 内的 "工作程序" 使用工作队列客户端库获取数据
# cat worker.py
#!/usr/bin/env python
import time
import rediswq
host="redis.inadm"      # 连接 redis 的 svc 名称
q = rediswq.RedisWQ(name="job2", host=host)
print("Worker with sessionID: " + q.sessionID())
print("Initial queue state: empty=" + str(q.empty()))
while not q.empty():
    item = q.lease(lease_secs=10, block=True, timeout=2)
    if item is not None:
        itemstr = item.decode("utf-8")
        print("Working on " + itemstr)
        time.sleep(10)
        q.complete(item)
    else:
        print("Waiting for work")
print ("Queue empty, exiting")
  • 编写 Dockerfile
1
2
3
4
5
6
7
8
9
10
# Dockerfile
FROM harbor.inadm.com/inadm_kubernetes/python:alpine3.15
RUN pip install redis
COPY ./worker.py /worker.py
COPY ./rediswq.py /rediswq.py
RUN chmod +x /worker.py /rediswq.py
CMD python worker.py

# docker build -t harbor.inadm.com/inadm_kubernetes/redis-mq-consumer-job:v1.0 .
# docker push harbor.inadm.com/inadm_kubernetes/redis-mq-consumer-job:v1.0
  • 编写 Job 任务
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# cat redis-consumer.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: redis-consumber
  namespace: inadm
spec:
  # completions: 1          # 默认 1
  parallelism: 2
  ttlSecondsAfterFinished: 1000
  template:
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: redis-consumber
        image: harbor.inadm.com/inadm_kubernetes/redis-mq-consumer-job:v1.0
      restartPolicy: OnFailure

# kubectl apply -f redis-consumer.yaml
  • 检查
1
2
3
4
5
# kubectl describe jobs redis-consumber -n inadm
# kubectl logs -n inadm redis-consumber-jwstt
// 在这个例子中，每个 Pod 处理了队列中的多个项目，直到队列中没有项目时便退出。因为由工作程序自行检测工作队列是否为空，并且 Job 控制器不知道工作队列的存在，这依赖于工作程序在完成时发出信号。
// 工作程序以成功退出的形式发出信号表示工作队列已经为空。所以，只要有任意一个工作程序成功退出，控制器就知道工作已经完成了，所有的 Pod 将很快会退出。
// 因此，我们将 Job 的完成技术（Complateion count）设置为 1

upload successful

6.5 contjob

  • 什么是 CronJob：CronJob 资源用于管理 Job 资源的运行时间，它允许用户在特定时间或指定时间运行 Job，它适合自动执行特定的任务，例如 备份、报告、发送邮件、垃圾清理。而一个 CronJob 对象就像 crontab 文件中的一行。它用cron 格式进行编写 分 时 日 月 周

upload successful

  • CronJob 并发执行：CronJob 资源的 对象可能不支持同时运行多个实例，用户可基于 spec.concurrencyPolicy 属性来控制多个 CronJob 并存的机制
    • Allow：运行不同时间点的多个 CronJob 实例同时运行（默认）
    • Forbid：CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行
    • Replace：用于让后一个 CronJob 取代前一个，即终止一个并启动后一个
  • 注意：并发性规则仅适用于相同 CronJob 创建的任务。如果有多个不同的 CronJob，它们相应的任务总是允许并发执行的。

6.5.1 CrobJob 基础资源

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: betach/v1
kind: CronJob
metadata:
  name: <string>
  namespace: <string>
spec:
  concurrencyPolicy: <string>                 # 并发策略，可用值有 Allow、Forbid、Replace
  failedJobdsHistoryLimit: <integer>          # 失败作业历史记录数，默认为 1
  successfulJobsHistoryLimit: <integer>       # 成功作业历史记录数，默认为 1
  startingDeadlineSeconds: <integer>          # 因错误时间点而未执行的作业可超期时长
  schedule: <string> -required-               # 调度时间设定，必选字段
  jobTemplate: <Object> -required-            # Job 作业模板，必选字段
    metadate: <Object>
    spec: <Object>
      completions: <integer>                  # 期望成功完成作业的次数
      parallelism: <integer>                  # 作业的最大并行度，默认为 1
      backoffLimit: <integer>                 # 将作业标记为 Failed 之前的重试次数，默认为 6
      activeDeadlineSeconds: <integer>        # 作业启动后可处于活动状态的时长，超出则会被标记为 Failed
      ttlSecondsAfterFinished: <integer>      # 作业的最大生存时长，超期将被删除， 0 表示立即删除
      template: <Object>                      # Pod 模板
        spec: <Object>
          containers: <Object>
          restartPolicy: <string>             # Pod 重启策略，默认的 Always 并不适应，因此必须单独指定
  • CronJob 示例
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
# cat cronjob-demo.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: cronjob-demo
  namespace: inadm
spec:
  failedJobsHistoryLimit: 5           # 保留运行失败的 Job，5条
  successfulJobsHistoryLimit: 5       # 保留运行成功的 Job，5条
  startingDeadlineSeconds: 300        # 错误计划执行时间，而允许延迟启动的最长时间
  schedule: "* * * * *"               # 每分钟执行一次
  jobTemplate:
    spec:
      parallelism: 1                  # 并行执行为 1
      completions: 1                  # 需要成功运行 1 次
      ttlSecondsAfterFinished: 3600   # Job 在结束 3600s 之后，会被系统自动删除(无论执行成功还是失败)
      #activeDeadlineSeconds: 120      # 总活跃时间为 120s，包含运行 Pod时间+异常时间重试次数时间
      template:
        spec:
          imagePullSecrets:
          - name: harbor-auth
          restartPolicy: OnFailure
          containers:
          - name: cronjob-container
            image: harbor.inadm.com/inadm_kubernetes/tools:latest
            command:
            - "/bin/bash"
            - "-c"
            - "echo Hell From CronJob; sleep 5"

# kubectl apply -f cronjob-demo.yaml
# kubectl logs -n inadm cronjob-demo-29219016-p5dtn
Hell From CronJob

upload successful

6.6 每分钟从redis队列获取数据

  • 消费者–> 程序 –> Dockerfile –> cronjob –> job –> pod

6.6.1 消息发布者

1
2
3
4
5
6
7
8
9
1. 创建 redis 服务：参考 6.4.1 
2. 消息发布者
# kubectl exec -it tmp-redis -n inadm -- "/bin/sh"                    # 参考：6.4.2
3. 连接 redis 服务，然后往队列中添加一些任务
# redis-cli -h redis.inadm
redis.inadm:6379> rpush job2 "inadm,cronjob01"
redis.inadm:6379> rpush job2 "inadm,cronjob02"
redis.inadm:6379> rpush job2 "inadm,cronjob03"
redis.inadm:6379> rpush job2 "inadm,cronjob04"

6.6.2 消息发布者

  • 定期获取 Redis 中数据
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
# cat redis-cronjob-consumber.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: redis-consumer-cronjob
  namespace: inadm
spec:
  failedJobsHistoryLimit: 3          # 保留运行失败的 Job，5条
  successfulJobsHistoryLimit: 3       # 保留运行成功的 Job，5条
  startingDeadlineSeconds: 300        # 错误计划执行时间，而允许延迟启动的最长时间
  schedule: "* * * * *"               # 每分钟执行一次
  jobTemplate:
    spec:
      parallelism: 2                  # 并行执行为 1
      completions: 3                  # 需要成功运行 1 次
      ttlSecondsAfterFinished: 300   # Job 在结束 3600s 之后，会被系统自动删除(无论执行成功还是失败)
      #activeDeadlineSeconds: 120      # 总活跃时间为 120s，包含运行 Pod时间+异常时间重试次数时间
      template:
        spec:
          imagePullSecrets:
          - name: harbor-auth
          restartPolicy: OnFailure
          containers:
          - name: cronjob-container
            image: harbor.inadm.com/inadm_kubernetes/redis-mq-consumer-job:v1.0
1
2
3
4
5
6
7
8
9
// 检查
# kubectl describe -n inadm cronjobs.batch redis-consumer-cronjob
# kubectl logs -n inadm redis-consumer-cronjob-29219026-jt4fj 
// 在此发布消息
redis.inadm:6379> rpush job2 "inadm,cronjob05"
redis.inadm:6379> rpush job2 "inadm,cronjob06"
redis.inadm:6379> rpush job2 "inadm,cronjob07"
redis.inadm:6379> rpush job2 "inadm,cronjob08"
# kubectl logs -n inadm redis-consumer-cronjob-29219026-hrjh

upload successful

7.0 service

  • srevice 的作用：

    • 暴露流量：让用户可以通过 ServiceIP + ServicePort 访问对应后端的 Pod 应用
    • 负载均衡：提供基于 4 层的 TCP/IP 负载均衡，并不提供 HTTP/HTTPS 等负载均衡
    • 服务发现：当发现新增 Pod 则自动加入至 Service 的后端，如发现 Pod 异常则自动剔除 Service 后端

  • service 工作逻辑：

    • Service 持续监视 API-Server，监视 Service 标签选择器所匹配的后端 Pod，并实时跟踪这些 Pod 对象的变动情况，例如 IP 地址发生变化、或 Pod 对象新增与减少

    • 不过 Service 并不直接与 Pod 简历关联关系，它们之间还有一个中间层 Endpoints，Endpoints 对象是由一个 IP 地址和端口组成的列表，这些 IP 地址和端口则来自于 Service 标签选择器所匹配到的 Pod，默认情况下，创建 Service 资源时，其关联的 Endpoints 对象会被自动创建

    • Service：用户通过 kbuectl 命令向 apiServer 发送创建 Service 请求，APIServer 收到后存入 etcd

    • ndpoints：获取 Service 所匹配的 Pod 地址，而后将信息写入与 Service 同名的 endpoints 资源中

    • kube-proxy：获取 Service 和 Endpoints 资源的变动，而后生存 iptables 、IPVS 规则，在本级执行

    • ptables：当用户请求 service_ip 时，使用 iptables 的 DNAT 技术将 ServiceIP 的请求调度至 endpoint 保存 ip 列表

  • service 具体实现：

    • 在 k8s 中，Service 只是抽象的一个概念，真正起作用实现负载均衡规则的其实是 kube-proxy 这个进程。它在每个节点上都需要运行一个 kube-proxy，来完成负载均衡规则的创建
      • 创建 Service 资源后，会分配一个随机的 ServiceIP，返回给用户，然后写入 etcd
      • endpoints controller 负责生成和维护所有 endpoints，它会监听 Service 和 Pod 的状态，当 Pod 处于 running 且准备就绪时，endpoints controller 会将 Pod IP 更新到对应 Service 的 endpoints 对象中，然后写入 etcd
      • kube-proxy 通过 API-Server、Endpoints 的资源变动，一旦 Service 或 EndPoints 资源发生变化，kube-proxy 会将最新的信息转换为对应的 iptables、IPVS 访问规则，而后在本地主机执行
      • 当客户端想要访问 Service 的时候，其实访问的就是本地节点上的 iptables、IPVS 规则，由他们路由到对应节点

  • service 资源类型：

    • ClusterIP：通过集群的内部 IP 暴露服务，选择 ServiceIP 只能够在集群内部访问。这也是默认的 ServiceType
    • NodePort：NodePort 类型是对 ClusterIP 类型 Service 资源的扩展。它通过每个节点上的 IP 和端口接入集群外部流量，并分发给后端的 Pod 处理和响应。因此通过 <节点IP>:<节点端口>，可以从几圈外访问服务
    • oadBalance：这类 Service 依赖云厂商，需要通过云厂商调用 API 接口创建软件负载均衡将服务暴露到集群外部。当创建 LoadBalance 类型的 Service 对象时，它会在集群上自动创建一个 NodePort 类型的 Service。集群外部的请求流量会先路由该负载均衡，并由该负载均衡调度至各个节点的 NodePort
    • ExternalName：此类型不是用来定义如何访问集群内服务的，而是把集群外部的某些服务以 DNS、CNAME 方式映射到集群内，从而让集群内的 Pod 资源能够访问外部服务的一种实现方式

7.1 配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Service
metadata:
  name: <string>
  namespace: <string>
spec:
  type: <string>              # svc 类型，默认为 ClusterIP
  selector:                   # 标签选择器，用于匹配对应的 Pod
  ports:                      # svc 端口列表
  - name: <string>            # 端口名称
    protocol: <string>        # 协议，目前支持 TCP、UDP、SCTP、默认 TCP
    port: <integer>           # svc 的端口号
    targetPort: <string>      # 后端目标进程的端口号或名称
    nodePort: <integer>       # 节点端口号，仅适用于 NodePort 和 Loadbalancer 类型
    externalTrafficPolicy:    # 外部流量路由策略， local 表示当前节点处理，cluster 表示向集群范围内调度
    internalTrafficPolicy:    # 内部流量路由策略

7.1.1 ClusterIP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip
  namespace: inadm
spec:
  selector:
    role: web
  #clusterIP: 10.96.x.x         # 自定指定IP，建议还是由 Service 自动分配
  ports:
  - protocol: TCP
    port: 8888
    targetPort: 80

# kubectl apply -f svc-clusterip.yaml

7.1.2 NodePort

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# cat svc-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: svc-nodeport
  namespace: inadm
spec:
  type: NodePort
  selector:
    role: npt
  ports:
  - protocol: TCP
    port: 8888
    targetPort: 80
    nodePort: 32000

# kubectl apply -f svc-nodeport.yaml

upload successful

7.1.3 ExternalName

  • 当查询主机 SERVICE.NAMESPACE.svc.cluster.local 时，集群的 DNS 服务将返回一个值为 www.ink8s.com 的 CNAME 记录访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层面
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
# cat pod-test.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-test
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-test
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0

---
apiVersion: v1
kind: Service
metadata:
  name: svc-externalname
  namespace: inadm
spec:
  type: ExternalName
  externalName: blog.ink8s.com

# kubectl apply -f pod-test.yaml 
# kubectl exec -it pod-test -n inadm -- "/bin/sh"
[root@pod-test /]$dig svc-externalname.inadm.svc.cluster.local @10.96.0.10 +short blog.ink8s.com

7.2 自定义endpoint

  • service 通过 selector 和 Pod 建立关联，k8s 会根据 关联到的 PodIP 信息组合成一个 endpoint。若 service 定义中没有 selector 字段，service 被创建时，endpoint controller 不会自动创建 endpoint
  • 我们可以通过配置清单创建 service，而无需使用标签选择器，而后自行创建一个同名的 endpoint 对象，指定对应的 IP。这种一般用于将外部 MySQL、Redis 等应用引入 k8s 集群内部，让内部通过 service 的方式访问外部资源
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
42
43
44
45
46
47
48
49
50
51
// 1. 准备外部 MySQL 服务，并且允许远程用户访问权限
    10.16.41.152:3306

// 2. 创建 endpoints 资源清单、创建与 endpoint 同名的 service 资源清单
# cat svc-mysql-external-endpoint.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: pod-test
    image: harbor.inadm.com/inadm_kubernetes/tools:latest
---
apiVersion: v1
kind: Endpoints
metadata:
  name: svc-mysql-external
  namespace: inadm
subsets:
  - addresses:
    - ip: 10.16.41.152      # 外部 MySQL IP 地址
    ports:
    - protocol: TCP
      port: 3306            # 外部 MySQL 运行的端口

---
apiVersion: v1
kind: Service
metadata:
  name: svc-mysql-external
  namespace: inadm
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 3306            # 访问 service 的端口
    targetPort: 3306      # 后端应用的端口

# kubectl apply -f svc-mysql-external-endpoint.yaml 
# kubectl get ep -n inadm svc-mysql-external 
# kubectl describe svc -n inadm svc-mysql-external 

// 使用 pod 访问 service，验证能否正常访问 MySQL 服务
# kubectl exec -it pod-tools -n inadm -- /bin/bash
// 测试在 Pod 中可以使用2种方式连接外部MySQL服务
[root@pod-test /]# mysql -h 10.16.41.152 -P3306 -uroot -pink8s.com     		   # service_ip 地址方式
[root@pod-test /]# mysql -h svc-mysql-external.inadm -P3306 -uroot -pink8s.com     # fqdn 方式

upload successful

upload successful

7.3 service相关字段

7.3.1 sessionAffinity

  • 如果要将来自于特定客户端的连接调度至同一 Pod，可以使用 sessionAffinity 基于客户端的 IP 地址进行会话保持
  • 还可以通过 sessionAffinityConfig.clientIP.timeoutSeconds 来设置最大会话停留时间。（默认 10800s，即 3H）
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
42
43
44
45
46
# cat deploy-demoapp.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp
  namespace: inadm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: demoapp-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: svc-session
  namespace: inadm
spec:
  type: NodePort
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  sessionAffinity: ClientIP         # 配置 sessionAffinity 策略
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 60            # 最大会话停留时间 60s

# kubectl apply -f deploy-demoapp.yaml 
# curl svc_ip/version		    # 60s 后，请求保持才会更新

upload successful

7.3.2 externalTrafficPolicy

  • 外部流量策略：当外部用户通过 NodePort 请求 Service，是将外部流量路由到本地节点上的 Pod，或是路由到集群范围的 Pod
    • Cluster(默认)：将用户请求路由到集群范围的所有 Pod 节点，具有良好的整体负载均衡
    • Local：仅会将流量调度至请求的目标节点本地运行的 Pod 对象之上，以减少网络跳跃，降低网络延迟，但当请求指向的节点本地不存在目标 Service 相关的 Pod 对象时直接丢弃该报文
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
42
43
44
45
46
47
48
# cat svc-externaltraffice.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp
  namespace: inadm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: demoapp-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports:
        - name: http
          containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-external-traffic
  namespace: inadm
spec:
  externalTrafficPolicy: Local            # 默认 Cluster 节点
  type: NodePort
  selector:
    app: web
  ports:
  - name: http
    port: 80
    targetPort: 80
    nodePort: 32002

# kubectl apply -f svc-externaltraffice.yaml 

// 外部请求，仅只能使用指定节点IP+PORT才能请求到指定节点的Pod上资源
// 如果 10.10.21.160 node 节点没有 Pod，则无法访问这个节点
# curl http://10.16.41.125:32002/
# curl http://10.16.41.66:32002/
# curl http://10.16.41.196:32002/

upload successful

upload successful

7.3.3 internalTrafficPolicy

  • 本地流量策略：当本地 Pod 对 Service 发起访问时，是将流量路由到本地节点上的 Pod，还是路由到集群范围的 Pod
    • luster (默认)：将 Pod 的请求路由到集群范围的所有 Pod 节点，具有良好的整体负载均衡
    • Local：将请求路由到与发起方处于相同节点的端点，这种机制有助于节省开销，提升效率。但当请求指向的节点本地不存在的目标 Service 相关的 Pod 对象时直接丢弃该报文
  • 注意：在一个 service 上，当 externalTrafficePolicy 已设置为 Local 时，internalTrafficPolicy 则无法使用。换句话说，在一个集群的不同 service 上可以同时使用这2个特性，但在一个 service 上不行

upload successful

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
42
# cat svc-internal.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp
  namespace: inadm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: demoapp-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports:
        - name: http
          containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-internal-traffic
  namespace: inadm
spec:
  internalTrafficPolicy: Local      # 默认 (Cluster)
  selector:
    app: web
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f svc-internal.yaml 
# kubectl exec -it -n inadm pod-test -- /bin/bash
[root@pod-test /]# curl svc_ip/version

upload successful

7.3.4 publishNotReadyAddresses

  • publishNotReadyAddresses: 表示 Pod 就绪探针探测失败，也不会将失败的 PodIP 加入 NotReadyAddresses 列表中
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# cat publishNRA.yaml 
apiVersion: v1
kind: Service
metadata:
  name: svc-internal-traffic
  namespace: inadm
spec:
  publishNotReadyAddresses: true
  internalTrafficPolicy: Local      # 默认 (Cluster)
  selector:
    app: web
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f publishNRA.yaml 
// 当某个 Pod 就绪探针失败后，Pod 也不会被加入到 NotReadyAddresses 列表中，一般不太建议这样加

upload successful

7.4 coredns 策略

  • DNS 策略可以单独对 Pod 进行设定，在创建 Pod 时可以为其指定 DNS 的策略，最终配置会落在 Pod 的 /etc/resolv.conf 文件中，可以通过 pod.spec.dnsPlicy 字段设置 DNS 的策略
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
// 下面演示环境需要的配置
# cat coredns_plicy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-demoapp
  namespace: inadm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: demoapp-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports:
        - name: http
          containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-demoapp
  namespace: inadm
spec:
  selector:
    app: web
  ports:
  - name: http
    port: 80
    targetPort: 80

# kubectl apply -f coredns_plicy.yaml

7.4.1 ClusterFirst

  • ClusterFirst (默认DNS策略)：表示 Pod 内的 DNS 使用集群中配置的 DNS 服务，简单来说就是使用 k8s 中的 coredns 服务进行域名解析。如果解析不成功，会使用当前 Pod 所在的宿主机 DNS 进行解析
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
# cat dns-clusterfirst.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-demoapp
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  dnsPolicy: ClusterFirst
  containers:
  - name: tools
    image: harbor.inadm.com/inadm_kubernetes/tools:latest
    ports:
    - containerPort: 8000

# kubectl apply -f dns-clusterfirst.yaml 

// 下条命令，只是为了确认容器中的 resolv.conf 是否为 k8s 集群中的 nameserver
# kubectl exec -it -n inadm pod-demoapp -- cat /etc/resolv.conf            # 容器中是默认的svc dns 解析，如果请求的是非容器中的解析，则会使用节点的 resolv.conf 的解析
search inadm.svc.cluster.local svc.cluster.local cluster.local 
nameserver 10.96.0.10
options ndots:5


# kubectl exec -it -n inadm deploy-demoapp-c748d6844-8bjvq -- /bin/sh
$nslookup svc-demoapp.inadm
$nslookup www.ink8s.com

upload successful

7.4.2 ClusterFirstWithHostNet

  • 某些场景下，我们的 Pod 是用 HostNetwork 模式启动的，一旦使用 Hostnetwork 模式，那该 Pod 则会使用当前宿主机的 resolv.conf 来进行 DNS 查询，但如果任然继续使用 k8s 的 DNS 服务，那就将 dnsPolicy 设置为 ClusterFirestWithHostNet
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
# cat dns-withhostnet.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dns-withhostnet
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  hostNetwork: true                          # 与当前 Pod 所在 NODE 节点共享 resolv.conf 配置
  #dnsPolicy: ClusterFirstWithHostNet        # 如果配置了这条，其实就等同于 ClusterFirst 默认策略了，相当于 hostNetwork 不需要配置。如果内网有 dns，待验证是否可以使用内网 dns
  containers:
  - name: dns-withhostnet
    image: harbor.inadm.com/inadm_kubernetes/tools:latest
    ports:
    - containerPort: 8000

# kubectl apply -f dns-withhostnet.yaml

// 此 Pod 采用 "hostNetwork: true" 方式则仅调用了 宿主机的 resolv.conf 配置
# kubectl exec -it dns-withhostnet -n inadm -- cat /etc/resolv.conf
nameserver 8.8.4.4
nameserver 8.8.8.8

// 如果启用了 "dnsPolicy: ClusterFirstWithHostNet" 配置，则等同于 "ClusterFirst" 配置(如果内网有 dns，待验证是否可以使用内网 dns)
# kubectl exec -it dns-withhostnet -n inadm -- cat /etc/resolv.conf
search inadm.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

7.4.3 Default

  • 默认使用宿主机的 resolv.conf 但可以使用 kubelet 的 –resolv-conf=/etc/resolv.conf 来指定 DNS 解析文件地址
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# cat dns-default.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dns-default
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  dnsPolicy: Default
  containers:
  - name: dns-default
    image: harbor.inadm.com/inadm_kubernetes/tools:latest
    ports:
    - containerPort: 8000

# kubectl apply -f dns-default.yaml 
# kubectl exec -it -in inadm dns-default -- cat /etc/resolv.conf
nameserver 8.8.4.4
nameserver 8.8.8.8

7.4.4 None

  • 空的 DNS 设置，这种方式一般用于自定义 DNS 配置的场景，往往需要和 dnsConfig 一起使用才可以达到自定义的 DNS 的目的
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
// 如果生产环境不便于 apply 应用文件，则可以采用 edit 修改 svc 然后将 svc 文件调整好待下次更新时调整及下次 apply 永久生效
# cat dns-none.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dns-none
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 10.96.0.10
      - 223.5.5.5
    searches:
      - cluster.local
      - svc.luster.local
      - default.svc.cluster.local
      - inadm.svc.cluster.local
      - ink8s.com
    options:
      - name: ndots
        value: "5"
  containers:
  - name: dns-none
    image: harbor.inadm.com/inadm_kubernetes/tools:latest
    ports:
    - containerPort: 8000

# kubectl apply -f dns-none.yaml 
# kubectl exec -it -n inadm dns-none -- cat /etc/resolv.conf
search cluster.local svc.luster.local default.svc.cluster.local inadm.svc.cluster.local ink8s.com
nameserver 10.96.0.10
nameserver 223.5.5.5
options ndots:5

7.5 headless

  • 什么是 HeadLess：HeadlessService 也叫无头服务，就是创建的 Service 没有 ClusterIP，而是为 Service 所匹配的每个 Pod 都创建一条 DNS 的解析记录，这样每个 Pod 都有一个唯一的 DNS 名称标识身份，访问的格式如 [SERVICE_NAME.NAMESPACE.svc.cluster.local]
  • HeadLess 作用：像 elasticsearch、mongodb、kafka 等分布式服务，在做集群初始化时，配置文件中要写上集群中所有节点的 IP(或是域名)但 Pod 是没有固定 IP 的，所以配置文件里写 DNS 名称是最合适的。
    • 那为什么不用 service，因为 service 作为 Pod 前置负载均衡，一般是为一组相同的后端 Pod 提供访问入口，而且 service 的 selector 也没有办法区分同一组 Pod 的 不同身份
    • 但是我们可以使用 statefulset 控制器，它在创建每个 Pod 的时候，能为每个 Pod 做一个编号，就是为了能区分这一组 Pod 的不同角色，各个节点的角色不会变的混乱，然后再创建 headless service 资源，集群内的节点通过 Pod名称+序号.service名称，来进行彼此间通信的，只要序号不变，访问就不会出错
    • {statefulSet name}-{编号}.{headless service}.{namespace}.svc.cluster.local
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
42
43
44
45
46
# cat headless.yaml
apiVersion: v1
kind: Service
metadata:
  name: svc-headless
  namespace: inadm
spec:
  clusterIP: "None"                   # 设置为 None，表示无头服务
  selector:
    app: nginx
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: inadm
spec:
  serviceName: "svc-headless"        # 要与 Headless 名称保持一致
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - containerPort: 80
        

// 进入测试 Pod 验证是轮询的，能获得 web-0 和 web-1 的 IP
# kubectl exec -it -n inadm pod-tools -- /bin/bash
ping svc-headless.inadm.svc.cluster.local

// 单独解析 Pod 的 DNS
# ping web-0.svc-headless.inadm.svc.cluster.local
# ping web-1.svc-headless.inadm.svc.cluster.local

upload successful

upload successful

微信

加微信,入技术群

微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

运维技术面：
1. Linux 基础、脚本、服务部署、虚拟化
2. Linux 自动化、服务器硬件
3. Kubernetes、kube 服务部署
4. Windows 客户端,服务端的便捷应用

微信： wnn_chat

写博客的动力,源自于个人爱好!