kubernetes 资源对象

  • kubernetes 资源对象
    • 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 重启策略

  • restartPolicy(重启策略):
    • Always:当容器终止退出后，总是重启容器，默认策略
    • OnFailure:当容器异常退出(退出状态码非0)时，才重启容器
    • Never:当容器终止退出，从不重启容器

1.3 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.4 获取私有仓库镜像

1.4.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.4.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.5 传递环境变量

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.6 自定义容器命令与参数

  • 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
9
// 通过 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
# 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
# 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
# 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
# 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：用户通过 kubectl 命令向 apiServer 发送创建 Service 请求，APIServer 收到后存入 etcd
    • nedpoints：获取 Service 所匹配的 Pod 地址，而后将信息写入与 Service 同名的 endpoints 资源中
    • kube-proxy：获取 Service 和 Endpoints 资源的变动，而后生存 iptables 、IPVS 规则，在本级执行
    • iptables：当用户请求 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 >:< 节点端口 >，可以从几圈外访问服务
    • loadBalance：这类 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

8.0 ingress

8.1 ingress 资源清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: networking.k8s.io/v1        # 资源所属的 API 群组和版本
kind: Ingress
metadata:
  name:  <string>
  namespace: <string>
spec:
  ingressClassName: "nginx"             # 适配 Ingress 控制器类别，必须明确指定
  rules: <[]Object>                     # Ingress 规则列表
  - host: <string>                      # 虚拟主机的 FQDN，俗称域名
    http: <Object>
      paths: <[]Object>                 # 虚拟主机 PATH 定义的列表，有 path 和 backend 组成
      - path: <string>                  # 匹配以什么开头，类似 nginx 中 location 的作用
        pathType: <string>              # Prefix 前缀匹配，不区分大小写 Exact 精确匹配 URL，区分大小写
        backend: <Object>
          service: <Object>             # 关联后端 svc
            name: <string>              # 后端 svc 名称
            port: <Object>              # 后端 svc 端口
              name: <string>            # 端口名称
              number: <integr>          # 端口号

8.2 ingress 基于 url 实现路由

  • 将来自同一域名，不同 URL 请求调度到不同 svc

upload successful

  • 因后端 Pod 无法处理 /app 这样的接口，所以需要调整代理到后端的路径
    • 默认 URL：用户请求 url.inadm.com/app，代理到后端请求也会带上 /app，后端无法处理该 url，就会报错
    • 修改 URL：用户请求 url.inad.com/app，代理到后端后，将请求的 /app 删除，url 为 url.inadm.com/

8.2.1 demoapp 应用

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

---
apiVersion: v1
kind: Service
metadata:
  name: svc-web-url
  namespace: inadm
spec:
  selector:
    app: url-web
  ports:
  - port: 80
    targetPort: 80

# kubectl apply -f ing-deploy-web.yaml

8.2.2 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# cat ing-deploy-tomcat.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ing-tomcat-url
  namespace: inadm
spec:
  replicas: 2
  selector:
    matchLabels:
      app: url-tomcat
  template:
    metadata:
      labels:
        app: url-tomcat
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: url-container
        image: harbor.inadm.com/inadm_kubernetes/tomcat:9.0.63
        ports:
        - containerPort: 8080
        lifecycle:
          postStart:
            exec:
              command:
              - "/bin/bash"
              - "-c"
              - "cp -rf /usr/local/tomcat/webapps.dist/* /usr/local/tomcat/webapps"

---
apiVersion: v1
kind: Service
metadata:
  name: svc-tomcat-url
  namespace: inadm
spec:
  selector:
    app: url-tomcat
  ports:
  - port: 8080
    targetPort: 8080

# kubectl apply -f ing-deploy-tomcat.yaml

8.2.3 ing 配置

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 ing-web-tomcat.yaml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: url-ing
  namespace: inadm
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"   # 关键：启用正则
    nginx.ingress.kubernetes.io/rewrite-target: /$2   # 配置 Rewrite 规则;捕获组$2对应(.*)
spec:
  ingressClassName: "nginx"
  rules:
  - host: url.inadm.com
    http:
      paths:
      - path: /app(/|$)(.*)
        #pathType: Prefix
        pathType: ImplementationSpecific  # 使用正则时必须用此类型
        backend:
          service:
            name: svc-web-url
            port:
              number: 80
      - path: /java(/|$)(.*)
        #pathType: Prefix
        pathType: ImplementationSpecific  # 使用正则时必须用此类型
        backend:
          service:
            name: svc-tomcat-url
            port:
              number: 8080

# kubectl apply -f ing-web-tomcat.yaml

8.2.4 验证

upload successful

upload successful

8.3 多域名

  • 将来自不同域名的请求调度到不同 svc

upload successful

8.3.1 app 应用

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
# cat ing-app-domian.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ing-app-domain
  namespace: inadm
spec:
  replicas: 2
  selector:
    matchLabels:
      app: app-domain
  template:
    metadata:
      labels:
        app: app-domain
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: app-container
        image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
        ports:
        - containerPort: 80

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

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-app-domain
  namespace: inadm
spec:
  ingressClassName: "nginx"
  rules:
  - host: app.inadm.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: svc-app-domain
            port:
              number: 80

# kubectl apply -f ing-app-domian.yaml

8.3.2 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
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
# cat ing-tomcat-domian.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ing-tomcat-domain
  namespace: inadm
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tomcat-domain
  template:
    metadata:
      labels:
        app: tomcat-domain
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: domain-container
        image: harbor.inadm.com/inadm_kubernetes/tomcat:9.0.63
        ports:
        - containerPort: 8080
        lifecycle:
          postStart:
            exec:
              command:
              - "/bin/bash"
              - "-c"
              - "cp -rf /usr/local/tomcat/webapps.dist/* /usr/local/tomcat/webapps"

---
apiVersion: v1
kind: Service
metadata:
  name: svc-tomcat-domain
  namespace: inadm
spec:
  selector:
    app: tomcat-domain
  ports:
  - port: 8080
    targetPort: 8080

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-tomcat-domain
  namespace: inadm
spec:
  ingressClassName: "nginx"
  rules:
  - host: tomcat.inadm.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: svc-tomcat-domain
            port:
              number: 8080

# kubectl apply -f ing-tomcat-domian.yaml

8.3.2 验证

upload successful

upload successful

upload successful

8.4 ing 实现 https

  • 在 ingress 中引用 secret 资源，然后告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡的通道
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
// 创建 secrets (证书文件提前准备好)
# kubectl create secret tls app-inadm-com -n inadm --key=app.inadm.com.key --cert=app.inadm.com.pem

# cat ing-app-tls.yaml 			# 以 "8.3.1 app应用"为例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-app-domain
  namespace: inadm
spec:
  ingressClassName: "nginx"
  tls:                                  # https
  - hosts:
    - app.inadm.com
    secretName: app-inadm-com           # secrets 资源名称
  rules:
  - host: app.inadm.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: svc-app-domain         # svc name
            port:
              number: 80

# kubectl apply -f ing-app-tls.yaml

8.5 ing 自定义配置

  • annotations: 局部 –> server {} ==> 认证、限速 …
  • configmap: 全局 –> http {} ==> 参数优化、压缩 …

8.5.1 自定义 basic 认证

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
# yum -y install httpd-tools
# htpasswd -c auth admin                # 生成一个 auth 文件,名字必须是 auth
New password: ink8s.com
Re-type new password: ink8s.com
# kubectl create secret generic basic-auth --from-file=auth -n inadm
# kubectl get secret basic-auth -n inadm -o yaml
# cat ing-auth-basic.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-tomcat-domain
  namespace: inadm
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic                    # 认证类型
    nginx.ingress.kubernetes.io/auth-secret: basic-auth             # 包含用户和密码的 secret 资源名称
    nginx.ingress.kubernetes.io/auth-realm: 'Please User password'  # 要显示的信息
spec:
  ingressClassName: "nginx"
  rules:
  - host: tomcat.inadm.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: svc-tomcat-domain         # svc name
            port:
              number: 8080

# kubectl apply -f ing-auth-basic.yaml 
// http://tomcat.inadm.com

upload successful

8.5.2 全局参数优化

  • 如果相对 ingress 进行全局配置，可以通过 configmap 资源来实现，Pod 默认加载了一个 ConfigMap 资源 “ingress-nginx”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# kubectl get cm -n ingress-nginx ingress-nginx-controller
// 需要注意下划线都为中横线
# kubectl edit configmaps ingress-nginx-controller -n ingress-nginx
data:
  proxy-connect-timeout: "120"            # 与代理服务连接的超时时间，默认75s
  proxy-read-timeout: "120"               # 从代理服务器读取响应的超时（秒）
  upstream-keepalive-connections: "500"   # 缓存到后端的最大空闲连接数，默认320
  upstream-keepalive-requests: "1000"     # 长连接最大支持的请求数，达到后则关闭连接，默认10000
  upstream-keepalive-timeout: "120"       # 后端空闲连接数最大保留多长时间，默认60s
  max-worker-connections: "65535"         # worker最大连接数，默认16384
  max-worker-open-files: "10240"          # 进程可以打开的最大文件数。默认1024
  ssl-protocols: "TLSv1.2 TLSv1.3"
  ssl-session-cache: "true"               # 开启ssl缓存；
  ssl-session-cache-size: "30m"           # ssl缓存大小；
  ssl-session-timeout: "1024m"            # ssl缓存的超时时间

