k8s Pod管理

Pod参数解释

apiVersion: v1 
kind: Pod
metadata: {...}
spec:
   #在 Kubernetes 中，Pod 停止时 kubelet 会先给容器中的主进程发 SIGTERM 信号来通知进程进行 shutdown 以实现优雅停止，如果超时进程还未完全停止则会使用 SIGKILL 来强行终止,terminationGracePeriodSeconds就是强行终止的时间，发送SIGTERM 信号 30s（默认是30s）之后容器还未终止，就会强行终止。
   #特别说明： preStop Hook并不会影响SIGTERM的处理，因此有可能preStopHook还没有执行完就收到SIGKILL导致容器强制退出。因此如果preStop Hook设置了n秒，需要设置terminationGracePeriodSeconds为terminationGracePeriodSeconds+n秒。
   terminationGracePeriodSeconds: 30s
   
   ##pod级别  安全上下文
   securityContext: # Pod级别的安全上下文，对内部所有容器均有效 
      runAsUser <integer> # 以指定的用户身份运行容器进程，默认由镜像中的USER指定 
      runAsGroup <integer> # 以指定的用户组运行容器进程，默认使用的组随容器运行时 
      supplementalGroups <[]integer> #为容器中1号进程的用户添加的附加组; 
      fsGroup <integer> #为容器中的1号进程附加的一个专用组，其功能类似于sgid 
      runAsNonRoot <boolean>#是否以非root身份运行 seLinuxOptions <0bject> #SELinux的相关配置
      sysctls <[]0bject> # 应用到当前Pod上的名称空间级别的sysctl参数设置列表 
      windows0ptions <0bject> #Windows容器专用的设置  
   
   containers: 
      name:… 
      image: …
      ##容器级别 安全上下文
      securityContext: # 容器级别的安全上下文，仅生效于当前容器 
      runAsUser <integer> # 以指定的用户身份运行容器进程 
      runAsGroup <integer> # 以指定的用户组运行容器进程 
      runAsNonRoot <boolean> #是否以非root身份运行
      allowPrivilegeEscalation <boolean> # 是否允许特权升级
      capabilities <0biect> # 于当前容器上添加(add)或删除(drop)的内核能力
         add <[]string> # 添加由列表定义的各内核能力 
         drop <[]string> #移除由列表定义的各内核能力 privileged <boolean> # 是否运行为特权容器
      procMount <string> #设置容器的procMount类型，默认为DefaultProcMount; 
      readonlyRootFilesystem <boolean> # 是否将根文件系统设置为只读模式 
      seLinuxOptions <0bject> # SELinux的相关配置
      windowsOptions <0bject> #windows容器专用的设置

	  ##探针选项解释
	  livenessProbe:
        exec <Object>        #命令式探针
        httpGet <Object>	 #http GET类型的探针
        tcpSocket <Object>   #tcp Socket类型的探针
        initialDelaySeconds <integer> #容器启动时发起首次探测请求的延后时长
        periodSeconds <integer>		#请求周期
        timeoutSeconds <integer>    #超时时长
        successThreshold <integer>	#成功阈值意思是：成功几次才算是真正的成功，次数
        failureThreshold <integer>	#失败阈值意思是：失败几次才算是真正的失败，次数
      
      ##资源限制
      resources:
        requests:
           cpu: ...
           memory:  ...
        limits:
           cpu: ...
           memroy: ...

一、Pod安全上下文

1.1 解释

安全上下文是用于决定容器是如何创建和运行的约束条件，它们代表创建和运行容器时使用的运行参数。

1.2 pod上的安全级别

1.2.1 两个级别

Pod级别 可以使用命令kubectl explain pods.spec.securityContext 看到以下解释内容
容器级别 可以使用命令kubectl explain pods.spec.containers 看到以下解释内容

