k8s Pod管理

已于 2022-09-21 15:53:09 修改
阅读量594 收藏 2
点赞数
分类专栏： k8s 文章标签： kubernetes
于 2022-06-16 18:40:53 首次发布
TimeRovers
本文链接：https://blog.csdn.net/martinlinux/article/details/125299226
版权

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
TimeRovers
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
pod重启策略和状态解释
yan_0916的博客
02-28 4115
一、Pod一直处于Pending状态二、Pod一直处于Waiting 或 ContainerCreating状态三、Pod 一直处于CrashLoopBackOff状态四、Pod处于Error状态五、Pod 处于Terminating或 Unknown状态 一、Pod一直处于Pending状态 Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl.
k8s pod管理
weixin_60551759的博客
01-15 665
DNS domain name service域名解析服务 一.实验环境的搭建 主机作路由 虚拟机添加网关
k8s之Pod控制器(ReplicaSet、Deployment、DaemonSet、job、Cronjob)
yrx420909的博客
04-23 2313
1.控制器 Pod控制器是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试 进行重启，当根据重启策略无效，则会重新新建pod的资源。 Pod 的分类： 自主式 Pod：Pod 退出后不会被创建 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目 控制器类型： Replication Controller和ReplicaSet Depl...
Rancher-[ContainersNotReady] containers with unready status:
最新发布
博然的宝藏库
04-30 154
你计算资源不够了～bro。
k8s-----Pod管理
weixin_46971894的博客
10-28 171
k8s Pod管理Pod简介Pod管理Pod的创建与使用Pod扩容与缩容更新pod与Pod回滚三级目录 Pod简介 Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。 一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker），多个容器间共享IPC、Network和UTC namespace。 Pod管理 启动之前所作的k8s集群部署, [root@server2 ~]# export KUBECONFIG=/etc
k8s——2、pod管理
qq_43604376的博客
05-22 739
文章目录k8s集群内部加入私有harbor仓库pod管理创建pod使用控制器，管理pod副本微服务servicepod的扩容与缩容更改service类型为NodePort更新pod镜像pod镜像版本回滚给kubectl设置别名 使用阿里云主机ECS， 四台主机信息如下： server1 — 私网IP:10.0.0.2 ----公网IP: 47.108.54.185 ---- 搭建docker仓库harbor server2 — 私网IP:10.0.0.3 ----公网IP: 47.108.144.23
k8s pod 管理
m0_59750991的博客
07-29 146
Pod是Kubernetes调度的最小单元。一个Pod可以包含一个或多个容器，因此它可以被看作是内部容器的逻辑宿主机。Pod的设计理念是为了支持多个容器在一个Pod中共享网络和文件系统。因此处于一个Pod中的多个容器共享以下资源： PID命名空间：Pod中不同的应用程序可以看到其他应用程序的进程ID。 network命名空间：Pod中多个容器处于同一个网络命名空间，因此能够访问的IP和端口范围都是相同的。也可以通过localhost相互访问。 IPC命名空间：Pod中的多个容器共享Inner-proc
k8s容器管理工具视频教程.zip
02-19
04-k8s的基础单元pod.mp4 k8s-day2 01-副本控制器rc.mp4 02-新副本控制器deployment.mp4 03-容器的网络访问service.mp4 04-tomcat-app项目持久化.mp4 k8s-day3 01-k8s的dahsboard部署.mp4 02-k8s的dns和heapster监控...
k8s安装部署
01-07
Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。 快速部署应用 快速扩展应用 无缝对接新的应用功能 节省资源，优化硬件资源的使用 Kubernetes 特点 可...
K8S架构解读
02-24
Master是kubernetes的大脑，运行的Deamon服务包括kube-apiserver、kube-scheduler、kube-contronller-manager、etcd和pod网络2.1.1各组件介绍APIServer（kube-apiserver）APIServer提供HTTP/HTTPSRESTfulAPI，即...
k8s-utils
02-13
k8s-utils 用于管理和调试kubernetes集群的帮助程序工具/ Pod
k8s-jumpserver:K8S容器版跳板机，POD自注册，还原传统体验 方便开发调试及线上问题排查。 国内仓库：
05-30
2.Jumpserver外置，可与物理机混合管理，可管理多个K8S集群 二、Modules 1.jumpregister Jumpserver自注册 2.jumpserver 0.3.x版Jumpserver跳板机 3.alpine-ext:weak 轻量sshd (业务负载的基础镜像层) 三、快速开始 ...
Kubernetes（k8s)—Pod管理
xy_的博客
06-25 458
1.pod介绍 <1> pod是可以创建和管理kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。 <2> 一个Pod类似一个豌豆荚，包含一个或多个容器（通常是docker),多个容器间共享IPC，Network和UTC namespace。 2.pod的创建 pod分为俩类，一类是自主式pod，另一类是由控制器来控制的pod。 kubectl get pod ##查看pod kubectl get pod -o wide
k8s之Pod管理
yrx420909的博客
04-22 705
1. 什么是Pod Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。 一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker），多个容器间共享IPC、Network和UTC namespace。 2. 用自主命令的方式运行pod 部署过程中所有需要的镜像均由server4 push到harbor仓库...
k8s(三)pod管理
vpx_srio的博客
05-10 590
通过本文章，可以对pod的基本概念、创建、排错、调度等方面有基本的认识。
K8s---Pod管理之基本操作、资源清单构建与应用、pod生命周期、探针、控制器
m0_62341392的博客
01-12 595
目录 k8s平台使用： Pod管理 外部访问集群节点： 回滚【undo】 集群外部访问： 资源清单构建与应用 pod生命周期 探针 pod的生命 控制器 job控制器： 周期化job k8s平台使用： server2 kubectl get node #查看节点 kubectl get pod #查看pod（pod是k8s最小调度单位） 【默认是在default namespace来进行查询】 kubectl get pod -n kube-system #-...
K8s--k8s的pod管理
qq_43541622的博客
06-30 284
Pod介绍 Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群 中运行的一个进程，每个pod都有一个唯一的ip。 一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker），多个容器间 共享IPC、Network和UTC namespace。 Pod管理 kubectl命令： https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands 配置每个节点的私有仓库，以及每个节点都有相对应证
k8s—pod管理
weixin_54855780的博客
07-28 94
k8s—pod管理什么是pod 什么是pod pod是可以创造和管理kubernetes计算的最小可部署单元，一个pod代表着集群中运行的一个进程，每个pod都都有唯一的ip，一个pod包含一个或多个容器，多个容器间共享IPC、Network和UTC namespace。 在控制端和其它节点开启docker和kubelet systemctl enable --now docker systemctl enable --now kubelet kubectl get cs kubectl get
kubernetes(k8s)之pod管理
qq_36275923的博客
04-24 867
文章目录kubernetes(k8s)之pod管理及资源清单1 Pod管理2 pod的多种方式2.1 自主式的pod2.2 控制器pod(deployment模式pod)2.3 pod间相互访问2.4 外部访问集群ip2.5 pod的滚动更新和回滚 kubernetes(k8s)之pod管理及资源清单 1 Pod管理 2 pod的多种方式 2.1 自主式的pod kubectl指令集：https...
k8s pod 动态伸缩
09-20
如果你想要实现 K8S Pod 的动态伸缩，你可以使用 ReplicaSet 或 Deployment 来管理 Pod 的副本数量，根据需求自动调节 Pod 的数量来实现动态伸缩。 如果要进行 Pod 的动态伸缩，你可以使用 Horizontal Pod ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值