// 验证
# kubectl get pod -n ingress-nginx        # 找到 ingress-nginx-controller POD 名
# kubectl exec -it -n ingress-nginx ingress-nginx-controller-6mv4t -- grep --color "ssl_session_timeout" /etc/nginx/nginx.conf 
# kubectl exec -it -n ingress-nginx ingress-nginx-controller-6mv4t -- grep --color "connections" /etc/nginx/nginx.conf

upload successful

upload successful

9.0 configmap

9.1 创建 cm

9.1.1 命令创建 cm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 1.使用 kubectl create configmap 命令 使用 --from-literal 选项给出键值对来创建 ConfigMap
# kubectl create configmap nginx-command-cm --from-literal=nginx.host='0.0.0.0' --from-literal=nginx.port='8899' -n inadm

// 2.可以看到，cm 资源没有 spec 和 status，而是直接使用 data 字段嵌套数据
# kubectl get cm -n inadm nginx-command-cm -o yaml
apiVersion: v1
data:
  nginx.host: 0.0.0.0
  nginx.port: "8899"
kind: ConfigMap
metadata:
  creationTimestamp: "xxx"
  name: nginx-command-cm
  namespace: inadm
  resourceVersion: "2100281"
  uid: 52a58946-3fb9-4db0-91e2-27979a55757f