1.2.1.1 解释
apiVersion: v1 
kind: Pod
metadata: {...}
spec:
   ##pod级别
   securityContext: # Pod级别的安全上下文，对内部所有容器均有效 
      runAsUser <integer> # 以指定的用户身份运行容器进程，默认由镜像中的USER指定 
      runAsGroup <integer> # 以指定的用户组运行容器进程，默认使用的组随容器运行时 
      supplementalGroups <[]integer> #为容器中1号进程的用户添加的附加组; 
      fsGroup <integer> #为容器中的1号进程附加的一个专用组，其功能类似于sgid 
      runAsNonRoot <boolean>#是否以非root身份运行 seLinuxOptions <0bject> #SELinux的相关配置
      sysctls <[]0bject> # 应用到当前Pod上的名称空间级别的sysctl参数设置列表 
      windows0ptions <0bject> #Windows容器专用的设置  
   ##容器级别
   containers: 
      name:… 
      image: …
      securityContext: # 容器级别的安全上下文，仅生效于当前容器 
      runAsUser <integer> # 以指定的用户身份运行容器进程 
      runAsGroup <integer> # 以指定的用户组运行容器进程 
      runAsNonRoot <boolean> #是否以非root身份运行
      allowPrivilegeEscalation <boolean> # 是否允许特权升级
      capabilities <0biect> # 于当前容器上添加(add)或删除(drop)的内核能力
         add <[]string> # 添加由列表定义的各内核能力 
         drop <[]string> #移除由列表定义的各内核能力 privileged <boolean> # 是否运行为特权容器
      procMount <string> #设置容器的procMount类型，默认为DefaultProcMount; 
      readonlyRootFilesystem <boolean> # 是否将根文件系统设置为只读模式 
      seLinuxOptions <0bject> # SELinux的相关配置
      windowsOptions <0bject> #windows容器专用的设置
1.2.1.2 Linux常用的capabilities内核单元
  1. CAP_CHOWN: 改变UID和GID的，容器中默认是开启的
  2. CAP_MKNOD: mknod()，创建设备文件
  3. CAP_NET_ADMIN: 网络管理权限
  4. CAP_SYS_ADMIN: 大部分内核管理权限都支持
  5. CAP_SYS_TIME: 系统时钟
  6. CAP_SYS_MODULE: 装载卸载内核模块
  7. CAP_NET_BIND_SERVER: 是否允许普通用户绑定1024以内的特权端口
1.2.1.3 pod级别的sysctls内核参数

目前pod内可安全设定的内核参数只有三个：kernel.shm.rmid_forced，net.ipv4.ip_local_port_range，net.ipv4.tcp_syncookies
如果想要pod可以设置更多的非安全内核参数需要创建/etc/default/kubelet文件（kubelet级别的设定，而且需要重启kubelet服务）
文件中添加以下配置：
KUBELET_EXTRA_ARGS=‘–allowed-unsafe-sysctls=net.core.somaxconn,net,ipv4.ip.unprivileged_port_start’

1.2.2 举例

1.2.2.1 设置普通用户和组

这里注意：普通用户无法使用1024以内的端口，所以这里定义了端口

apiVersion: v1
kind: Pod
metadata:
   name: SecurityContext-demo
   labels:
      app: SecurityContext-demo
   namespace: dev
spec:
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent     #镜像拉取策略，IfNotPresent如果没有镜像就拉取
     env:
     - name: PORT
       value: "8080"
     securityContext:
     	#设置运行用户和组
        runAsUser: 1001
        runAsGroup: 1001

kubectl describe pods SecurityContext-demo 查看详细情况
kubect exec pod SecurityContext-demo – ps aux 查看用户ID是否发生变化

1.2.2.2 设置capabilities内核功能
apiVersion: v1
kind: Pod
metadata:
   name: SecurityContext-capabilities-demo
   labels:
      app: SecurityContext-capabilities-demo
   namespace: dev
spec:
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     command: ["/bin/sh","-c"]
     args: ["/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80 && /usr/bin/python3 /usrlocal/bin/demo.py"]
     securityContext:
        capabilities:
           add: ['NET_ADMIN']
           drop: ['CHOWN']			#删除可修改UID和GID的内核参数，删除之后，就不能使用chown更改属主和属组了

