3.pod详解

smile_pbb

已于 2022-02-06 13:53:48 修改

阅读量278

点赞数

分类专栏： K8S 文章标签： kubernetes docker 容器

于 2021-06-05 19:44:06 首次发布

本文链接：https://blog.csdn.net/smile_pbb/article/details/117604667

版权

K8S 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、pod的资源清单

1. 1级清单

#通过以下命令可以查看pod可以编写的1级清单参数
kubectl explain pod

在显示结果中
FIELDS: 中规定了pod的资源清单可以写哪些1级资源清单
比如： 
	apiVersion	<string>
	kind	    <string>
	metadata	<Object>
	spec	    <Object>
	status	    <Object>

2. 2级清单

#如果想看某个选项的二级清单,命令如下：
kubectl explain pod.metadata
kubectl explain pod.spec

#3级清单依次类推

二、清单详解

在kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分：

1.apiVersion 版本

由kubernetes内部定义，可以用 kubectl api-versions 查询到

[root@t3-tkhijbs-jcsszy-app09 ~]# kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
......
......

2.kind 类型

由kubernetes内部定义可以用 kubectl api-resources 查询到

3.metadata 元数据

主要是资源标识和说明，常用的有name、namespace、labels等

4.spec 描述

这是配置中最重要的一部分，里面是对各种资源配置的详细描述

5.status 状态信息

里面的内容不需要定义，由kubernetes自动生成

三、spec 详解

1.containers.name

[root@k8s-master01 ~]# kubectl explain pod.spec.containers
KIND:     Pod
VERSION:  v1
RESOURCE: containers <[]Object>   # 数组，代表可以有多个容器
FIELDS:
   name  <string>     			# 容器名称
   image <string>     			# 容器需要的镜像地址
   imagePullPolicy  <string> 	# 镜像拉取策略 
   command  <[]string> 			# 容器的启动命令列表，如不指定，使用打包时使用的启动命令
   args     <[]string>		 	# 容器的启动命令需要的参数列表
   env      <[]Object> 			# 容器环境变量的配置
   ports    <[]Object>     		# 容器需要暴露的端口号列表
   resources <Object>      		# 资源限制和资源请求的设置

首先创建命名空间
kubectl create ns dev

[root@t3-tkhijbs-jcsszy-app09 yaml]# cat nginx-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-base #定义了pod的名字
  namespace: dev
  labels:
    user: bybo
spec:
  containers:
  - name: nginx  #pod里边的第一个容器的名字
    image: nginx
  - name: tomcat #pod里边的第二个容器的名字
    image: tomcat

[root@t3-tkhijbs-jcsszy-app09 yaml]# kubectl apply -f nginx-pod.yaml 
pod/pod-base created

[root@t3-tkhijbs-jcsszy-app09 yaml]# kubectl get pod -n dev
NAME       READY   STATUS    RESTARTS   AGE
pod-base   2/2     Running   0          2m49s

在这里就体现出了一个pod是由一个或者多个容器组成的

2.containers.imagePullPolicy

imagePullPolicy，用于设置镜像拉取策略，kubernetes支持配置三种拉取策略：
(1)Always：总是从远程仓库拉取镜像（一直远程下载）
(2)IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就本地本地没远程下载）
(3)Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错（一直使用本地）

spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPlicy: IfNotPresent
  - name: tomcat
    image: tomcat
    command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]

3.进入pod里的容器

语法：
kubectl exec pod名称 -n dev -c 容器名称 -it  -- bash

例如：
kubectl exec pod-base -n dev -c tomcat -it  -- bash

4.containers.ports

containers的ports选项介绍

[root@k8s-master01 ~]# kubectl explain pod.spec.containers.ports
KIND:     Pod
VERSION:  v1
RESOURCE: ports <[]Object>
FIELDS:
   name         <string>  # 端口名称，如果指定，必须保证name在pod中是唯一的		
   containerPort<integer> # 容器要监听的端口(0<x<65536)
   hostPort     <integer> # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本(一般不用) 
   hostIP       <string>  # 要将外部端口绑定到的主机IP(一般不用)
   protocol     <string>  # 端口协议。必须是UDP、TCP或SCTP。默认为“TCP”。

spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - name: nginx-port
      containerPort: 80
      protocol: TCP

访问pod中的容器：

Podip:容器的Port

5.资源限制resources

kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，他有两个子选项：
limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
requests ：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动

例子：

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    resources: # 资源配额
      limits:  # 限制资源（上限）
        cpu: "2" # CPU限制，单位是core数
        memory: "10Gi" # 内存限制
      requests: # 请求资源（下限）
        cpu: "1"  # CPU限制，单位是core数
        memory: "10Mi"  # 内存限制

四、容器的探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例" 摘除 "，不承担业务流量。kubernetes提供了两种探针来实现容器探测，分别是：
liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量

livenessProbe 决定是否重启容器
readinessProbe 决定是否将请求转发给容器。

上面两种探针目前均支持三种探测方式：

1.Exec命令

在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常

……
  livenessProbe:
    exec:
      command:
      - cat
      - /tmp/healthy
……

实例：

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-exec
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx
    ports: 
    - name: nginx-port
      containerPort: 80
    livenessProbe:
      exec:
        command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令

#这里看到 这个容器重启了3次
[root@t3-tkhijbs-jcsszy-app09 yaml]# kubectl get pod -n dev
NAME                READY   STATUS    RESTARTS   AGE
pod-liveness-exec   1/1     Running   3          106s

[root@t3-tkhijbs-jcsszy-app09 yaml]# kubectl describe pod -n dev
  Warning  Unhealthy  62s (x9 over 2m22s)  kubelet, node03    Liveness probe failed: /bin/cat: /tmp/hello.txt: No such file or directory
  Normal   Killing    62s (x3 over 2m2s)   kubelet, node03    Container nginx failed liveness probe, will be restarted

从详细信息中可以看到"存活性"探针 检测到了问题。然后容器重启

2.TCPSocket

将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常

……      
  livenessProbe:
    tcpSocket:
      port: 8080
……

3.HTTPGet

调用容器内Web应用的URL，如果返回的状态码在200和399之间，则认为程序正常，否则不正常

……
  livenessProbe:
    httpGet:
      path: / #URI地址
      port: 80 #端口号
      host: 127.0.0.1 #主机地址
      scheme: HTTP #支持的协议，http或者https
……

五、容器的重启策略

一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由pod的重启策略决定的，pod的重启策略有 3 种，分别如下：

Always ：容器失效时，自动重启该容器，这也是默认值。
OnFailure ：容器终止运行且退出码不为0时重启
Never ：不论状态为何，都不重启该容器

重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。
例子：

apiVersion: v1
kind: Pod
metadata:
  name: pod-restartpolicy
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - name: nginx-port
      containerPort: 80
    livenessProbe:
      httpGet:
        scheme: HTTP
        port: 80
        path: /hello
  restartPolicy: Never # 设置重启策略为Never

六、容器的调度

在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式：

自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
定向调度：NodeName、NodeSelector
亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
污点（容忍）调度：Taints、Toleration

定向调度nodeName

NodeName用于强制约束将Pod调度到指定的Name的Node节点上。这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-exec
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: node01 #将pod定向调度到node01