9.1.2 文件创建 cm

  • cm 资源也可以为应用程序提供大段配置，这些大段配置通常保存在一个或多个文件中，可以使用 kubectl create cm 命令，通过 –from-file 选项一次加载一个配置文件的内容为指定的键值。默认文件为 key，文件内容为 values
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# cat cm-nginx-server.conf
server {
    listen  80;
    server_name app.inadm.com;

    location / {
        root    /usr/share/nginx/html;
        index   index.html;
    }

    include /etc/nginx/conf.d/*.cfg;
}

# cat cm-nginx-status.cfg
location /ngx_status {
    stub_status;
    access_log off;
}

// 一个直接使用 cm-nginx-server.conf 作为 key 名称，另一个 status.cfg 作为键名称
# kubectl create cm nginx-conf --from-file=cm-nginx-server.conf --from-file=status.cfg=cm-nginx-status.cfg -n inadm
# kubectl describe -n inadm cm nginx-conf

upload successful

9.1.3 目录创建 cm

  • 对于配置文件较多且无需自定义键名称的场景，可以直接在 kubectl cm 命令的 –from-file 选项上附加一个目录路径就能将该目录下的所有文件创建于同一个 cm 资源中，各文件名即为键名称
1
2
3
4
5
6
7
# ls k8s-cm 目录中包含如下3个文件
    cm-nginx-gzip.cfg
    cm-nginx-server.conf    # 
    cm-nginx-status.cfg     # 基于上面以创建的文件继续使用
# cat cm-nginx-gzip.cfg
    gzip    on;
# kubectl create cm cm-nginx-conf-dir --from-file=../k8s-cm/ -n inadm        # 目录中所有文件都保存到 cm-nginx-conf-dir 对象中

9.1.4 yaml 文件创建 cm

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 cm-app-config.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-app-config
  namespace: inadm
data:
  host: 0.0.0.0
  port: "8888"
  nginx-server.conf: |
    server {
        listen  80;
        server_name app.inadm.com;
    
        location / {
            root    /usr/share/nginx/html;
            index   index.html;
        }
    
        include /etc/nginx/conf.d/*.cfg;
    }
  nginx-status.conf: |
    location /ngx_status {
        stub_status;
        access_log off;
    }

# kubectl apply -f cm-app-config.yaml 
# kubectl describe -n inadm cm cm-app-config

upload successful

9.2 引用 cm

  • 通过环境变量引用 cm 键值
  • Pod 清单中除了使用 value 字段直接给定变量之外，还支持 valueFrom 字段嵌套 configMapKeyRef 来引用 ConfigMap 对象的键值，具体格式如下
1
2
3
4
5
6
7
env:
- name: <string>            # 要赋值的环境变量名称
  valueFrom:                # 定义变量的引用
    configMapkeyRef:        # 变量来自于 configmap 对象
      name: <string>        # configmap 对象的名称(因为有很多 cm，需要制定具体的名称)
      key: <string>         # cm 的键名称
// 这种方式赋值环境变量与直接赋值环境变量方式并无区别，它们都可以用于容器的启动脚本或直接传递给容器引用等

9.2.1 env 引用变量

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 cm-env-conf.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-var-conf
  namespace: inadm
data:
  demoapp.host: "0.0.0.0"
  demoapp.port: "8888"

---
apiVersion: v1
kind: Pod
metadata:
  name: cm-env-app
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: cm-pod-env
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    env:
    - name: HOST
      valueFrom:
        configMapKeyRef:
          name: cm-var-conf
          key: demoapp.host
    - name: PORT
      valueFrom:
        configMapKeyRef:
          name: cm-var-conf
          key: demoapp.port

# kubectl apply -f cm-env-conf.yaml 
# kubectl exec -n inadm cm-env-app -- netstat -nlaput            # 验证

upload successful

9.2.2 挂载卷引用 cm

  • 使用环境变量方式导入 cm 对象中来源较长的文件内容，会导致占据过多的内存空间，同时也不支持内容的动态更新
  • 其次该类数据主要用于为容器提供配置文件，所以将其内容直接通过挂载方式进行引用，会是一种更好的选择
  • 引用了 9.1.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
// 引用整个存储卷：将 cm 对象的每个键名转为容器挂载点路径下的一个文件名，所以每个建明应该设计为对容器应用加载的配置文件名称
// 1.启动一个 nginx_pod，然后将此前创建的 cm-nginx-conf-dir 引用至容器的 /etc/nginx/conf.d 目录中
# cat cm-nginx-all-volume.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-volume-all-cm
  namespace: inadm
spec:
  containers:
  - name: cm-nginx-volume
    image: nginx
    imagePullPolicy: IfNotPresent
    volumeMounts:                           # 将 nginx-conf-dir 挂载到 /etc/nginx/conf.d 目录下
    - name: nginx-conf-dir
      mountPath: /etc/nginx/conf.d/
  volumes:                                  # nginx-conf-dir 内容来源于 cm 中的 cm-nginx-conf-dir 资源
  - name: nginx-conf-dir
    configMap:
      name: cm-nginx-conf-dir               # cm-nginx-conf-dir 资源中引用了 3 个配置文件

# kubectl apply -f cm-nginx-all-volume.yaml 
# kubectl exec -it nginx-volume-all-cm -n inadm -- ls /etc/nginx/conf.d/
    cm-nginx-gzip.cfg  cm-nginx-server.conf  cm-nginx-status.cfg
# curl pod_ip/ngx_status            # 访问 ngx_status，看是否可以打开状态页

upload successful

9.2.3 引用存储卷部分键值

  • 有些应用场景中，用户可能期望仅向容器中挂载指定几个键，例如前面创建名为 cm-app-config 里面有 4 个键，其中 host、port 能为 demoapp 容器定义监听地址及端口，而 nginx-server.conf 、nginx-status.conf 能为 nginx 提供一个虚拟主机站点以及该虚拟站点的状态信息
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 cm-app-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-app-config
  namespace: inadm
data:
  host: 0.0.0.0             # key: value
  port: "8888"              # key: value
  nginx-server.conf: |      # key
    server {
        listen  80;
        server_name app.inadm.com;
    
        location / {
            root    /usr/share/nginx/html;
            index   index.html;
        }
    
        include /etc/nginx/conf.d/*.cfg;
    }
  nginx-status.conf: |
    location /ngx_status {
        stub_status;
        access_log off;
    }
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
# cat cm-nginx-demoapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: demoapp-nginx-cm
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: cm-nginx-containers
    image: harbor.inadm.com/ops_apps_tools/nginx:1.16
    # imagePullPolicy: IfNotPresent
    imagePullPolicy: Always
    volumeMounts:
    - name: cm-ngx-conf
      mountPath: /etc/nginx/conf.d/
  - name: cn-demoapp-containers
    image: harbor.inadm.com/inadm_kubernetes/demoapp:v1.0
    env:
    - name: PORT
      valueFrom:
        configMapKeyRef:
          name: cm-app-config
          key: port
    - name: HOST
      valueFrom:
        configMapKeyRef:
          name: cm-app-config
          key: host
  volumes:
  - name: cm-ngx-conf
    configMap:
      name: cm-app-config               # cm-ngx-conf 引用 cm-app-config 的 cm 资源
      items:                            # 引用部分键采用 items
      - key: nginx-server.conf
        path: app.inadm.com.conf        # 对应的键在挂载点目录映射的文件名称(必写)
        mode: 0644                      # 文件权限
      - key: nginx-status.conf
        path: nginx-status.cfg          # include 引用的 *.cfg 所以这里必须是 .cfg 结尾
        mode: 0644

// 验证
# curl http://POD_IP/ngx_status
# kubectl exec -it demoapp-nginx-cm -c cn-demoapp-containers -n inadm -- netstat -nlaput

upload successful

9.2.4 引用存储卷单个键值

  • 前面两种方式中，无论是装在 cm 对象中的所有文件还是部分文件，挂载点目录下原有的文件都会被隐藏。(打开刚在创建的 nginx 容器验证，看默认的 default.conf 配置文件是否还存在)
  • 对于期望将 cm 对象提供的配置文件补充在挂载点目录下的需求来说，这种方法难以实现，好在我们可以通过容器上的 volumeMounts 字段 subpath 来解决
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
// 1.运行一个 nginx_Pod，将 cm-app-config 中 nginx-server.conf、nginx-status.conf 挂载进来测试
# cat cm-nginx-subpath.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cm-nginx-pod-subpath
  namespace: inadm
spec:
  volumes:
  - name: cm-nginx-volume-subpath
    configMap:
      name: cm-app-config
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: cm-nginx-subpath-containers
    image: harbor.inadm.com/ops_apps_tools/nginx:1.16
    imagePullPolicy: Always
    volumeMounts:
    - name: cm-nginx-volume-subpath
      mountPath: /etc/nginx/conf.d/app.inadm.com.conf               # 挂载容器对应的路径(属于附加，不是覆盖)
      subPath: nginx-server.conf
    - name: cm-nginx-volume-subpath
      mountPath: /etc/nginx/conf.d/app.inadm.com.cfg
      subPath: nginx-status.conf

# kubectl exec -it cm-nginx-pod-subpath -c cm-nginx-subpath-containers -n inadm -- ls -l /etc/nginx/conf.d/	# 可以看到 default.conf 原文件
# curl HHost:app.inadm.com http://POD_IP/ngx_status

upload successful

9.3 redis 结合 cm

  • 使用 redis 配置的值创建一个 cm 文档
  • 创建一个 redis_pod，挂载并使用创建的 cm
  • 验证配置已经被正确应用
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 cm-redis.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-redis
  namespace: inadm
data:
  redis-cfg: |
    bind 0.0.0.0
    port 6380
    maxclients 200000
    maxmemory 2mb
    requirepass ink8s.com
---
apiVersion: v1
kind: Pod
metadata:
  name: cm-pod-redis
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: redis-server-container
    image: harbor.inadm.com/ops_apps_tools/redis:latest
    command:
    - redis-server
    - "/redis-master/redis.conf"
    volumeMounts:
    - name: cm-redis-config                         # cm-redis-config 挂载到 /redis-master/redis.conf
      mountPath: /redis-master/redis.conf
      subPath: redis-cfg
  volumes:
  - name: cm-redis-config
    configMap:
      name: cm-redis

# kubectl exec -it -n inadm cm-pod-redis -- /bin/bash
/data# redis-cli -p 6380
127.0.0.1:6380> auth ink8s.com

10.0 secret

  • secret 资源类别：
    • docker-registry：用于认证 Docker Registry 的 Secret，以便于用户能使用私有容器镜像
    • generic：基于本地文件、目录或命令行创建的 Secret，一般用于存储密码、秘钥、等信息
    • tls：基于指定的公钥和私钥对来创建 TLS Secret，专用于 TLS 通信

10.1 创建 secret

10.1.1 命令创建 secret

  • 使用 secret 为容器中运行的服务提供用于认证的用户名和密码是一种常见的应用场景，像 MySQL 镜像就支持通过环境变量来设置管理员用户的默认密码
1
2
3
4
// 比如: 创建一个名为 mysql-root-auth 的 secret 资源，用户名使用 username 键名，密码使用 password 键名
# kubectl create secret generic mysql-root-auth -n inadm --from-literal=username=root --from-literal=password=ink8s.com
# kubectl get secret mysql-root-auth -n inadm -o yaml
# echo cm9vdA== | base64 -d

upload successful

10.1.2 文件创建 Secret

  • Secret 中包含 Pod 访问数据库所需的用户凭证，除了通过命令行创建，也可以通过文件方式创建。将用户名存储在文件 username.txt 中，将密码存储在文件 password.txt 中
1
2
3
4
5
6
7
8
// 1.准备好对应的用户名文件以及密码文件
// "-n" 表示文本末尾不包含额外换行符。因为 kubectl 读取文件并将内容编码为 base64 时，多余的换行符也会被编码
# echo -n 'admin' > username.txt
# echo -n 'ink8s.com' > password.txt
# kubectl create secret generic mysql-inadm-auth -n inadm --from-file=username.txt --from-file=password.txt
// 默认 key 名称为文件名。可以使用 --from-file=[key=]source 来设置 key 名称
    kubectl create secret generic mysql-inadm-auth -n inadm --from-file=user=username.txt --from-file=pass=password.txt
# kubectl get secrets mysql-inadm-auth -n inadm -o yaml

upload successful

10.1.3 TLS secret

1
2
3
# kubectl create secret tls app-inadm-com -n inadm --key=app.inadm.com.key --cert=app.inadm.com.pem
# kubectl get secret -n inadm app-inadm-com -o yaml
// 同样可以使用 echo xxx | base64 -d 反解析

10.1.4 docker registry

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# kubectl create secret docker-registry image-auth \
  --docker-server=harbor.inadm.com \
  --docker-username=admin \
  --docker-password=ink8s.com \
  [email protected] \                            # 可选
  -n inadm
  
# kubectl get secrets image-auth -n inadm

// yaml 中需写
...
apiVersion: v1
kind: Pod
metadata:
  name: secret
  namespace: inadm
spec:
  imagePullSecrets:
  - name: image-auth
...

10.1.5 secret 清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 1. 创建一个用户名 admin ，密码为 ink8s.com 的 Secret 对象，首先 用户名和密码做 base64 编码
# echo -n "admin" | base64
YWRtaW4=
# echo -n "ink8s.com" | base64
aW5hZG0uY29t

# cat secret-demo01
apiVersion: v1
kind: Secret
metadata:
  name: secret-demo01
  namespace: inadm
data:
  user: YWRtaW4=
  pass: aW5rOHMuY29t

# kubectl apply -f secret-demo01 
# kubectl describe secret -n inadm secret-demo01
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 2. 通过 Data 定义资源清单需要实现进行编码，如果使用 stringData 则直接输入明文信息，而后程序自动完成编码存储至 Data
# cat secret-demo02
apiVersion: v1
kind: Secret
metadata:
  name: secret-demo02
  namespace: inadm
stringData:
  username: "admin"
  passname: "ink8s.com"

# kubectl apply -f secret-demo02 
# kubectl describe secret -n inadm secret-demo02
# kubectl get secret -n inadm secret-demo02 -o yaml
# echo aW5rOHMuY29t | base64 -d

10.2 pod 引用 secret

10.2.1 env 引用 Secret

  • Pod 资源以环境变量方式获取 Secret 数据，存在两种方式
    • 将指定键传递给环境变量，一个一个传递，通过 env.valueFrom 字段实现
    • 将 Secret 对象上的全部键一次性全部映射为容器的环境变量，通过 envFrom 字段实现
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
// 将此前创建 secret-demo01 变量挨个传递给系统环境变量，将 secret-demo02 一次导入到系统环境变量
# cat secret-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-nignx-pod
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: secret-nginx-container
    image: harbor.inadm.com/ops_apps_tools/nginx:1.16
    env:
    - name: USER
      valueFrom:
        secretKeyRef:
          name: secret-demo01       # 引用 secret 对象名称
          key: user                 # 引用 secret 对象上的键，将其值传递给环境变量
    - name: PASS
      valueFrom:
        secretKeyRef:
          name: secret-demo01
          key: pass
    envFrom:                        # 整体引用指定的 Secret 对象全部键名和键值
    - prefix: NEW                   # 将所有健明引用为环境变量时统一添加的前缀 (无需求，可不用)
      secretRef:
        name: secret-demo02

# kubectl apply -f secret-nginx.yaml
# kubectl exec -it secret-nignx-pod -n inadm -- /bin/bash
:/# env | egrep -i "(pass|user)"

upload successful

10.2.2 MySQL 注入密码

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
// MySQL 运行时初始化 root 用户的密码，引用此前创建的 secret 对象 mysql-root-auth
# cat secret-mysql.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-mysql-pod
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: secret-nginx-container
    image: harbor.inadm.com/ops_apps_tools/mysql:5.7.37
    env:
    - name: MYSQL_ROOT_PASSWORD         # 设定 MySQL 超级管理员密码变量名称
      valueFrom:
        secretKeyRef:
          name: mysql-root-auth
          key: password
    - name: MYSQL_USER
      valueFrom:
        secretKeyRef:
          name: mysql-inadm-auth
          key: username.txt
    - name: MYSQL_PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysql-inadm-auth
          key: password.txt

# kubectl apply -f secret-mysql.yaml 
// 使用 mysql-root-auth 对象中的 password 字段值 inadm.com 作为密码进行数据库访问
# kubectl exec -it secret-mysql-pod -n inadm -- mysql -uroot -pink8s.com
mysql> show databases;

10.2.3 引用整个存储卷

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 引用整个存储卷：将 mysql-inadm-auth ,这个 secret 的每个键名转为容器挂载点路径下的一个文件名
# cat secret-volume.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-nginx01
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  volumes:
  - name: user-pass
    secret:
      secretName: mysql-inadm-auth
  containers:
  - name: secret-volume-container
    image: harbor.inadm.com/ops_apps_tools/nginx:1.16
    volumeMounts:
    - name: user-pass             # 将 user-pass 所有 key 挂载至 /app 目录下
      mountPath: /app

# kubectl apply -f secret-volume.yaml 
# kubectl exec -it secret-volume-nginx01 -n inadm -- ls -l /app

upload successful

10.2.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
// 1.将 mysql-inadm-auth，这个 secret 的 username.txt 键挂载至容器的 /app 目录下，命名为 username.txt
// 2.将 mysql-inadm-auth，这个 secret 的 password.txt 键挂载至容器的 /app 目录下，命名为 password.txt
# cat secret-volume-nginx02.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-nginx02
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: secret-volume-container-02
    image: harbor.inadm.com/ops_apps_tools/nginx:1.16
    volumeMounts:
    - name: volume-nginx02             # 将 volume-nginx02 数据挂载至容器 /app 路径
      mountPath: /app
  volumes:
  - name: volume-nginx02
    secret:
      secretName: mysql-inadm-auth
      items:
      - key: username.txt              # key 挂载至 mountPath 定义路径下，并通过 path 命名为 username.txt
        path: username.txt
      - key: password.txt
        path: password.txt

# kubectl apply -f secret-volume-nginx02.yaml
# kubectl exec -it secret-volume-nginx02 -n inadm -- cat /app/password.txt
    ink8s.com        # 进行了转译

10.3 nginx 基于 secret 实现 tls

  • 场景说明:
    • 运行一个 nginx 容器
    • nginx 虚拟站点配置文件来源于 ConfigMap
    • nginx 虚拟站点需要使用 TLS 证书，来源于 Secret
    • 验证 nginx 服务是否已提供 https 访问
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
# kubectl create secret tls web-inadm-com -n inadm --key=app.inadm.com.key --cert=app.inadm.com.pem
# cat secret-nginx-ssl.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-nginx-ssl-vhost
  namespace: inadm
data:
  app.inadm.com.conf: |
    server {
        listen  443 ssl;
        server_name app.inadm.com;

        ssl_certificate /etc/nginx/certs/tls.crt;
        ssl_certificate_key /etc/nginx/certs/tls.key;
    
        location / {
            root    /usr/share/nginx/html;
            index   index.html;
        }
    
        include /etc/nginx/conf.d/*.cfg;
    }
    server {
        listen  80;
        server_name app.inadm.com;
        return 301 https://$host$request_uri;
    }

---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-ssl-vhost
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: nginx-ssl-vhost-container
    image: harbor.inadm.com/ops_apps_tools/nginx:1.16
    volumeMounts:
    - name: ngx-conf
      mountPath: /etc/nginx/conf.d/
    - name: ngx-tls
      mountPath: /etc/nginx/certs/
  volumes:
  - name: ngx-conf
    configMap:
      name: cm-nginx-ssl-vhost
      items:
      - key: app.inadm.com.conf
        path: app.inadm.com.conf
        mode: 0644
  - name: ngx-tls                       # 定义虚拟主机 tls 文件来源
    secret:
      secretName: app-inadm-com

# kubectl apply -f secret-nginx-ssl.yaml 
# curl -I -k https://pod_ip
# curl -I -k -v https://pod_ip

upload successful

11.0 statefulset

  • StatefulSet 名称是固定，且创建时按照顺序进行创建，并固定对应的 Pod 名称
  • Headless Service 用来配置每个 Pod 的 DNS 名称，只要 Pod 名称不变化，他们的 DNS 就是稳定且持久的
  • VolumeClaimTemplate 作为分布式，每个 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
// StatefulSet 示例配置

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: <string>                            # 资源名称
  namespace: <string>
spec:
  serviceName: <string>                     # 相关 HeadlessService 名称
  updateStrategy: <object>                  # 更新策略
    type: <string>                          # 更新类型，可以有 rollingUpdate 和 OnDelete
    rollingUpdate: <object>                 # 滚动更新
      partition: <integer>                  # 分区策略，默认为 0
  podManagementPolicy: <string>             # Pod 管理策略，默认 OrderedReady 表示顺序创建 Pod，逆序删除
                                            # 另一种 Parallel 表示并行创建 Pod 和并行删除  Pod
  replicas: <integer>                       # Pod 副本数
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo-container
        image: nginx
        ports:
        - containerPort: 80
  volumeClaimTemplates:                             # 存储卷申请模版
    metadata:
      name: data
    spec:
      accessMode: ["ReadWriteOnce"]
      storageClassName: "managed-nfs-storage"
      resources:
        requests:
          storage: 2G

11.1 sts 实践

  • 创建名为 web-svc 的 Headless Service 用来控制网络域名
  • 创建名为 web 的 StatefulSet 有一个 spec，它表名将在独立的 3 个 Pod 副本中启动 nginx 容器
  • volumeClaimTemplates 将通过 PersistentVolumes 驱动来提供稳定的存储
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
# cat sts-web-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-svc
  namespace: inadm
spec:
  clusterIP: None
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: inadm
spec:
  serviceName: web-svc
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - containerPort: 80
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "csi-rbd-sc"
        resources:
          requests:
            storage: 6Gi

# kubectl apply -f sts-web-svc.yaml
# kubectl get pvc -n inadm                                                 # pv 动态供应自动创建
# dig web-0.web-svc.inadm.svc.cluster.local @10.96.0.10 +short                # DNS 名称解析
# kubectl scale sts web -n inadm --replicas=5                                 # 扩展 sts，按照编号一个一个顺序创建出来

upload successful

11.2 sts 更新策略

  • sts 更新支持两种策略 onDelete 和 RollingUpdate，在 .spec.updateStrategy 进行设定
    • onDelete: 当 StatefulSet 的 .spec.updateStrategy.type 设置为 OnDelete 时，控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 .spec.template 的变动做出反应
    • RollingUpdate: RollingUpdate 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。这是默认的更新策略。StatefulSet 控制器会删除和重建 Pod。它将按照与 Pod 终止相同的顺序(从最大序号到最小序号)进行，每次更新一个 Pod

11.2.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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// 滚动更新：修改 yaml 为 RollingUpdate，并更新镜像版本
# cat sts-web.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-svc
  namespace: inadm
spec:
  clusterIP: None
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: inadm
spec:
  serviceName: web-svc
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  updateStrategy:                     # 设定滚动更新
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: nginx
        image: harbor.inadm.com/ops_apps_tools/nginx:1.18            # 调整版本，观察申请顺序
        ports:
        - containerPort: 80
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "csi-rbd-sc"
        resources:
          requests:
            storage: 6Gi

# kubectl apply -f sts-web.yaml
# kubectl get pod -n inadm -o wide -l app=nginx -w

upload successful

upload successful

11.2.2 分区滚动更新

  • sts 的 RollingUpdate 滚动更新支持 Partition 分区更新，有点类似灰度发布模式
    • 设定 partition 为 3, sts 会检查是否有 Pod 的编号大于 3 ，如果有则更新大于等于 N 的 Pod
    • 如果直接 partition 分区为 0，sts 会更新所有的镜像 (从最大序号到最小序号进行镜像更新)
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 sts-web.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-svc
  namespace: inadm
spec:
  clusterIP: None
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: inadm
spec:
  serviceName: web-svc
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  updateStrategy:                     # 设定滚动更新
    type: RollingUpdate
    rollingUpdate:
      partition: 3                    # 设定更新分区
  template:
    metadata:
      labels:
        app: nginx
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: nginx
        image: harbor.inadm.com/ops_apps_tools/nginx:1.18
        ports:
        - containerPort: 80
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "csi-rbd-sc"
        resources:
          requests:
            storage: 6Gi

# kubectl get pod -n inadm -l app=nginx -w -o wide            # 观察更新过程

12.0 认证与授权

  • 为何需要认证：对于 k8s 系统来说，APIServer 肯定不是任何人都能轻易访问的，如果任何人都能轻易访问，意味着可以通过 kubectl 命令访问 APIServer，进而操作 k8s。也就意味着它能够在我们的系统上随便部署应用程序，甚至还会删除我们正在运行的应用程序，这是非常危险的。所以我们需要对用户进行身份认证，确保身份是合法的
  • 认证流程：任何客户端用户试图通过 APIServer 操作资源对象时，他们必须经历多个阶段的访问控制，才会被接受处理，其中包含认证、授权及准入控制
    • 认证：任何客户端访问，经过 API 操作之前，需要先完成认证操作，也就是进行身份认证
    • 授权：认证通过后仅代表它是一个合法的系统用户，但它是否拥有删除对应资源权限，需要进行授权检查
    • 准入控制：虽然我们有了权限，也可以创建 Pod 资源等各种资源，但创建 Pod 是否能够成功呢，假设 ops 名称空间显示最多创建 2 个 Pod，目前已经有了 2 个 Pod 了，那么这次的创建就会失败
  • 认证的方式：
    • UserAcconunt：使用 kubectl 创建资源，首先要进行客户端身份认证，所以客户端每次请求 APIServer 时都会携带上数字证书，用于认证 API-Server，当认证通过后，证书中的 Subject 将被识别为用户标识，其中的 CN 字段的值为用户名，字段 O 的值就是用户所属的组，例如：Subject： O=ops,CN=user01 用户名为 user01，用户的组为 ops
    • ServiceAccount：有些情况下，期望在 Pod 内部能够访问 API-Server，获取集群的信息，甚至对集群进行改动。针对这种情况，k8s 提供了一种特殊的认证方式：ServiceAccount。默认情况下，创建的 Pod 如果没有指定 ServiceAccount 则系统默认提供一个 ServiceAccount，而后通过 mount 方式挂载到 Pod 文件系统，该 ServiceAccount 能通过 DownWardAPI 获取该 Pod 相关的一些元数据信息。当然也可以自行创建 ServiceAccount 来完成 API-Server 的身份认证，至于能否对集群进行改变，则需要看该 ServiceAccount 是否拥有权限
1
2
3
4
5
6
7
// 可以使用 echo xxx | base64 -d 对 client-certificate-data 进行超管的解码
# cat /root/.kube/config                            # 对 "client-certificate-data" 进行解码
# echo xxx | base64 -d
# openssl x509 -in test.crt -text -noout            # 组"O",用户"CN"
// 进一步查看 kubernetes-admin 用户权限
# kubectl get clusterrole cluster-admin -o yaml
# kubectl get clusterrolebindings cluster-admin -o yaml

12.1 SA 认证实践

  • 在线 JWT Token 解析解码
  • 使用默认 sa 认证 API：当创建 Pod 时，如果没有指定 SA，Pod 会注入对应名称空间的 default 服务账户。如果你查看 Pod 的原始 YAML（例如：kubectl get pod/podname -o yaml），你可以看到 spec.serviceAccountName 字段已经被自动设置了
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# kubectl get pod -n inadm pod-test -o yaml | grep "serviceAccountName"
# cat sa-pod-test.yaml
piVersion: 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: Pod
metadata:
spec:
  serviceAccountName: default

# kubectl apply -f sa-pod-test.yaml
# kubectl exec -it -n inadm pod-test -- /bin/sh
$cat /var/run/secrets/kubernetes.io/serviceaccount/token		# 令牌
// Token 解码 https://tooltt.com/jwt-decode/

upload successful

upload successful

12.1.1 创建 sa 并与 Pod 关联

1
2
3
4
5
6
7
8
9
10
// 命令方式创建 SA
# kubectl create sa sa-test --namespace=default

// 清单文件写法
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-test
  namespace: inadm
automountServiceAccountToken: true            # 自动挂载 API 凭据
  • 测试 SA 用户能否认证 APIServer
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Pod 清单文件应用 SA
# cat sa-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sa-pod
spec:
  imagePullSecrets:
  - name: harbor-auth
  serviceAccountName: sa-test                 # 指定 Pod 运行时使用的 SA
  automountServiceAccountToken: true
  containers:
  - name: nginx
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18

// 测试 SA 用户能否认证 APIServer
# kubectl exec -it sa-pod -- /bin/bash
# cd /var/run/secrets/kubernetes.io/serviceaccount
// 虽然能认证，但是没有权限访问 (cdoe: 403)
# curl --cacert ca.crt -H "Authorization: Bearer $(cat token)" https://kubernetes/api/v1/namespaces/default

upload successful

  • 分配集群管理员权限，测试效果
1
2
3
# kubectl create rolebinding role-sa-admin --clusterrole=admin --serviceaccount=default:sa-test
// 再次测试 SA 是否能访问 APIServer
# curl --cacert ca.crt -H "Authorization: Bearer $(cat token)" https://kubernetes/api/v1/namespaces/default

upload successful

12.1.2 sa 添加私有仓库认证

  • 通过 ServiceAccountName 来完成私有仓库认证，可以不使用 imagePullSecret，因为在 ServiceAccount 中有 Image Pull Secrets 这个字段，可以将认证仓库信息给附加进去
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 1.secret 认证使用 harbor-auth
// 2.创建 SA，定义名称，然后将镜像拉取 Secret 添加到该账号下
# cat sa-pod.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-pod-auth
  namespace: inadm
imagePullSecrets:
  - name: harbor-auth

---
apiVersion: v1
kind: Pod
metadata:
  name: sa-pod-auth
  namespace: inadm
spec:
  serviceAccount: sa-pod-auth
  containers:
  - name: sa-pod-auth
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18

# kubectl apply -f sa-pod.yaml

12.2 k8s 基于 user 认证

  • kubeconfig 作用：由于 APIServer 是基于无状态 HTTP/HTTPS 协议实现，所以每次与集群进行交互都需要进行身份认证，通常都是使用证书进行认证，其认证所需要的信息都会存放在 kubeconfig 文件中
  • 客户端程序会通过默认路径 -–kubeconfig 选项 或 KUBECONFIG 环境变量定义要加载的 kubeocnfig 文件，从而能够在每次的请求通过 API-Server 的认证
  • kubeconfig 文件格式：kubeconfig 文件主要分为四部分：cluster、users、context、current-context
    • cluster：集群以列表形式定义在 cluster 配置段中，每个列表项代表一个 kubernetes 集群，并拥有名称标识
    • users：访问集群的身份都定义在 users 配置段中，每个列表项代表一个能够认证到某个 kubernetes 集群的凭据
    • context：将 user 与 cluster 二者之间的映射关系进行绑定，而后定义在 context 配置中
    • current-context：用于指定当前集群默认使用的 context，表示当前正在使用哪个用户操作哪个集群
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 默认使用 kubeadm 初始化 kubernetes 集群过程中，在 master 节点上生成的 /etc/kubernetes/admin.conf 文件就是一个 kubeconfig 格式的文件，它由 kubeadm 命令自动生成，可由 kubectl 加载后接入当前集群的 API Server。
// 默认 kubectl 加载的 kubeconfig 文件默认路径为 $HOME/.kube/config，当然也可以通过 --kubeconfig 选项，或 KUBECONFIG 环境变量将其修改为其它路径

// kubectl config view 命令能打印 kubeconfig 文件内容，其中包含了集群列表，用户列表，上下文列表，以及当前使用的上下文 context 等
# kubectl config view
apiVersion: v1
clusters:                                         # 集群列表
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://k8s-vip.inadm.com:6443
  name: kubernetes
contexts:                                         # 映射关系
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes      # 当前正在使用的
kind: Config
preferences: {}
users:                                            # 用户列表
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

12.2.1 自定义 kubeconfig

  • 创建一个 UserAccount 用户，然后加入到 kubeconfig 文件中，最后通过 kubectl 加载 kubeconfig 文件中对应的证书信息，然后尝试认证到 APServer
  • UserAccount 用户不可以直接创建，需要创建证书文件，在证书申请文件中填写好证书对应的 CN，也就是我们的用户名称，而后经由 APIServer 信任的 CA (/etc/kubernetes/api/ca.crt) 签署证书请求文件。最后与 APIServer 进行认证时，APIServer 会获取证书中的 CN，以判断该用户是否是合法的
  • 加入已有集群配置文件
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 -p /root/.certs
# (umask 077; openssl genrsa -out /root/.certs/user01.key 2048)

// 创建证书签署请求文件，-subj 选项中的 CN 的值将被 APIServer 识别为用户名，O 的值将被识别为用户组
# openssl req -new -key /root/.certs/user01.key -out /root/.certs/user01.csr -subj "/CN=user01/O=devops"

// 使用 kubernetes-ca 的身份对文件进行签署
# openssl x509 -req -days 3650 -in /root/.certs/user01.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /root/.certs/user01.crt

// 根据 x509 数字证书及私钥创建身份凭据
# kubectl config set-credentials user01 --client-certificate=/root/.certs/user01.crt --client-key=/root/.certs/user01.key --embed-certs=true

// 配置 context 上下文，以 user01 身份凭据访问已定义的 kubernetes 集群，context 名称为 user01@kubernets
# kubectl config set-context user01@kubernetes --cluster=kubernetes --user=user01

// 将当前上下文切换为 user01@kubernetes
# kubectl config use-context user01@kubernetes

// 测试 user01 用户是否能通过 API Server 认证
# kubectl get ns
Error from server (Forbidden): namespaces is forbidden: User "user01" cannot list resource "namespaces" in API group "" at the cluster scope
/ 虽然报错，但 user01 用户已被 API Server 正确失败

# kubectl config get-contexts 					# 查看所有上下文
# kubectl config current-context 				# 查看当前使用的上下文
# kubectl config use-context kubernetes-admin@kubernetes	# 切换上下文

12.2.2 创建新的集群配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 1.添加集群配置，设定集群名称，设定 APIServer 地址，以及 APIServer 信任的 CA 证书
# kubectl config set-cluster inadm_k8s --kubeconfig=/tmp/config --server="https://k8s-vip.inadm.com:6443" --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true

// 2.添加身份凭据，使用 CA 已签署的客户端证书即可
# kubectl config set-credentials user01 --kubeconfig=/tmp/config --client-certificate=/root/.certs/user01.crt --client-key=/root/.certs/user01.key --embed-certs=true

// 3.将 user01 用户与 inadm_k8s 集群建立映射关系
# kubectl config set-context user01@inadm_k8s --cluster=inadm_k8s --user=user01 --kubeconfig=/tmp/config

// 4.设定默认上下文为 user01@inadm_k8s
# kubectl config use-context user01@inadm_k8s --kubeconfig=/tmp/config

// 5. user01 用户未设置任何授权，但它能够被系统识别为 user01 用户，这表示身份认证时正常；后续就可以授权了
# kubectl get nodes --kubeconfig=/tmp/config --context="user01@inadm_k8s"
Error from server (Forbidden): nodes is forbidden: User "user01" cannot list resource "nodes" in API group "" at the cluster scope
1
2
[root@master01 ~]# kubectl config current-context                # 查看 kubectl 的当前上下文
    user01@kubernetes

12.3 RBAC 授权

  • RBAC 基于角色的访问控制；其实就是将资源的操作权限授予给指定的角色，而后将用户加入该角色，那么该用户则拥有了对角色的权限
  • 举例：希望 user01 用户能够获取所有 Pod 的列表
    • 首先定义角色，然后定义角色权限规则，资源：Pod，操作权限：get,list
    • 然后定义角色绑定，将 user01 绑定至该角色，而后 user01 就拥有了该角色的权限，进而就能够获取 Pod 信息

upload successful

  • RBAC 角色与集群角色：k8s 系统的 RBAC 授权插件将角色分为了 Role 和 ClusterRole 两类：
    • Role：仅作用于名称空间级别，用于承载名称空间级别内的资源权限集合
    • ClusterRole：作用于集群范围，能够同时承载名称空间和集群级别的资源权限集合
  • k8s 利用 Role 和 ClusterRole 两类角色来赋予对应的权限，同时也需要用到另外两类资源 Rolebinding 和 ClusterRolebinding 来完成用户与角色的绑定关系

upload successful

  • 注意：RoleBinding除了可以绑定 Role 以外，还可以绑定 ClusterRole，但它的权限还是限制在名称空间级别
    • 这种方式有着特定的应用场景
      • 比如：希望在三个名称空间中都创建一个管理员身份，那么我们就需要创建3个 role 和 3 个 rolebinding
      • 但是：我们可以定义一个 clusterrole，然后通过 rolebind 绑定就完成了，也就不需要重复创建很多的 role

upload successful

1
2
Role <-- Rolebinding --> User
User --> Rolebinding --> ClusterRole

12.3.1 RBAC 场景-1

  • 场景说明： 赋予 user01 用户对 default 名称空间拥有 Pod 的读取权限
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 创建 role 角色，设定对应的规则

// 命令方式
# kubectl create role default-pod-reader --resource=pod --verb=get,list,watch --namespace=default --context="kubernetes-admin@kubernetes"

// yaml 方式
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: default-pod-reader
  namespace: default
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  • 创建 rolebinding 角色绑定，将 user01 绑定至对应的 role 上
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 命令方式
# kubectl create rolebinding user01-default-pod-reader --role=default-pod-reader --user=user01 --namespace=default --context="kubernetes-admin@kubernetes"

// yaml 方式
apiVersion: rabc.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: user01-default-pod-reader
  namespace: default
roleRef:
  apiGroup: rabc.authorization.k8s.io
  kind: Role
  name: default-pod-reader
subjects:
- apiGroup:
  kind: User
  name: user01
  • 使用 user01 用户验证权限
1
# kubectl get pod --context="user01@kubernetes"

12.3.2 RBAC 场景-2

  • 场景说明：赋予 user01 用户对所有名称空间拥有 Pod 的读取权限 （ClusterRole、ClusterRoleBinding）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 创建 clusterrole

// 命令方式
# kubectl create clusterrole cluster-pod-reader --resource=pod --verb=get,list,watch --context="kubernetes-admin@kubernetes"

// yaml 方式
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-reader
rule:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  • 创建 clusterrolebinding，并绑定 user01 用户至对应的 clusterrole
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 命令方式
# kubectl create clusterrolebinding cluster-pod-reader-user01 --clusterrole=cluster-pod-reader --user=user01 --context="kubernetes-admin@kubernetes"

// yaml 方式
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-pod-reader-user01
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-pod-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user01
  • 使用 user01 用户验证权限
1
2
# kubectl get pod --context="user01@kubernetes"
# kubectl get pod -n kube-system --context="user01@kubernetes"

12.3.3 RBAC 场景-3

  • 场景说明: 赋予 user01 用户对 default 名称空间拥有管理员权限
    • 系统内置了一个 ClusterRole: admin 的集群管理员，我们可以通过 rolebinding 引用 ClusterRole: admin 集群角色，该引用会造成用户仅对 rolebinding 所在的名称空间有管理员权限。（因为 rolebinding 仅能作用在名称空间范围内）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 删除此前的绑定，避免权限受到干扰
# kubectl delete clusterrolebindings cluster-pod-reader-user01 --context="kubernetes-admin@kubernetes"
# kubectl delete rolebindings user01-default-pod-reader --context="kubernetes-admin@kubernetes"

// 创建 RoleBinding 引用 Cluster-role
# kubectl create rolebinding default-admin-user01 --clusterrole=admin --user=user01 --namespace=default --context="kubernetes-admin@kubernetes"

// 验证 user01 用户权限
# kubectl get pod
# kubectl delete pod sa-pod

// 能对 default 名称空间进行 增 删 改，对其它名称空间无权限
# kubectl get pod -n ingress-nginx --context="user01@kubernetes"
Error from server (Forbidden): pods is forbidden: User "user01" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"

12.3.4 内置ClusterRole

  • k8s 系统内置了一组默认的 ClusterRole 和 ClusterRoleBinding 资源预留给系统使用，其中大多数都以 system: 为前缀。还有一些不易 system: 为前缀的 ClusterRole 是面向用户设计的，比如：集群管理员角色 cluster-admin、admin、edit、view 掌握这些默认的内置角色资源有助于按需创建用户并分配相应的权限

upload successful

  • Cluster-admin 分析：内置的 cluster-admin 资源拥有管理集群所有资源的权限，而内置的 cluster-admin 将该角色分配给了 system:master 组，这意味着所有加入该组的用户将自动具有集群的超级管理员权限
  • 在使用 kubeadm 安装集群时，它自动创建配置文件 /etc/kubernetes/admin.conf 中定义的用户为 kubernetes-admin，而该用户使用数字证书， Subject 属性值为 /o=system:master。所以 API Server 会在成功验证该用户的身份之后将其识别为 system:master 用户组成员

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
// 分析过程如下：

1. 查看 cluster-admin 角色的绑定关系，可以看到 cluster-admin 这个角色绑定的 system.master
# kubectl get clusterrolebinding cluster-admin -o yaml --context="kubernetes-admin@kubernetes"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "xxx"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "172"
  uid: adf208fd-91ba-4766-89dc-76fbc2901b00
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters
  
2. system:master 这个组名称并非认为定义，而是证书生成的
# echo "KUBERNETES-ADMIN_USER_CRT" | base64 -d > 1.txt
# openssl x509 -in 1.txt -text -noout            # 注意：在创建证书时，可以将用户绑定到 system:master 组，用户会自动集成组的权

12.3.4.1 Cluster-admin 实践

  • 创建一个 ops 用户，然后将该用户加入到 system:masters 组中，验证是否拥有集群管理员权限
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1. 创建证书私有文件
# mkdir -p /root/.certs
# (umask 077; openssl genrsa -out /root/.certs/ops.key 2048)

2. 创建证书签署请求文件，CN 为指定的用户名，O 为指定的组名称
# openssl req -new -key /root/.certs/ops.key -out /root/.certs/ops.csr -subj "/CN=ops/O=system:masters"

3. 使用 kubernetes-ca 的身份对文件进行签署
# openssl x509 -req -days 3650 -in /root/.certs/ops.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /root/.certs/ops.crt

4. 根据 x509 数字证书及私钥创建身份凭据
# kubectl config set-credentials ops --client-certificate=/root/.certs/ops.crt --client-key=/root/.certs/ops.key --embed-certs=true

5. 配置 context 上下文，以 user01 身份凭据访问已定义的 kuberntes 集群，context 名称为 user01@kubernetes
# kubectl config set-context ops@kubernetes --cluster=kubernetes --user=ops


6. 测试 user01 是否具备超级管理员权限
# kubectl get nodes --context="ops@kubernetes"
# kubectl get all --context="ops@kubernetes"

13.0 准入控制

  • APIServer 中准入控制器是以插件形式存在的，他们会拦截所有已完成认证的用户，且与资源创建、更新、删除操作相关的请求
  • 通过 APIServer 启用的准入控制插件，然后强制实现定义的功能，比如：对象的语义验证、以及设置缺省字段的默认值等 k8s 通过 ResourceQuota 以及 LimitRange 准入控制器，可以为多租户或多项目的集群环境提供资源配额与限制

13.1 ResoucesQuta

  • 资源配额：当系统存在多个用户或团队共享具有固定节点的 k8s 集群时，一般会根据不同团队创建不同的命名空间，但可能会出现某个应用将该命名空间的 CPU 或 内存耗尽的情况，无法保证其公平分配原则。可以通过 ResourceQuotas 资源配额来解决这个问题。ResourceQuota 主要是对每个命名空间的资源使用总量设定限制

    • 它可以限制命名空间中某种类型对象的所创建的总数进行限制
    • 也可以限制命名空间中 Pod 可以使用的 CPU 或 内存资源的总上线

  • 场景-1：当用户在命名空间下创建资源（如：Pod、Service 等）时，k8s 的配额会跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的资源限额。如果资源创建或更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN），并在消息中给出违反的信息描述

  • 场景-2：如果命名空间下的计算资源（如 cpu 和 memory）的配额被启用，则用户必须为这些资源设定（requests）和（limit），否则配额系统将决绝 Pod 的创建。提示：可使用LimitRange 准入控制器来为没有设置计算资源的 Pod 设置默认值

  • 配额策略示例：在具有 32GiB 内存和 16C 资源的集群中

    • 允许 A 团队使用 20GiB 内存和 10C 的资源
    • 允许 B 团队使用 10GiB 内存和 4C 的资源
    • 预留 2GiB 内存和 2C 资源供将来分配

  • 限制 test 命名空间使用 1C 和 1GiB 内存。允许 prod 命名空间使用任意数量，当集群容量小于各命名空间配额总和的情况下，可能存在资源竞争。资源竞争时，k8s 系统会遵循先到先得的原则。但不管是自愿竞争还是配额修改，都不会影响已经创建的资源使用对象

13.1.1 计算资源配额

  • 用户可以对给定命名空间下的可被请求的 计算资源 总量进行限制
资源名称描述
requests.cpu所有非终止状态的 Pod，其 CPU 申请的总量不能超过该值
requests.memory所有非终止状态的 Pod，其 内存 申请的总量不能超过该值
limits.cpu所有非终止状态的 Pod，其 CPU 运行期间限制总量不能超过该值
limits.memory所有非终止状态的 Pod，其 内存 运行期间限制总量不能超过该值
 
1
2
3
4
5
6
7
8
9
10
11
12
// 示例
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
  namespace: ops
spec:
  hard:
    requests.cpu: "1"                # 在该命名空间中所有 Pod 的 CPU  申请总和不能超过 1C
    requests.memory: 1Gi             # 在该命名空间中所有 Pod 的内存申请总和不能超过 1GiB
    limits.cpu: "2"                  # 在该名称空间中所有 Pod 的 CPU 限制总和不能超过 2C
    limits.memory: 2Gi               # 在该名称空间中所有 Pod 的内存限制总和不能超过 2GiB

13.1.2 存储资源配额

  • 用户可以对指定命名空间下的存储资源总量进行限制。此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗
资源名称描述
requests.storage所有 PVC 存储资源的需求总量不能超过该值
persistentvolumeclaims 3在该命名空间中所允许的 PVC 总数量
< storage-class-name >.storageclass.storage.k8s.io/requests.storage与 < storage-class-name > 相关的 PVC，存储请求的总和不能超过该值
< storage-class-name >.storageclass.storage.k8s.io/persistentvolumeclaims与 < storage-class-name > 相关的 PVC，可以存在的 PVC 总数
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 示例
apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-demo
  namespace: ops
spec:
  hard:
    requests.storage: 500Gi                                     # 总共可以申请的 PVC 总量
    persistentvolumeclaims: 20                                  # 命名空间中总共能申请的 PVC 数量
    nfs.storageclass.storage.k8s.io/requests.storage: 100Gi     # 对 nfs 存储类型限制 100G 的申请
    gfs:storageclass.storage.k8s.io/requests.storage: 100Gi     # 对 gfs 存储类型限制 100Gi 的申请
    csi-rbd-sc.storageclass.storage.k8s.io/requests.storage: 100Gi
    
# kubectl get storageclass					# storageclass NAME 查看

13.1.3 对象数量配额

  • 当使用 count/* 资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。这些类型的配额有助于防止存储资源耗尽。例如
    • 用户可能想根据服务器的存储能力来对服务器中 secret 的数量进行配额限制，集群中存在过多的 secret 实际上回导致服务器和控制器无法启动
    • 用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务
资源名称描述
configmaps在该名称空间中允许存在的 ConfigMap 总数上限
persistentvolumeclaims在该名称空间中允许存在的 PVC 的总数上限
pods在该名称空间中允许存在的非终止状态的 Pod 总数上限。包含(Filed, Succeeded)
resourcequotas在该名称空间中允许存在的 ResourceQuota 总数上线
services在该名称空间中允许存在的 service 总数上限
rservies.loadbalancers在该名称空间中允许存在的 LoadBalancer 类型的 Service 总数上限
services.nodeports在该名称空间中允许存在的 NodePort 类型的 Service 总数上限
secrets在该名称空间中允许存在的 Secret 总数上限

13.1.4 计算资源配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1. 创建一个名称空间，以便创建的资源和集群的其余资源相隔离
# kubectl create ns quota-ns

2. 创建清单示例文件
# cat quota-mem-cpu.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo-1
  namespace: quota-ns
spec:
  hard:
    requests.cpu: "1"                # 在该命名空间中所有 Pod 的 CPU  申请总和不能超过 1C
    requests.memory: 1Gi             # 在该命名空间中所有 Pod 的内存申请总和不能超过 1GiB
    limits.cpu: "2"                  # 在该名称空间中所有 Pod 的 CPU 限制总和不能超过 2C
    limits.memory: 2Gi               # 在该名称空间中所有 Pod 的内存限制总和不能超过 2GiB

3. 查看 RequestsQuta 配置详情
# kubectl get resourcequota -n quota-ns
NAME             AGE    REQUEST                                     LIMIT
mem-cpu-demo-1   14s   requests.cpu: 0/1, requests.memory: 0/1Gi   limits.cpu: 0/2, limits.memory: 0/2Gi

# kubectl describe quota -n quota-ns        # Used 使用多少；Hard 限制多少

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
4. 创建第一个 Pod，申请 400m的 CPU，最大限制 800m。申请 600Mi 内存，最大限制 800Mi
# kubectl create secret docker-registry harbor-auth \
  --docker-server=harbor.inadm.com \
  --docker-username=admin \
  --docker-password=ink8s.com \
  [email protected] \
  -n quota-ns

# cat pod-quota-mem-cpu-1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-demo-1
  namespace: quota-ns
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: nginx
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18
    resources:
      requests:
        cpu: "400m"
        memory: "600Mi"
      limits:
        cpu: "800m"
        memory: "800Mi"

# kubectl apply -f pod-quota-mem-cpu-1.yaml

5. 检查 ResourceQuotas
# kubectl describe -n quota-ns resourcequotas

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
6. 创建第二个 Pod，申请 400m的 CPU，最大限制 800m。申请 700Mi 的内存，最大限制 1Gi
# cat pod-quota-mem-cpu-2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-demo-2
  namespace: quota-ns
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: nginx
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18
    resources:
      requests:
        cpu: "400m"
        memory: "700Mi"
      limits:
        cpu: "800m"
        memory: "1Gi"

# kubectl apply -f pod-quota-mem-cpu-2.yaml
Error from server (Forbidden): error when creating "pod-quota-mem-cpu-2.yaml": pods "pod-demo-2" is forbidden: exceeded quota: mem-cpu-demo-1, requested: requests.memory=700Mi, used: requests.memory=600Mi, limited: requests.memory=1Gi

7. 可以看到 Pod 的内存请求为 700Mi。注意新的内存请求与已经使用的内存请求之和超过了内存请求的配额：600MiB + 700MiB > 1GiB，所以无法创建，提示内存溢出

8. 如果 Pod 没有设定 requests 和 limits 则报错。但可以通过 limitRange 来设定默认的 requests 和 limits

13.1.5 存储资源配置

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
1. 创建资源清单文件
# cat quota-storage.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-demo
  namespace: quota-ns
spec:
  hard:
    requests.storage: 10Gi			# 所有存储类型的总容量
    persistentvolumeclaims: 3			# 所有存储类型的PVC总数
    csi-rbd-sc.storageclass.storage.k8s.io/requests.storage: 8Gi
    csi-rbd-sc.storageclass.storage.k8s.io/persistentvolumeclaims: 2
    cephfs.storageclass.storage.k8s.io/requests.storage: 5Gi

// managed-nfs-storage 动态
# kubectl get storageclass                    # 查看动态 storage 名称
// nfs-storage 静态
# kubectl get pv                              # 查看静态 STORAGECLASS 名称

# (managed-nfs-storage + nfs-storage) 总容量不能超过总限制 10Gi，总申请条目不允许超过 3 条
# managed-nfs-storage 类型的 PVC 申请总和不能超过 8G，并 PVC 条目不允许超过 2
# nfs-storage 类型的 PVC 申请总和不能超过 5G

2. 查看状态
# kubectl describe resourcequotas -n quota-ns                        # 由于没有静态 "nfs-storage"，所以没有实际执行过程

upload successful

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
3. 创建第一个 PVC 申请，类型为 csi-rbd-sc，申请 5Gi
# cat pvc-quota-storage-1.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo-1
  namespace: quota-ns
spec:
  storageClassName: "csi-rbd-sc"
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

# kubectl apply -f pvc-quota-storage-1.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
4. 创建第二个 PVC 申请，先申请 3Gi，然后申请 2Gi，最后申请 1Gi
# cat pvc-quota-storage-2.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo-2
  namespace: quota-ns
spec:
  storageClassName: "csi-rbd-sc"
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 3Gi

# kubectl apply -f pvc-quota-storage-2.yaml

# cat pvc-quota-storage-3.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo-3
  namespace: quota-ns
spec:
  storageClassName: "csi-rbd-sc"
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

# kubectl apply -f pvc-quota-storage-3.yaml

// 第 1 个 PVC 会申请成功，第 2 个PVC也会申请成功，第 3 个 PVC 会申请失败。(首先超过了 PVC 最大的申请数量，同时申请的容量也超过了最大的限制)

upload successful

13.1.6 对象数量限制

  • count/< resource >.< group >: 用于非核心（core）组的资源，比如 Ingress
  • count/< resource >: 用于核心组的资源
1
2
3
4
5
6
7
8
9
10
11
12
13
1. 创建资源清单
# cat quota-counts-1.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: count-demo
  namespace: quota-ns
spec:
  hard:
    count/pods: 2
    count/deployments.apps: 2
    count/services: 2
    count/ingresses.networking.k8s.io: 1

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
2. 创建一个 Deployment，副本数为 1，然后创建 Service 以及 Ingress 资源
# cat quota-count-2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: quota-ns
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: harbor.inadm.com/ops_apps_tools/nginx:1.18
        resources:
          requests:
            cpu: 10m
            memory: 10Mi
          limits:
            cpu: 20m
            memory: 20Mi

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: quota-ns
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-nginx
  namespace: quota-ns
spec:
  ingressClassName: "nginx"
  rules:
  - host: app.inadm.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80

# kubectl describe resourcequotas -n quota-ns

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
3. 创建一个 Deploy，Pod 副本数为 1，然后创建 Service 以及 Ingress 资源
# cat quota-counts-3.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-2
  namespace: quota-ns
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-2
  template:
    metadata:
      labels:
        app: nginx-2
    spec:
      imagePullSecrets:
      - name: harbor-auth
      containers:
      - name: nginx-2
        image: harbor.inadm.com/ops_apps_tools/nginx:1.18
        resources:
          requests:
            cpu: 10m
            memory: 10Mi
          limits:
            cpu: 20m
            memory: 20Mi

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc-2
  namespace: quota-ns
spec:
  selector:
    app: nginx-2
  ports:
  - port: 80
    targetPort: 80

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-nginx-2
  namespace: quota-ns
spec:
  ingressClassName: "nginx"
  rules:
  - host: nginx.inadm.com
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: nginx-svc-2
            port:
              number: 80

4. 应用 yaml 文件，发现无法创建 Ingress，因为限制该名称空间最多创建一个 Ingress

upload successful

13.2 LimitRange

  • ResourceQuota 可以对名称空间资源总使用量进行限制。但可能会出现一个 Pod 申请的 CPU 或 内存设定非常大，从而将该名称空间中的可用资源被某个 Pod 所耗尽，所以可以通过 LimitRange 来限制名称空间中的每个 Pod 或每个 Container 的最大资源、最小资源。如果创建 Pod 没有给定对应的 resources 字段，还可以设定默认值进行自动填充
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
// limitrange 示例
apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - type: Pod               # 针对 Pod 资源（一个 Pod 可以有多个 Container）
    max:                    # Pod 最大能申请的资源大小
      cpu: "2"
      memory: 2Gi
    min:                    # Pod 最低申请的资源大小
      cpu: 200m
      memory: 6Mi
  - type: Container
    default:                # 默认容器未指定资源限制，为该容器提供默认的 Limits
      cpu: 300m
      memory: 200Mi
    defaultRequest:         # 默认容器未指定资源请求，为该容器提供默认的 Requests
      cpu: 200m
      memory: 100Mi
    max:                    # 容器能指定的最大资源申请
      cpu: "1"
      memory: 1Gi
    min:                    # 容器申请时，最低申请的资源大小，低于该大小则报错
      cpu: 100m
      memory: 3Mi
                            # Limits 与 Requests 的比例值不能超过
    maxLimitRequestRatio:   # Requests 和 limits 比率，公式: Limits/Requests ≤ maxLimitRequestRatio
      cpu: 5
      memory: 4

13.2.1 LimitRange 限制场景-1

  • 为名称空间中未指定 Resources 字段的 Pod 资源，设定默认的 requests 和 limits
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1. 创建 LimitRange 资源限制
# cat limitrange-cpumem.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-mem-1
  namespace: inadm
spec:
  limits:
  - type: Container
    default:
      memory: 256Mi
      cpu: 200m
    defaultRequest:
      memory: 128Mi
      cpu: 100m

# kubectl apply -f limitrange-cpumem.yaml 

2. 查看 limitrange 详情
# kubectl describe limitranges -n inadm

upload successful

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
3. 创建一个 Pod，并且在 Pod 中不申明任何的 cpu 与 内存 的 Requests 和 Limits
# cat pod-cpu-mem.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-cpu-mem-demo-1
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: nginx
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18

# kubectl apply -f pod-cpu-mem.yaml 

4. 查看 Pod 的默认 Requests 和 Limits
# kubectl get -n inadm pod pod-cpu-mem-demo-1 -o yaml
// 默认情况什么都不指定，使用LimitRange提供的  request和limits字段值

upload successful

13.2.2 LimitRange 限制场景-2

  • 创建容器时，如果指定了容器的 limits，而没有指定它的 requests 会怎么样 ？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1. 创建 Pod 的 yaml
# cat pod-mem.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-mem-demo-2
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: nginx
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18
    resources:
      limits:             # 指定 Limits 字段
        memory: 64Mi
        cpu: 50m

2. 输出结果显示，容器的 CPU、内存，对应的 Requests 被设置为对应的 Limits 想通值
# kubectl get -n inadm pod pod-mem-demo-2 -o yaml
// 如果创建Pod自行指定了limits，而没有指定request。   它会使用limits的值作为request的值； 二者一样

upload successful

13.2.3 LimitRange 限制场景-3

  • 声明容器的 CPU 和 内存 请求而不声明内存限制会怎样 ？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1. 创建 Pod 的 yaml
# cat pod-mem.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-mem-demo-3
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: nginx
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18
    resources:
      requests:
        memory: 32Mi
        cpu: 30m

2. 输出结果显示，所创建 Pod，容器的 Requests 为 Pod 清单中声明的值。而容器的 CPU与内存 的 Limits 被设置为 200m，256Mi，此值是该名称空间的默认内存限制值
# kubectl get -n inadm pod pod-mem-demo-3 -o yaml
// 如果创建Pod自行指定了requests，而没有指定limits。 request会使用用户自行指定的，而limits则会使用limitrange 中 default字段提供的值作为limits的值；

upload successful

13.2.4 LimitRange 限制场景-4

  • 通过 LimitRange，限制 Pod 创建时最小申请的资源（Request），以及 Pod 运行期间最大能使用的资源（Limits）
  • 这样就可以将 ResourceQuota 和 LimitRange 结合起来，从而避免因某一个 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
1. 创建 LimitRange
# cat limitrange-mem.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-mem-1
  namespace: inadm
spec:
  limits:
  - type: Container
    default:
      memory: 256Mi
      cpu: 200m
    defaultRequest:
      memory: 128Mi
      cpu: 100m
    max:
      cpu: 400m
      memory: 2048Mi
    min:
      cpu: 10m
      memory: 64Mi

2. 创建 Pod
# cat pod-mem.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-mem-demo-4
  namespace: inadm
spec:
  imagePullSecrets:
  - name: harbor-auth
  containers:
  - name: nginx
    image: harbor.inadm.com/ops_apps_tools/nginx:1.18
    resources:
      requests:
        memory: 32Mi
        cpu: 10m

# kubectl apply -f 13-pod-mem.yaml 
Error from server (Forbidden): error when creating "pod-mem.yaml": pods "pod-mem-demo-4" is forbidden: minimum memory usage per Container is 64Mi, but request is 32Mi
// 因为 requests 的 memory 不满足最低申请的 64Mi，所以无法创建 Pod

13.2.5 LimitRange 限制存储

  • 场景说明：
    • 使用 ResourceQuota 限制名称空间中创建的 PVC 总容量，以及 PVC 的总数量
    • 然后使用 LimitRange 限制每个 PVC 申请的最小容量和最大容量
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
1. 创建 ResourceQuotas 限制 PVC 的总容量以及创建的总数量
# ct resource-storage-limitrange.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-storage
  namespace: inadm
spec:
  hard:
    persistentvolumeclaims: 3
    requests.storage: "3Gi"

2. 创建 LimitRange 限制最大和最小
---
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-storage
  namespace: inadm
spec:
  limits:
  - type: PersistentVolumeClaim
    min:
      storage: 1Gi
    max:
      storage: 2Gi

3. 创建 pvc 申请
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: limit-pvc
  namespace: inadm
spec:
  storageClassName: "csi-rbd-sc"
  accessModes:
  - ReadWritemany
  resources:
    requests:
      storage: 100Mi

4. 请求 100Mi 存储空间的 PVC 将被拒绝，因为它们没有达到最小的申请 1Gi

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

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