kubectl describe pods SecurityContext-capabilities-demo 查看详细情况
kubect exec pod SecurityContext-capabilities-demo – iptables -L -n -t nat 查看容器内的规则

1.2.2.3 设置sysctls内核安全参数
apiVersion: v1
kind: Pod
metadata:
   name: SecurityContext-sysctls-demo
   labels:
      app: SecurityContext-sysctls-demo
   namespace: dev
spec:
   securityContext:
      sysctls:
      - name: kernel.shm.rmid_forced
        value: "0"
      #以下这个参数只有在修改/etc/default/kubelet文件之后才能生效，意思是运行非特权用户使用端口从0开始,所以下边就无需设置端口
      - name: net,ipv4.ip.unprivileged_port_start
        value: "0"
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     securityContext:
        runAsUser: 1001
        runAsGroup: 1001

kubectl describe pods SecurityContext-sysctls-demo 查看详细情况
kubect exec pod SecurityContext-sysctls-demo – netstat -lnpt 查看80端口是否在监听（因为容器中指定了运行用户是普通用户，按理说普通用户无法使用1024以内的端口，但是pod级别中的sysctls参数中打开了这一选项，所以是可以看到80端口在监听的）

1.3 POD状态解释

在这里插入图片描述

Pending：Pod已经被创建，但还没有完成调度，可能处在：写数据到etcd，调度，pull镜像，启动容器这四个阶段中的任何一个阶段，pending伴随的事件通常会有：ADDED, Modified这两个事件的产生。

Running：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。

Succeeded：Pod中的所有的容器已经正常的执行后退出，并且不会自动重启，一般会是在部署job的时候会出现。

Failed：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。

Unkonwn：API Server无法正常获取到Pod对象的状态信息，通常是由于其无法与所在工作节点的kubelet通信所致。

pod从创建到成功或失败的事件
PodScheduled ：pod正处于调度中，刚开始调度的时候，hostip还没绑定上，持续调度之后，有合适的节点就会绑定hostip，然后更新etcd数据

Initialized ：pod中的所有初始化容器已经初启动完毕

Ready ：pod中的容器可以提供服务了

Unschedulable：不能调度，没有合适的节点


CrashLoopBackOff： 容器退出，kubelet正在将它重启
InvalidImageName： 无法解析镜像名称
ImageInspectError： 无法校验镜像
ErrImageNeverPull： 策略禁止拉取镜像
ImagePullBackOff： 正在重试拉取
RegistryUnavailable： 连接不到镜像中心
ErrImagePull：通用的拉取镜像出错
CreateContainerConfigError： 不能创建kubelet使用的容器配置
CreateContainerError： 创建容器失败
m.internalLifecycle.PreStartContainer 执行hook报错
RunContainerError： 启动容器失败
PostStartHookError： 执行hook报错
ContainersNotInitialized： 容器没有初始化完毕
ContainersNotReady： 容器没有准备完毕
ContainerCreating：容器创建中
PodInitializing：pod 初始化中
DockerDaemonNotReady：docker还没有完全启动
NetworkPluginNotReady： 网络插件还没有完全启动
Evicte: pod被驱赶

二、Pod探针和hook

2.1 pod过程

在这里插入图片描述

hook表示可人为定义命令并运行
probe(探针)表示探测容器运行状态可自定义设置探测对象

  1. init contioners 初始化容器，在启动完成之后会自动消亡（初始化容器可以有多个，是串行启动的）
  2. post start hook 作用：主容器启动完成之后可运行命令，类似于/etc/rc.local文件
  3. startup probe 启动探针，是一次性探针，只有这个探针没问题，之后的周期性探针才会生效；未定义这个选项时，容器一启动，周期性探针就开始运行了。
  4. liveness probe 存活探针。检查容器启动状态是否健康（周期性探针）；检测未通过时，kubelet会根据restartPolicy(重启策略)的定义来决定是否重启该容器；未定义这个选项时，kubelet只认为容器未退出，即为健康。【探针在探测时如果容器启动首次探测失败是不会被重启的，只有连续三次探测失败才会重启（这里的首次探测失败是三次中的第一次失败了，后两次没失败就不会重启）】
  5. readiness probe 就绪探针，检查容器是否可以被访问，是否就绪（周期性探针）；检测未通过时，与该pod关联的service，会将该Pod从Service的后端可用端点列表中删除，直到再次就绪时，重新添加回来；未定义这个选项时，kubelet只认为容器未退出，即为就绪。【这个选项探测失败后容器是不会重启的，只会影响端点】
  6. pre stop hook 结束容器之前可运行命令

2.2 探针类型

startup probe ,liveness probe,readiness probe每种探针都支持三种探针

  1. ExecAction: 直接执行命令，命令成功返回，表示探测成功
  2. TCPSocketAction: 端口能正常打开，即成功
  3. HTTPGetAction: 向指定的path发送HTTP请求，2xx，3xx的响应码表示成功。

2.3 参数解释

kubectl explain pods.spec.containers.livenessProbe可以看到以下内容

apiVersion: v1 
kind: Pod
metadata: {...}
spec:
   containers:
   - name: ...
     image: ...
     livenessProbe:
        exec <Object>        #命令式探针
        httpGet <Object>	 #http GET类型的探针
        tcpSocket <Object>   #tcp Socket类型的探针
        initialDelaySeconds <integer> #容器启动时发起首次探测请求的延后时长
        periodSeconds <integer>		#请求周期
        timeoutSeconds <integer>    #超时时长
        successThreshold <integer>	#成功阈值意思是：成功几次才算是真正的成功，次数
        failureThreshold <integer>	#失败阈值意思是：失败几次才算是真正的失败，次数

2.4 举例

此次是基于liveness probe（存活探针）来演示三种探针类型，其他的startup probe ,readiness probe类似

2.4.1 ExecAction执行命令

apiVersion: v1
kind: Pod
metadata:
   name: liveness-exec-demo
   labels:
      app: liveness-exec-demo
   namespace: dev
spec:
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     livenessProbe:
        exec:
          command: ['/bin/sh', '-c', '[ "$(curl -s 127.0.0.1/livez)" == "OK" ]']
        initialDelaySeconds: 5
        timeoutSeconds: 1
        periodSeconds: 5

kubectl describe pods liveness-exec-demo 查看详细信息
如果curl检测的结果不等于OK，就容器就会退出并重启容器。
验证：curl pod_ip:80/livez 返回的应该是OK
修改livez参数的值：curl -X POST -d “livez=fail” pod_ip:80/livez；修改之后curl pod_ip:80/livez 返回的应该是fail，然后就会发现pod重启了，因为这个参数的值是临时修改的，所以重启pod之后，curl pod_ip:80/livez 返回的是OK

2.4.2 TCPSocketAction探针

apiVersion: v1
kind: Pod
metadata:
   name: liveness-tcpsocket-demo
   labels:
      app: liveness-tcpsocket-demo
   namespace: dev
spec:
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     ports:  #声明一个名为http的端口
     - name: http
       containerPort: 80
     securityContext:    #加上修改内核的特权是因为待会验证时，直接修改iptables规则
         capabilities:
            add:
            - NET_ADMIN
     livenessProbe:
        tcpSocket:
           port: http       #这里的http是引用的上边的ports中http这个选项
        initialDelaySeconds: 5
        timeoutSeconds: 1
        periodSeconds: 5

kubectl describe pods liveness-tcpsocket-demo 查看详细信息
这里的Tcpsocket探针方法只是对80端口的探测，只要80端口不挂，就不会检测失败也就不会重启，所以这里需要设置规则，使80端口拒绝访问。
验证：修改规则：kubectl exec liveness-tcpsocket-demo – iptables -A INPUT -p tcp --dport 80 -j REJECT 这条规则表示拒绝访问80端口
之后就会发现pod重启

2.4.3 HTTPGetAction探针

apiVersion: v1
kind: Pod
metadata:
   name: liveness-httpget-demo
   labels:
      app: liveness-httpget-demo
   namespace: dev
spec:
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     ports:  #声明一个名为http的端口
     - name: http
       containerPort: 80
     livenessProbe:
        httpGet:
           path: '/livez'      
           port: http #这里的http是引用的上边的ports中http这个选项
           scheme: HTTP
        initialDelaySeconds: 5
        timeoutSeconds: 1
        periodSeconds: 5

kubectl describe pods liveness-httpget-demo 查看详细信息
这种方法不同于exec命令探测，这里只看响应码是否是2xx或者3xx，不管内容如何
验证：curl -I pod_ip:80/livez 返回200
修改：curl -X POST -d “livez=fail” pod_ip:80/livez
验证：curl -I pod_ip:80/livez 返回5xx，之后发现pod重启

2.4.4 探针readiness probe示例

  1. HTTPGetAction方法

readiness probe 只会影响service后端列表，pod不会重启

apiVersion: v1
kind: Pod
metadata:
   name: readiness-httpget-demo
   labels:
      app: readiness-httpget-demo
   namespace: dev
spec:
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     ports:  #声明一个名为http的端口
     - name: http
       containerPort: 80
     readinessProbe:
        httpGet:
           path: '/readyz'      
           port: http #这里的http是引用的上边的ports中http这个选项
           scheme: HTTP
        initialDelaySeconds: 15
        timeoutSeconds: 2
        periodSeconds: 5
        failureThreshold: 3
     restartPolicy: Always

kubectl describe pods readiness-httpget-demo 查看详细信息
curl pod_ip:80/readyz 返回OK
curl -I pod_ip:80/readyz 返回200
修改：curl -X POS -d “readyz=fail” pod_ip:80/readyz
curl pod_ip:80/readyz 返回fail
curl -I pod_ip:80/readyz 返回5xx，然后查看kubectl get pods -o wide 会发现这个pod中没有就绪的容器了，pod并不会重启

2.5 hook

hook的postStart选项和preStop也跟探针一样支持三种方法

2.5.1 示例

启动前和结束前执行的命令

apiVersion: v1
kind: Pod
metadata:
   name: lifecycle-demo
   labels:
      app: lifecycle-demo
   namespace: dev
spec:
   containers:
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     ports:  #声明一个名为http的端口
     - name: http
       containerPort: 80
     livenessProbe:
        httpGet:
           path: '/livez'      
           port: http #这里的http是引用的上边的ports中http这个选项
           scheme: HTTP
        initialDelaySeconds: 15
        timeoutSeconds: 2
        periodSeconds: 5
        failureThreshold: 3
        lifecycle:
           postStart:
              exec:
                 command: ['/bin/sh','-c','iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-ports 80']
            preStop:
               exec:
                  command: ['/bin/sh','-c','while killall python3;do sleep 1; done']
     restartPolicy: Always

三、pod多容器

pod中可存在多个容器，初始化容器和主容器，其中主容器又分为应用容器，sidecar容器，Adapater容器，ambanssador容器

3.1 主容器的作用

  1. sidecar容器
    为主容器提供辅助功能，例：日志收集容器，代理容器等
  2. Adapater容器
    提供兼容的，例prometheus监控时
  3. ambanssador容器
    大使容器，为主容器更好的接入外部环境的，例：链接外部数据库（mysql，MongoDB等）

3.2 初始化容器示例

这里设置初始化容器的目的在于：为了防止修改内核的权限一直在主容器中可以使用，所以把修改内核的权限放到了初始化容器里，因为修改内核参数之后初始化容器就会消亡，这样就能保证pod的安全性

apiVersion: v1
kind: Pod
metadata:
   name: init-container-demo
   labels:
      app: init-container-demo
   namespace:dev
spec:
   initContainers:
   - name: iptables-init
     image: ikbernetes/admin-box:latest   #这里的初始化镜像可自己构建，反正用完之后就消失了
     imagePullPolicy: IfNotPresent
     command: ['/bin/sh','-c']
     args: ['/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80']
     securityContext:
        capabilities:
           add:
           - NET_ADMIN
     containers:
     - name: demo
       image: ikubernetes/demoapp:v1.0
       imagePullPolicy: IfNotPresent
       ports:
       - name: http
         containerPort: 80

3.3 sidecar容器示例

apiVersion: v1
kind: Pod
metadata:
   name: sidecar-container-demo
   labels:
      app: sidecar-container-demo
   namespace:dev
spec:
   containers:
   - name: proxy
     image: envproxy/envoy-alpine:v1.14.1    #这是个代理容器，可以代理主容器，这里是代理demoapp的8080端口
     command: ['/bin/sh','-c']
     args: ['sleep 5 && envoy -c /etc/envoy/envoy.yaml']   #这里睡眠5秒是因为下边的启动完执行命令和主容器是一起运行的，如果不加下边的文件为下载完，主容器启动会报错的，所以这里主容器先睡5秒，等文件下载完之后在启动
     lifecycle:
        postStart:
           exec:
              command: ['/bin/sh','-c','wget -O /etc/envoy/envoy.yaml http://ilinux.io/envoy.yaml']
   - name: demo
     image: ikubernetes/demoapp:v1.0
     imagePullPolicy: IfNotPresent
     env:
     - name: HOST
       value: "127.0.0.1"
     - name: PORT
       value: "8080"

四、Pod容器的资源需求和限制

4.1 资源选项

resources选项可以定义在pod级别也可以定义在容器级别
requests：下阈值，表示最少需要多少资源cpu和内存
limits：上阈值，表示最多能使用多少资源

查看选项说明
kubectl explain pods.spec.containers.resources

yaml格式
apiVersion: v1
kind: Pod
metadata:
   name: ...
spec:
   containers:
   - name: ...
     image: ...
     resources:
        requests:
           cpu: ...
           memory:  ...
        limits:
           cpu: ...
           memroy: ...

4.2 示例

4.2.1 requests示例

  1. 部署
apiVersion: v1
kind: Pod
metadata:
   name: stress-pod   #压力测试pod
spec:
   containers:
   - name: stress
     image: ikubernetes/stress-ng
     command: ["/usr/bin/stress-ng", "-c 1", "-m 1", "--metrics-brief"]
     resources:
        requests:
           cpu: "200m"
           memory:  "128Mi"
        limits:
           cpu: "400M"
           memroy: "512Mi"
  1. 验证
查看内存和cpu
kubectl exec stress-pod -- top

4.2.2 limits示例

  1. 部署
用于测试内存泄漏的
apiVersion: v1
kind: Pod
metadata:
  name: memleak-pod    #内存泄漏
  labels:
    app: memleak
spec:
  containers:
  - name: simmemleak
    image: ikubernetes/simmemleak
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        memory: "64Mi"
        cpu: "1"
      limits:
        memory: "64Mi"
        cpu: "1"
  1. 验证
kubectl apply -f resource-limits-demo.yaml

根据以下情况可以看到OOM，会看到会重启，而且重启的间隔时间越来越长
[root@master01 ~]# kubectl get pods -o wide -w

NAME          READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
memleak-pod   0/1     Pending   0          0s    <none>   <none>   <none>           <none>
memleak-pod   0/1     Pending   0          0s    <none>   node02   <none>           <none>
memleak-pod   0/1     ContainerCreating   0          0s    <none>   node02   <none>           <none>
memleak-pod   0/1     OOMKilled           0          1s    10.244.2.3   node02   <none>           <none>
memleak-pod   0/1     OOMKilled           1          2s    10.244.2.3   node02   <none>           <none>
memleak-pod   0/1     CrashLoopBackOff    1          3s    10.244.2.3   node02   <none>           <none>
memleak-pod   0/1     OOMKilled           2          15s   10.244.2.3   node02   <none>           <none>
memleak-pod   0/1     CrashLoopBackOff    2          27s   10.244.2.3   node02   <none>           <none>
memleak-pod   0/1     OOMKilled           3          41s   10.244.2.3   node02   <none>           <none>
memleak-pod   0/1     CrashLoopBackOff    3          55s   10.244.2.3   node02   <none>           <none>

4.3 服务质量类别

QoS Class：服务质量类别，代表了Pod的资源被优先满足的类别

  1. Guaranteed：Pod内的每个容器都分别设定了CPU和Memroy资源需求和资源限制，CPU的需求与限制相等，而且Memory的需求与限制也相等；
  2. Bustable：设置了CPU或Memory，无论设置了几个或多少，都处于这个级别
  3. BestEffort：未为任何一个容器设定任何需求或限制；

如果节点资源不够了，pod中是会按照以上这几个级别保证容器的运行，1优先保证，2之后，3最低级别。

五、整理yaml示例

5.1 大部分示例yaml及解释

apiVersion: v1
kind: Pod
metadata:
  name: all-in-one
  namespace: default
spec:
  #初始化容器：1.设置iptables规则，将8080端口的请求重定向到80端口
  #2.securityContext选项定义了：修改大部分内核参数的特权权限
  initContainers:
  - name: iptables-init
    image: ikubernetes/admin-box:latest
    imagePullPolicy: IfNotPresent
    command: ['/bin/sh','-c']
    args: ['iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80']
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
  containers:
  #sidecar-proxy作用：主要是代理demo容器的8080端口
  #livenessProbe选项：设置了检测容器状态的配置；使用的tcpSocket方法，检测80端口是否是通的
  #readinessProbe选项：设置了检测容器是否就绪的配置；使用的tcpSocket方法，检测80端口是否是通的
  - name: sidecar-proxy
    image: envoyproxy/envoy-alpine:v1.13.1
    command: ['/bin/sh','-c']
    args: ['sleep 3 && envoy -c /etc/envoy/envoy.yaml']
    lifecycle:
      postStart:
        exec:
          command: ['/bin/sh','-c','wget -O /etc/envoy/envoy.yaml http://ilinux.io/envoy.yaml']
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5     #容器启动五秒之后才会周期性检测80端口的状态
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
    #demo容器：1.设置了web端口为8080
    #2.livenessProbe选项使用的是httpGet方法，检测的是访问ip:端口/livez路径返回是否是200，不是200就会重启
    #3.readinessProbe选项使用的是httpGet方法，检测的是访问ip:端口/readyz路径返回是否是200，不是200就会重启；这里的initialDelaySeconds（容器启动之后的检测时间）写15秒，是因为要保证livenessProbe先检测
    #4.securityContext选项：设置了运行用户和组
    #5.resources选项：设置的是下阈值cpu和memory分别为：0.5核和64mb；上阈值cpu和memory分别为：2核和1024mb
    - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    env:
    - name: PORT
      value: '8080'
    livenessProbe:
      httpGet:
        path: '/livez'
        port: 8080
      initialDelaySeconds: 5
    readinessProbe:
      httpGet:
        path: '/readyz'
        port: 8080
      initialDelaySeconds: 15
    securityContext:
      runAsUser: 1001
      runAsGroup: 1001
    resources:
      requests:
        cpu: 0.5
        memory: "64Mi"
      limits:
        cpu: 2 
        memory: "1024Mi"
  #这里的securityContext选项是设置在pod级别的，表示容器设置的运行用户只能在1002和1003之间
  securityContext:
    supplementalGroups: [1002, 1003]
    fsGroup: 2000

5.2 deployment中设置readinessProbe示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demoapp-with-readiness
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: demoapp-with-readiness
    spec:
      containers:
      - image: ikubernetes/demoapp:v1.0
        name: demoapp
        imagePullPolicy: IfNotPresent
        readinessProbe:
          httpGet:
            path: '/readyz'
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 10

---
apiVersion: v1
kind: Service
metadata:
  name: services-readiness-demo
  namespace: default
spec:
  selector:
    app: demoapp-with-readiness
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
# kubernetes
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes