1、Pod介绍
Pod是Kubernetes进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中
Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器
1）、Pod=进程组
在Kubernetes里面，Pod实际上正是Kubernetes抽象出来的一个可以类比为进程组的概念
由四个进程共同组成的一个应用Helloworld，在Kubernetes里面，实际上会被定义为一个拥有四个容器的Pod
就是说现在有四个职责不同、相互协作的进程，需要放在容器里去运行，在Kubernetes里面并不会把它们放到一个容器里，Kubernetes会把四个独立的进程分别用四个独立的容器启动起来，然后把它们定义在一个Pod里面
所以当Kubernetes把Helloworld给拉起来的时候，实际上会看到四个容器，它们共享了某些资源，这些资源都属于Pod，所以我们说Pod 在Kubernetes里面只有一个逻辑单位，没有一个真实的东西对应说这个就是Pod。真正起来在物理上存在的东西，就是四个容器。这四个容器，或者说是多个容器的组合就叫做Pod
Pod是Kubernetes分配资源的一个单位，因为里面的容器要共享某些资源，所以Pod也是Kubernetes的原子调度单位
2）、为什么Pod必须是原子调度单位？
假如现在有两个容器，它们是紧密协作的，所以它们应该被部署在一个Pod里面。具体来说，第一个容器叫做App，就是业务容器，它会写日志文件；第二个容器叫做LogCollector，它会把刚刚App容器写的日志文件转发到后端的ElasticSearch中
两个容器的资源需求是这样的：App容器需要1G内存，LogCollector需要0.5G内存，而当前集群环境的可用内存是这样一个情况：Node_A：1.25G内存、Node_B：2G内存
假如说现在没有Pod概念，就只有两个容器，这两个容器要紧密协作、运行在一台机器上。可是，如果调度器先把App调度到了Node_A上面，接下来会怎么样呢？这时会发现：LogCollector实际上是没办法调度到Node_A上的，因为资源不够。其实此时整个应用本身就已经出问题了，调度已经失败了，必须去重新调度
在Kubernetes里，就直接通过Pod这样一个概念去解决了。因为在Kubernetes里，这样的一个App容器和LogCollector容器一定是属于一个Pod的，它们在调度时必然是以一个Pod为单位进行调度，所以这个问题是根本不存在的
3）、Pod里面的容器是超亲密关系
Pod里面的容器是超亲密关系，大概分为以下几类：
- 比如说两个进程之间会发生文件交换，比如一个写日志，一个读日志
- 两个进程之间需要通过localhost或者说是本地的Socket去进行通信，这种本地通信也是超亲密关系
- 这两个容器或者是微服务之间，需要发生非常频繁的RPC调用，出于性能的考虑，也希望它们是超亲密关系
- 两个容器或者是应用，它们需要共享某些Linux Namespace。最简单常见的一个例子，就是我有一个容器需要加入另一个容器的Network Namespace。这样我就能看到另一个容器的网络设备，和它的网络信息
4）、Infra container（也叫Pause容器）
每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：
-
业务容器（用户程序所在的容器）：数量可多可少
-
Infra container：每个Pod都会有的一个根容器
1）共享网络
如上图所示，这个Pod里有两个用户容器A和B，还有一个Infra container。Infra container是一个非常小的镜像，大概100~200KB左右，是一个汇编语言写的、永远处于暂停状态的容器
整个Pod里Infra container第一个启动，在Infra containerHold住Network Namespace后，用户容器就可以加入到Infra container的Network Namespace当中了
所以说一个Pod里面的所有容器，它们看到的网络视图是完全一样的。即：它们看到的网络设备、IP地址、Mac地址等等，跟网络相关的信息，其实全是一份，这一份都来自于Pod第一次创建的这个Infra container。这就是Pod解决网络共享的一个解法
这也就意味着，对于Pod里的容器A和容器B来说：
- 它们可以直接使用localhost进行通信
- 它们看到的网络设备跟Infra container看到的完全一样
- 一个Pod只有一个IP地址，也就是这个Pod的Network Namespace对应的IP地址
- 其他的所有网络资源，都是一个Pod一份，并且被该Pod中的所有容器共享
- Pod的生命周期只跟Infra container一致，而与容器A和B无关
而对于同一个Pod里面的所有用户容器来说，它们的进出流量，也可以认为都是通过Infra container完成的
2）共享存储
有了Infra container这个设计之后，共享Volume就简单多了：Kubernetes只要把所有Volume的定义都设计在Pod层级即可
这样，一个Volume对应的宿主机目录对于Pod来说就只有一个，Pod里的容器只要声明挂载这个Volume，就一定可以共享这个Volume对应的宿主机目录。比如下面这个例子：
apiVersion: v1
kind: Pod
metadata:
name: two-containers
spec:
restartPolicy: Never
volumes:
- name: shared-data
hostPath:
path: /data
containers:
- name: nginx-container
image: nginx
volumeMounts:
- name: shared-data
mountPath: /usr/share/nginx/html
- name: debian-container
image: debian
volumeMounts:
- name: shared-data
mountPath: /pod-data
command: ["/bin/sh"]
args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]
在这个例子中，debian-container和nginx-container都声明挂载了shared-data这个Volume。而shared-data是hostPath类型。所以，它对应在宿主机上的目录就是：/data。而这个目录，其实就被同时绑定挂载进了上述两个容器当中
这就是nginx-container可以从它的/usr/share/nginx/html目录中，读取到debian-container生成的index.html文件的原因
3）Infra container的作用
- 整个Pod的生命周期就等同于Infra container的生命周期，可以以它为依据，评估整个Pod的健康状态
- Pod里的多个业务容器共享Infra container的IP，共享Infra container挂载的Volume，既简化了密切关联的业务容器之间的通讯问题，也很好地解决了它们之间的文件共享问题
5）、Pod定义
下面是Pod的资源清单：
apiVersion: v1 # 必选，版本号，例如v1
kind: Pod # 必选，资源类型，例如Pod
metadata: # 必选，元数据
name: string # 必选，Pod名称
namespace: string # Pod所属的命名空间，默认为"default"
labels: # 自定义标签列表
- name: string
spec: # 必选，Pod中容器的详细定义
containers: # 必选，Pod中容器列表
- name: string # 必选，容器名称
image: string # 必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] # 镜像拉取策略
command: [string] # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] # 容器的启动命令参数列表
workingDir: string # 容器的工作目录
volumeMounts: # 挂载到容器内部的存储卷配置
- name: string # 引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string # 存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean # 是否为只读模式
ports: # 需要暴露的端口库号列表
- name: string # 端口的名称
containerPort: int # 容器需要监听的端口号
hostPort: int # 容器所在主机需要监听的端口号，默认与Container相同
protocol: string # 端口协议，支持TCP和UDP，默认TCP
env: # 容器运行前需设置的环境变量列表
- name: string # 环境变量名称
value: string # 环境变量的值
resources: # 资源限制和请求的设置
limits: # 资源限制的设置
cpu: string # Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string # 内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: # 资源请求的设置
cpu: string # Cpu请求，容器启动的初始可用数量
memory: string # 内存请求，容器启动的初始可用数量
lifecycle: # 生命周期钩子
postStart: # 容器启动后立即执行此钩子，如果执行失败，会根据重启策略进行重启
preStop: # 容器终止前执行此钩子，无论结果如何，容器都会终止
livenessProbe: # 对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: # 对Pod容器内检查方式设置为exec方式
command: [string] # exec方式需要制定的命令或脚本
httpGet: # 对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: # 对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 # 容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 # 对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 # 对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] # Pod的重启策略
nodeName: <string> # 设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject # 设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: # Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false # 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: # 在该pod上定义共享存储卷列表
- name: string # 共享存储卷名称 （volumes类型有很多种）
emptyDir: {} # 类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string # 类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string # Pod所在宿主机的目录，将被用于同期中mount的目录
secret: # 类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: # 类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
可通过一个命令来查看每种资源的可配置项
kubectl explain 资源类型：查看某种资源可以配置的一级属性kubectl explain 资源类型.属性：查看属性的子属性
[root@k8s-master ~]# kubectl explain pod
KIND: Pod
VERSION: v1
FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
spec <Object>
status <Object>
[root@k8s-master ~]# kubectl explain pod.metadata
KIND: Pod
VERSION: v1
RESOURCE: metadata <Object>
FIELDS:
annotations <map[string]string>
clusterName <string>
creationTimestamp <string>
deletionGracePeriodSeconds <integer>
deletionTimestamp <string>
finalizers <[]string>
generateName <string>
generation <integer>
labels <map[string]string>
managedFields <[]Object>
name <string>
namespace <string>
ownerReferences <[]Object>
resourceVersion <string>
selfLink <string>
uid <string>
在Kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分：
apiVersion <string>：版本，由Kubernetes内部定义，版本号必须可以用kubectl api-versions查询到kind <string>：类型，由Kubernetes内部定义，版本号必须可以用kubectl api-resources查询到metadata <Object>：元数据，主要是资源标识和说明，常用的有name、namespace、labels等spec <Object>：描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述status <Object>：状态信息，里面的内容不需要定义，由Kubernetes自动生成
在上面的属性中，spec是接下来研究的重点，继续看下它的常见子属性:
containers <[]Object>：容器列表，用于定义容器的详细信息nodeName <String>：根据nodeName的值将Pod调度到指定的Node节点上nodeSelector <map[]>：根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node 上hostNetwork <boolean>：是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络volumes <[]Object>：存储卷，用于定义Pod上面挂在的存储信息restartPolicy <string>：重启策略，表示Pod在遇到故障的时候的处理策略
2、Pod配置
本小节主要来研究pod.spec.containers属性，这也是Pod配置中最为关键的一项配置
[root@k8s-master ~]# kubectl explain pod.spec.containers
KIND: Pod
VERSION: v1
RESOURCE: containers <[]Object> # 数组，代表可以有多个容器
FIELDS:
args <[]string> # 容器的启动命令需要的参数列表
command <[]string> # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
env <[]Object> # 容器环境变量的配置
envFrom <[]Object>
image <string> # 容器需要的镜像地址
imagePullPolicy <string> # 镜像拉取策略
lifecycle <Object>
livenessProbe <Object>
name <string> -required- # 容器名称
ports <[]Object> # 容器需要暴露的端口号列表
readinessProbe <Object>
resources <Object> # 资源限制和资源请求的设置
securityContext <Object>
startupProbe <Object>
stdin <boolean>
stdinOnce <boolean>
terminationMessagePath <string>
terminationMessagePolicy <string>
tty <boolean>
volumeDevices <[]Object>
volumeMounts <[]Object>
workingDir <string>
1）、基本配置
创建dev namespace，后续操作都在该namespace上进行
# 创建namespace
[root@k8s-master ~]# kubectl create ns dev
namespace/dev created
# 查看所有的namespace
[root@k8s-master ~]# kubectl get ns
NAME STATUS AGE
default Active 11h
dev Active 12s
kube-node-lease Active 11h
kube-public Active 11h
kube-system Active 11h
kubernetes-dashboard Active 11h
创建pod-base.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-base
namespace: dev
labels:
user: admin
spec:
containers:
- name: nginx
image: nginx:1.17.1
- name: busybox
image: busybox:1.30
上面定义了一个比较简单Pod的配置，里面有两个容器：
- nginx：用1.17.1版本的nginx镜像创建（nginx是一个轻量级web容器）
- busybox：用1.30版本的busybox镜像创建（busybox是一个小巧的linux命令集合）
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-base.yaml
pod/pod-base created
# 查看Pod状况
# READY 1/2:表示当前Pod中有2个容器，其中1个准备就绪，1个未就绪
# RESTARTS :重启次数，因为有1个容器故障了，Pod一直在重启试图恢复它
[root@k8s-master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-base 1/2 NotReady 2 53s
# 可以通过describe查看内部的详情
# 此时已经运行起来了一个基本的Pod，虽然它暂时有问题
[root@k8s-master ~]# kubectl describe pod pod-base -n dev
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 9m5s kubelet, k8s-node2 Pulling image "nginx:1.17.1"
Normal Scheduled 8m45s default-scheduler Successfully assigned dev/pod-base to k8s-node2 # pod被调度到k8s-node2节点
Normal Pulled 8m42s kubelet, k8s-node2 Successfully pulled image "nginx:1.17.1"
Normal Created 8m41s kubelet, k8s-node2 Created container nginx
Normal Started 8m41s kubelet, k8s-node2 Started container nginx # 启动nginx容器
Normal Pulling 8m41s kubelet, k8s-node2 Pulling image "busybox:1.30"
Normal Pulled 8m38s kubelet, k8s-node2 Successfully pulled image "busybox:1.30"
Normal Created 7m58s (x4 over 8m38s) kubelet, k8s-node2 Created container busybox
Normal Started 7m58s (x4 over 8m38s) kubelet, k8s-node2 Started container busybox # 启动busybox容器
Normal Pulled 7m16s (x4 over 8m37s) kubelet, k8s-node2 Container image "busybox:1.30" already present on machine
Warning BackOff 3m56s (x24 over 8m36s) kubelet, k8s-node2 Back-off restarting failed container # 重启失败的容器
2）、镜像拉取
创建pod-imagepullpolicy.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-imagepullpolicy
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: Never # 用于设置镜像拉取策略
- name: busybox
image: busybox:1.30
imagePullPolicy：用于设置镜像拉取策略，Kubernetes支持配置三种拉取策略：
- Always：总是从远程仓库拉取镜像（一直远程下载）
- IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就本地 本地没远程下载）
- Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错 （一直使用本地）
默认值说明：
-
如果镜像tag为具体版本号，默认策略是IfNotPresent
-
如果镜像tag为latest（最终版本），默认策略是Always
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-imagepullpolicy.yaml
pod/pod-imagepullpolicy created
# 查看Pod详情
# 此时明显可以看到nginx镜像有一步Pulling image "nginx:1.17.1"的过程
[root@k8s-master ~]# kubectl describe pod pod-imagepullpolicy -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 50s kubelet, k8s-node1 Pulling image "busybox:1.30"
Normal Scheduled 50s default-scheduler Successfully assigned dev/pod-imagepullpolicy to k8s-node1 # pod被调度到k8s-node1节点
Normal Pulled 44s kubelet, k8s-node1 Successfully pulled image "busybox:1.30"
Normal Pulled 28s (x2 over 43s) kubelet, k8s-node1 Container image "busybox:1.30" already present on machine # k8s-node1节点上已经有了busybox:1.30镜像
Normal Created 28s (x3 over 44s) kubelet, k8s-node1 Created container busybox
Warning ErrImageNeverPull 27s (x6 over 50s) kubelet, k8s-node1 Container image "nginx:1.17.1" is not present with pull policy of Never # k8s-node1节点上没有nginx:1.17.1镜像，拉取策略又是Never
Normal Started 27s (x3 over 43s) kubelet, k8s-node1 Started container busybox
Warning Failed 27s (x6 over 50s) kubelet, k8s-node1 Error: ErrImageNeverPull
Warning BackOff 27s (x3 over 42s) kubelet, k8s-node1 Back-off restarting failed container
修改镜像拉取策略为IfNotPresent
apiVersion: v1
kind: Pod
metadata:
name: pod-imagepullpolicy
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent # 用于设置镜像拉取策略
- name: busybox
image: busybox:1.30
# 删除之前创建的Pod
[root@k8s-master ~]# kubectl delete pod pod-imagepullpolicy -n dev
pod "pod-imagepullpolicy" deleted
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-imagepullpolicy.yaml
pod/pod-imagepullpolicy created
# 查看Pod详情
[root@k8s-master ~]# kubectl describe pod pod-imagepullpolicy -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 86s default-scheduler Successfully assigned dev/pod-imagepullpolicy to k8s-node1
Normal Pulling 86s kubelet, k8s-node1 Pulling image "nginx:1.17.1"
Normal Pulled 52s kubelet, k8s-node1 Successfully pulled image "nginx:1.17.1" # 成功拉取nginx:1.17.1镜像
Normal Created 52s kubelet, k8s-node1 Created container nginx
Normal Started 51s kubelet, k8s-node1 Started container nginx
Normal Pulled 9s (x4 over 51s) kubelet, k8s-node1 Container image "busybox:1.30" already present on machine
Normal Created 9s (x4 over 51s) kubelet, k8s-node1 Created container busybox
Normal Started 8s (x4 over 51s) kubelet, k8s-node1 Started container busybox
Warning BackOff 8s (x5 over 50s) kubelet, k8s-node1 Back-off restarting failed container
3）、启动命令
在前面的案例中，一直有一个问题没有解决，就是的busybox容器一直没有成功运行，那么到底是什么原因导致这个容器的故障呢？
原来busybox并不是一个程序，而是类似于一个工具类的集合，Kubernetes集群启动管理后，它会自动关闭。解决方法就是让其一直在运行，这就用到了command配置
创建pod-command.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-command
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]
command：用于在Pod中的容器初始化完毕之后运行一个命令
稍微解释下上面命令的意思：
"/bin/sh","-c"：使用sh执行命令
touch /tmp/hello.txt;：创建一个/tmp/hello.txt文件
while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;：每隔3秒向文件中写入当前时间
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-command.yaml
pod/pod-command created
# 查看Pod状态，此时发现两个Pod都正常运行了
[root@k8s-master ~]# kubectl get pod pod-command -n dev
NAME READY STATUS RESTARTS AGE
pod-command 2/2 Running 0 6s
# 进入Pod中的busybox容器，查看文件内容
# 补充一个命令:kubectl exec pod名称 -n 命名空间 -it -c 容器名称 /bin/sh 在容器内部执行命令
# 使用这个命令就可以进入某个容器的内部，然后进行相关操作了
[root@k8s-master ~]# kubectl exec pod-command -n dev -it -c busybox /bin/sh
/ # tail -f /tmp/hello.txt
15:03:45
15:03:48
15:03:51
特别说明：
通过上面发现command已经可以完成启动命令和传递参数的功能，为什么这里还要提供一个args选项，用于传递参数呢？这其实跟docker有点关系，Kubernetes中的command、args两项其实是实现覆盖Dockerfile中ENTRYPOINT的功能
- 如果command和args均没有写，那么用Dockerfile的配置
- 如果command写了，但args没有写，那么Dockerfile默认的配置会被忽略，执行输入的command
- 如果command没写，但args写了，那么Dockerfile中配置的ENTRYPOINT的命令会被执行，使用当前args的参数
- 如果command和args都写了，那么Dockerfile的配置被忽略，执行command并追加上args参数
4）、环境变量
创建pod-env.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-env
namespace: dev
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do /bin/echo $(date +%T);sleep 60; done;"]
env: # 设置环境变量列表
- name: "username"
value: "admin"
- name: "password"
value: "123456"
env：环境变量，用于在Pod中的容器设置环境变量
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-env.yaml
pod/pod-env created
# 进入容器，输出环境变量
[root@k8s-master ~]# kubectl exec pod-env -n dev -c busybox -it /bin/sh
/ # echo $username
admin
/ # echo $password
123456
5）、端口设置
首先看下ports支持的子选项：
[root@k8s-master ~]# kubectl explain pod.spec.containers.ports
KIND: Pod
VERSION: v1
RESOURCE: ports <[]Object>
FIELDS:
containerPort <integer> -required- # 容器要监听的端口(0<x<65536)
hostIP <string> # 要将外部端口绑定到的主机IP(一般省略)
hostPort <integer> # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本(一般省略)
name <string> # 端口名称，如果指定，必须保证name在pod中是唯一的
protocol <string> # 端口协议，必须是UDP、TCP或SCTP，默认为TCP
创建pod-ports.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-ports
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports: # 设置容器暴露的端口列表
- name: nginx-port
containerPort: 80
protocol: TCP
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-ports.yaml
pod/pod-ports created
[root@k8s-master ~]# kubectl get pod pod-ports -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-ports 1/1 Running 0 28s 10.244.2.8 k8s-node1 <none> <none>
访问容器中的程序需要使用的是podIp:containerPort，可以看到该Pod被调度到了k8s-node1节点上
# 在k8s-node1节点上访问podIp:containerPort
[root@k8s-node1 ~]# curl 10.244.2.8:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
6）、资源配额
容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。针对这种情况，Kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，有两个子选项：
- limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
- requests：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动
可以通过上面两个选项设置资源的上下限
创建pod-resources.yaml文件，内容如下：
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" # 内存限制
在这对cpu和memory的单位做一个说明：
- cpu：core数，可以为整数或小数
- memory：内存大小，可以使用Gi、Mi、G、M等形式
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-resources.yaml
pod/pod-resources created
# 查看发现Pod运行正常
[root@k8s-master ~]# kubectl get pod pod-resources -n dev
NAME READY STATUS RESTARTS AGE
pod-resources 1/1 Running 0 19s
修改resources.requests.memory的值为10Gi
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: "10Gi" # 内存限制
# 删除之前创建的Pod
[root@k8s-master ~]# kubectl delete pod pod-resources -n dev
pod "pod-resources" deleted
# 再次创建Pod
[root@k8s-master ~]# kubectl create -f pod-resources.yaml
pod/pod-resources created
# 查看Pod状态，发现Pod启动失败
[root@k8s-master ~]# kubectl get pod pod-resources -n dev
NAME READY STATUS RESTARTS AGE
pod-resources 0/1 Pending 0 14s
# 查看pod详情会发现，如下提示
[root@k8s-master ~]# kubectl describe pod pod-resources -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 49s (x2 over 49s) default-scheduler 0/3 nodes are available: 3 Insufficient memory. # 内存不足
3、Pod生命周期
我们一般将Pod对象从创建至终的这段时间范围称为Pod的生命周期，它主要包含下面的过程：
- pod创建过程
- 运行初始化容器（init container）过程
- 运行主容器（main container）
- 容器启动后钩子（post start）、容器终止前钩子（pre stop）
- 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）
- pod终止过程
在整个生命周期中，Pod会出现5种状态，分别如下：
- 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
- 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
- 成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启
- 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
- 未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致
1）、创建和终止
Pod的创建过程
-
用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer
-
apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
-
apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动
-
scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer
-
node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer
-
apiServer将接收到的pod状态信息存入etcd中
Pod的终止过程
- 用户向apiServer发送删除pod对象的命令
- apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
- 将pod标记为terminating状态
- kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
- 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
- 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行
- pod对象中的容器进程收到停止信号
- 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
- kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见
2）、初始化容器
初始化容器是在Pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：
- 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么Kubernetes需要重启它直到成功完成
- 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行
初始化容器有很多的应用场景，下面列出的是最常见的几个：
- 提供主容器镜像中不具备的工具程序或自定义代码
- 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足
接下来做一个案例，模拟下面这个需求：
假设要以主容器来运行nginx，但是要求在运行nginx之前先要能够连接上mysql和redis所在服务器
为了简化测试，事先规定好mysql（192.168.5.14）和redis（192.168.5.15）服务器的地址
创建pod-initcontainer.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-initcontainer
namespace: dev
spec:
containers:
- name: main-container
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
initContainers:
- name: test-mysql
image: busybox:1.30
command: ['sh', '-c', 'until ping 192.168.5.14 -c 1 ; do echo waiting for mysql...; sleep 2; done;']
- name: test-redis
image: busybox:1.30
command: ['sh', '-c', 'until ping 192.168.5.15 -c 1 ; do echo waiting for reids...; sleep 2; done;']
两个initContainer如果ping不通对应IP就会一直sleep下去，不会退出
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-initcontainer.yaml
pod/pod-initcontainer created
# 查看pod状态
# 发现pod卡在启动第一个初始化容器过程中，后面的容器不会运行
[root@k8s-master ~]# kubectl describe pod pod-initcontainer -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulled 74s kubelet, k8s-node2 Container image "busybox:1.30" already present on machine
Normal Created 74s kubelet, k8s-node2 Created container test-mysql
Normal Started 74s kubelet, k8s-node2 Started container test-mysql
Normal Scheduled 54s default-scheduler Successfully assigned dev/pod-initcontainer to k8s-node2
# 动态查看pod
[root@k8s-master ~]# kubectl get pod pod-initcontainer -n dev -w
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 2m38s
为Pod所在节点新增两个IP，观察Pod的状态变化
# 安装ifconfig
[root@k8s-node2 ~]# yum install net-tools -y
[root@k8s-node2 ~]# ifconfig enp0s3:1 192.168.5.14 netmask 255.255.255.0 up
[root@k8s-node2 ~]# ifconfig enp0s3:1 192.168.5.15 netmask 255.255.255.0 up
Pod状态变化如下：
[root@k8s-master ~]# kubectl get pod pod-initcontainer -n dev -w
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 2m38s
pod-initcontainer 0/1 Init:1/2 0 8m26s
pod-initcontainer 0/1 Init:1/2 0 8m27s
pod-initcontainer 0/1 PodInitializing 0 9m4s
pod-initcontainer 1/1 Running 0 9m5s
两个initContainer ping通对应IP后，执行完成，Pod最终创建完成
3）、钩子函数
钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码
Kubernetes在主容器的启动之后和停止之前提供了两个钩子函数：
- post start：容器创建之后执行，如果失败了会重启容器
- pre stop ：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作
钩子处理器支持使用下面三种方式定义动作：
- Exec命令：在容器内执行一次命令
......
lifecycle:
postStart:
exec:
command:
- cat
- /tmp/healthy
......
- TCPSocket：在当前容器尝试访问指定的socket
......
lifecycle:
postStart:
tcpSocket:
port: 8080
......
- HTTPGet：在当前容器中向某url发起http请求
......
lifecycle:
postStart:
httpGet:
path: / # URI地址
port: 80 # 端口号
host: 127.0.0.1 # 主机地址
scheme: HTTP # 支持的协议，http或者https
......
接下来，以exec方式为例，演示下钩子函数的使用，创建pod-hook-exec.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-hook-exec
namespace: dev
spec:
containers:
- name: main-container
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
lifecycle:
postStart:
exec: # 在容器启动的时候执行一个命令，修改掉nginx的默认首页内容
command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"]
preStop:
exec: # 在容器停止之前停止nginx服务
command: ["/usr/sbin/nginx","-s","quit"]
# 创建pod
[root@k8s-master ~]# kubectl create -f pod-hook-exec.yaml
pod/pod-hook-exec created
# 查看pod
[root@k8s-master ~]# kubectl get pods pod-hook-exec -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-hook-exec 1/1 Running 0 13s 10.244.2.9 k8s-node1 <none> <none>
# 在k8s-node1节点上(Pod所在的节点)访问podIp:containerPort
# nginx的默认首页内容已经改为了postStart...
[root@k8s-node1 ~]# curl 10.244.2.9
postStart...
4）、容器探测
容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么Kubernetes就会把该问题实例摘除，不承担业务流量。Kubernetes提供了两种探针来实现容器探测，分别是：
- liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器
- readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量
livenessProbe决定是否重启容器，readinessProbe决定是否将请求转发给容器
上面两种探针目前均支持三种探测方式：
- Exec命令：在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常
......
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
......
- TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常
......
livenessProbe:
tcpSocket:
port: 8080
......
- HTTPGet：调用容器内web应用的url，如果返回的状态码在200和399之间，则认为程序正常，否则不正常
......
livenessProbe:
httpGet:
path: / # URI地址
port: 80 # 端口号
host: 127.0.0.1 # 主机地址
scheme: HTTP # 支持的协议，http或者https
......
下面以liveness probes为例，做几个演示：
1）方式一：Exec
创建pod-liveness-exec.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-exec
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
exec:
command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-liveness-exec.yaml
pod/pod-liveness-exec created
# 查看Pod详情
[root@k8s-master ~]# kubectl describe pod pod-liveness-exec -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulled 41s kubelet, k8s-node2 Container image "nginx:1.17.1" already present on machine
Normal Created 41s kubelet, k8s-node2 Created container nginx
Normal Started 41s kubelet, k8s-node2 Started container nginx
Warning Unhealthy 22s (x2 over 32s) kubelet, k8s-node2 Liveness probe failed: /bin/cat: /tmp/hello.txt: No such file or directory
Normal Scheduled 21s default-scheduler Successfully assigned dev/pod-liveness-exec to k8s-node2
# 观察上面的信息就会发现nginx容器启动之后就进行了健康检查
# 检查失败之后，容器被kill掉，然后尝试进行重启
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
[root@k8s-master ~]# kubectl get pods pod-liveness-exec -n dev
NAME READY STATUS RESTARTS AGE
pod-liveness-exec 0/1 CrashLoopBackOff 4 2m52s
2）方式二：TCPSocket
创建pod-liveness-tcpsocket.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-tcpsocket
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
tcpSocket:
port: 8080 # 尝试访问8080端口
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-liveness-tcpsocket.yaml
pod/pod-liveness-tcpsocket created
# 查看Pod详情
[root@k8s-master ~]# kubectl describe pod pod-liveness-tcpsocket -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 63s default-scheduler Successfully assigned dev/pod-liveness-tcpsocket to k8s-node1
Normal Pulled 4s (x3 over 63s) kubelet, k8s-node1 Container image "nginx:1.17.1" already present on machine
Normal Created 4s (x3 over 63s) kubelet, k8s-node1 Created container nginx
Normal Started 4s (x3 over 62s) kubelet, k8s-node1 Started container nginx
Warning Unhealthy 4s (x6 over 54s) kubelet, k8s-node1 Liveness probe failed: dial tcp 10.244.2.10:8080: connect: connection refused
Normal Killing 4s (x2 over 34s) kubelet, k8s-node1 Container nginx failed liveness probe, will be restarted
# 观察上面的信息，发现尝试访问8080端口，但是失败了
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
[root@k8s-master ~]# kubectl get pod pod-liveness-tcpsocket -n dev
NAME READY STATUS RESTARTS AGE
pod-liveness-tcpsocket 0/1 CrashLoopBackOff 4 2m30s
3）方式三：HTTPGet
创建pod-liveness-httpget.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-httpget
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
httpGet: # 其实就是访问http://127.0.0.1:80/hello
scheme: HTTP # 支持的协议，http或者https
port: 80 # 端口号
path: /hello # URI地址
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-liveness-httpget.yaml
pod/pod-liveness-httpget created
# 查看Pod详情
[root@k8s-master ~]# kubectl describe pod pod-liveness-httpget -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 39s default-scheduler Successfully assigned dev/pod-liveness-httpget to k8s-node2
Normal Pulled 34s (x2 over 59s) kubelet, k8s-node2 Container image "nginx:1.17.1" already present on machine
Normal Created 34s (x2 over 59s) kubelet, k8s-node2 Created container nginx
Normal Started 34s (x2 over 59s) kubelet, k8s-node2 Started container nginx
Normal Killing 34s kubelet, k8s-node2 Container nginx failed liveness probe, will be restarted
Warning Unhealthy 24s (x4 over 54s) kubelet, k8s-node2 Liveness probe failed: HTTP probe failed with statuscode: 404
# 观察上面信息，尝试访问路径，但是未找到，出现404错误
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
[root@k8s-master ~]# kubectl get pod pod-liveness-httpget -n dev
NAME READY STATUS RESTARTS AGE
pod-liveness-httpget 0/1 CrashLoopBackOff 4 2m26s
4）liveness其他配置
livenessProbe的子属性除了这三种方式，还有一些其他的配置：
[root@k8s-master01 ~]# kubectl explain pod.spec.containers.livenessProbe
[root@k8s-master ~]# kubectl explain pod.spec.containers.livenessProbe
KIND: Pod
VERSION: v1
RESOURCE: livenessProbe <Object>
FIELDS:
exec <Object>
failureThreshold <integer> # 连续探测失败多少次才被认定为失败。默认是3，最小值是1
httpGet <Object>
initialDelaySeconds <integer> # 容器启动后等待多少秒执行第一次探测
periodSeconds <integer> # 执行探测的频率。默认是10秒，最小1秒
successThreshold <integer> # 连续探测成功多少次才被认定为成功。默认是1
tcpSocket <Object>
timeoutSeconds <integer> # 探测超时时间。默认1秒，最小1秒
5）、重启策略
在上一节中，一旦容器探测出现了问题，Kubernetes就会对容器所在的Pod进行重启，其实这是由Pod的重启策略决定的，Pod的重启策略有3种，分别如下：
- Always：容器失效时，自动重启该容器，这也是默认值
- OnFailure：容器终止运行且退出码不为0时重启
- Never：不论状态为何，都不重启该容器
重启策略适用于Pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长
创建pod-restartpolicy.yaml文件，内容如下：
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
[root@k8s-master ~]# kubectl create -f pod-restartpolicy.yaml
pod/pod-restartpolicy created
# 查看Pod详情，发现nginx容器失败
[root@k8s-master ~]# kubectl describe pod pod-restartpolicy -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulled 48s kubelet, k8s-node2 Container image "nginx:1.17.1" already present on machine
Normal Created 48s kubelet, k8s-node2 Created container nginx
Normal Started 48s kubelet, k8s-node2 Started container nginx
Normal Scheduled 28s default-scheduler Successfully assigned dev/pod-restartpolicy to k8s-node2
Warning Unhealthy 23s (x3 over 43s) kubelet, k8s-node2 Liveness probe failed: HTTP probe failed with statuscode: 404
Normal Killing 23s kubelet, k8s-node2 Stopping container nginx
# 多等一会，再观察pod的重启次数，发现一直是0，并未重启
[root@k8s-master ~]# kubectl get pod pod-restartpolicy -n dev
NAME READY STATUS RESTARTS AGE
pod-restartpolicy 0/1 Completed 0 4m10s
4、Pod调度
在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解Kubernetes对Pod的调度规则，Kubernetes提供了四大类调度方式：
- 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
- 定向调度：NodeName、NodeSelector
- 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
- 污点（容忍）调度：Taints、Toleration
1）、定向调度
定向调度：指的是利用在Pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的Node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过Pod运行失败而已
1）NodeName
创建pod-nodename.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: k8s-node1 # 指定调度到k8s-node1节点上
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-nodename.yaml
pod/pod-nodename created
# 查看Pod调度到NODE属性，确实是调度到了k8s-node1节点上
[root@k8s-master ~]# kubectl get pod pod-nodename -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodename 1/1 Running 0 28s 10.244.2.11 k8s-node1 <none> <none>
修改nodeName的值为k8s-node3（并没有k8s-node3节点）
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: k8s-node3 # 指定调度到k8s-node3节点上
# 删除之前创建的Pod，重新创建Pod
[root@k8s-master ~]# kubectl delete pod pod-nodename -n dev
pod "pod-nodename" deleted
[root@k8s-master ~]# kubectl create -f pod-nodename.yaml
pod/pod-nodename created
#再次查看，发现已经向k8s-node3节点调度，但是由于不存在k8s-node3节点，所以Pod无法正常运行
[root@k8s-master ~]# kubectl get pod pod-nodename -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodename 0/1 Pending 0 8s <none> k8s-node3 <none> <none>
2）NodeSelector
NodeSelector用于将Pod调度到添加了指定标签的Node节点上。它是通过Kubernetes的label-selector机制实现的，也就是说，在Pod创建之前，会由Scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标Node，然后将Pod调度到目标节点，该匹配规则是强制约束
# 分别为node节点添加标签
[root@k8s-master ~]# kubectl label node k8s-node1 nodeenv=pro
node/k8s-node1 labeled
[root@k8s-master ~]# kubectl label node k8s-node2 nodeenv=test
node/k8s-node2 labeled
# 查看node节点标签
[root@k8s-master ~]# kubectl get node --show-labels
NAME STATUS ROLES AGE VERSION LABELS
k8s-master Ready master 19h v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
k8s-node1 Ready <none> 19h v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1,kubernetes.io/os=linux,nodeenv=pro
k8s-node2 Ready <none> 19h v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux,nodeenv=test
创建pod-nodeselector.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeSelector:
nodeenv: pro # 指定调度到具有nodeenv=pro标签的节点上
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-nodeselector.yaml
pod/pod-nodeselector created
# 查看Pod调度到NODE属性，确实是调度到了k8s-node1节点上
[root@k8s-master ~]# kubectl get pod pod-nodeselector -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeselector 1/1 Running 0 29s 10.244.2.12 k8s-node1 <none> <none>
修改nodeSelector的值为nodeenv: xxx（不存在打有此标签的节点）
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeSelector:
nodeenv: xxx # 指定调度到具有nodeenv=xxx标签的节点上
# 删除之前创建的Pod，重新创建Pod
[root@k8s-master ~]# kubectl delete pod pod-nodeselector -n dev
pod "pod-nodeselector" deleted
[root@k8s-master ~]# kubectl create -f pod-nodeselector.yaml
pod/pod-nodeselector created
# 再次查看，发现Pod无法正常运行，Node的值为none
[root@k8s-master ~]# kubectl get pod pod-nodeselector -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeselector 0/1 Pending 0 26s <none> <none> <none> <none>
# 查看详情，发现node selector匹配失败的提示
[root@k8s-master ~]# kubectl describe pod pod-nodeselector -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 46s (x2 over 47s) default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.
2）、亲和性调度
上一节，介绍了两种定向调度的方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用Node列表也不行，这就限制了它的使用场景
基于上面的问题，Kubernetes还提供了一种亲和性调度（Affinity）。它在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活
Affinity主要分为三类：
- nodeAffinity（node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题
- podAffinity（pod亲和性） : 以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
- podAntiAffinity（pod反亲和性） : 以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题
关于亲和性（反亲和性）使用场景的说明：
- 亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用的尽可能的靠近，这样可以减少因网络通信而带来的性能损耗
- 反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性
1）nodeAffinity
首先来看一下nodeAffinity的可配置项：
pod.spec.affinity.nodeAffinity
requiredDuringSchedulingIgnoredDuringExecution Node节点必须满足指定的所有规则才可以，相当于硬限制
nodeSelectorTerms 节点选择列表
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
preferredDuringSchedulingIgnoredDuringExecution 优先调度到满足指定的规则的Node，相当于软限制 (倾向)
preference 一个节点选择器项，与相应的权重相关联
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符，支持In、NotIn、Exists、DoesNotExist、Gt、Lt
weight 倾向权重，在范围1-100
关系符的使用说明：
- matchExpressions:
- key: nodeenv # 匹配存在标签的key为nodeenv的节点
operator: Exists
- key: nodeenv # 匹配标签的key为nodeenv，且value是"xxx"或"yyy"的节点
operator: In
values: ["xxx","yyy"]
- key: nodeenv # 匹配标签的key为nodeenv，且value大于"xxx"的节点
operator: Gt
values: "xxx"
接下来演示一下requiredDuringSchedulingIgnoredDuringExecution：
创建pod-nodeaffinity-required.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
nodeAffinity: # 设置node亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
nodeSelectorTerms:
- matchExpressions: # 匹配nodeenv的值在["xxx","yyy"]中的标签
- key: nodeenv
operator: In
values: ["xxx","yyy"]
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-nodeaffinity-required.yaml
pod/pod-nodeaffinity-required created
# 查看Pod状态(运行失败)
[root@k8s-master ~]# kubectl get pod pod-nodeaffinity-required -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeaffinity-required 0/1 Pending 0 19s <none> <none> <none> <none>
# 查看Pod的详情
# 发现调度失败，提示node选择失败
[root@k8s-master ~]# kubectl describe pod pod-nodeaffinity-required -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 66s (x2 over 66s) default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.
修改matchExpressions匹配nodeenv的值在["pro","yyy"]中的标签
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
nodeAffinity: # 设置node亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
nodeSelectorTerms:
- matchExpressions: # 匹配nodeenv的值在["pro","yyy"]中的标签
- key: nodeenv
operator: In
values: ["pro","yyy"]
# 删除之前创建的Pod，重新创建Pod
[root@k8s-master ~]# kubectl delete pod pod-nodeaffinity-required -n dev
pod "pod-nodeaffinity-required" deleted
[root@k8s-master ~]# kubectl create -f pod-nodeaffinity-required.yaml
pod/pod-nodeaffinity-required created
# 此时查看，发现调度成功，已经将Pod调度到了k8s-node1上
[root@k8s-master ~]# kubectl get pod pod-nodeaffinity-required -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeaffinity-required 1/1 Running 0 20s 10.244.2.13 k8s-node1 <none> <none>
再演示一下requiredDuringSchedulingIgnoredDuringExecution：
创建pod-nodeaffinity-preferred.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-preferred
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
nodeAffinity: # 设置node亲和性
preferredDuringSchedulingIgnoredDuringExecution: # 软限制
- weight: 1
preference:
matchExpressions: # 匹配nodeenv的值在["xxx","yyy"]中的标签(当前环境没有)
- key: nodeenv
operator: In
values: ["xxx","yyy"]
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-nodeaffinity-preferred.yaml
pod/pod-nodeaffinity-preferred created
# 查看Pod状态(运行成功)
[root@k8s-master ~]# kubectl get pod pod-nodeaffinity-preferred -n dev
NAME READY STATUS RESTARTS AGE
pod-nodeaffinity-preferred 1/1 Running 0 13s
NodeAffinity规则设置的注意事项：
- 如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能运行在指定的Node上
- 如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可
- 如果一个nodeSelectorTerms中有多个matchExpressions ，则一个节点必须满足所有的才能匹配成功
- 如果一个Pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的节点亲和性需求，则系统将忽略此变化
2）podAffinity
podAffinity主要实现以运行的Pod为参照，实现让新创建的Pod跟参照Pod在一个区域的功能
首先来看一下podAffinity的可配置项：
pod.spec.affinity.podAffinity
requiredDuringSchedulingIgnoredDuringExecution 硬限制
namespaces 指定参照pod的namespace
topologyKey 指定调度作用域
labelSelector 标签选择器
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符，支持In、NotIn、Exists、DoesNotExist
matchLabels 指多个matchExpressions映射的内容
preferredDuringSchedulingIgnoredDuringExecution 软限制
podAffinityTerm 选项
namespaces
topologyKey
labelSelector
matchExpressions
key 键
values 值
operator
matchLabels
weight 倾向权重，在范围1-100
topologyKey用于指定调度时作用域，例如：
- 如果指定为
kubernetes.io/hostname，那就是以Node节点为区分范围 - 如果指定为
beta.kubernetes.io/os，则以Node节点的操作系统类型来区分
接下来演示一下requiredDuringSchedulingIgnoredDuringExecution：
首先创建一个参照Pod，pod-podaffinity-target.yaml：
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-target
namespace: dev
labels:
podenv: pro # 设置标签
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: k8s-node1 # 将目标Pod名确指定到k8s-node1上
# 创建参照Pod
[root@k8s-master ~]# kubectl create -f pod-podaffinity-target.yaml
pod/pod-podaffinity-target created
# 查看Pod，已经将Pod调度到了k8s-node1上
[root@k8s-master ~]# kubectl get pod pod-podaffinity-target -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-podaffinity-target 1/1 Running 0 15s 10.244.2.14 k8s-node1 <none> <none>
创建pod-podaffinity-required.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
podAffinity: # 设置pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 匹配podenv的值在["xxx","yyy"]中的标签
- key: podenv
operator: In
values: ["xxx","yyy"]
topologyKey: kubernetes.io/hostname
上面配置表达的意思是：新Pod必须要与拥有标签podenv=xxx或者podenv=yyy的Pod在同一Node上，显然现在没有这样Pod
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-podaffinity-required.yaml
pod/pod-podaffinity-required created
# 查看pod状态，发现未运行
[root@k8s-master ~]# kubectl get pod pod-podaffinity-required -n dev
NAME READY STATUS RESTARTS AGE
pod-podaffinity-required 0/1 Pending 0 21s
# 查看详情
[root@k8s-master ~]# kubectl describe pod pod-podaffinity-required -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 56s (x2 over 56s) default-scheduler 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod affinity rules, 2 node(s) didn't match pod affinity/anti-affinity.
修改matchExpressions匹配podenv的值在["pro","yyy"]中的标签
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
podAffinity: # 设置pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 匹配podenv的值在["pro","yyy"]中的标签
- key: podenv
operator: In
values: ["pro","yyy"]
topologyKey: kubernetes.io/hostname
# 删除之前创建的Pod，重新创建Pod
[root@k8s-master ~]# kubectl delete pod pod-podaffinity-required -n dev
pod "pod-podaffinity-required" deleted
[root@k8s-master ~]# kubectl create -f pod-podaffinity-required.yaml
pod/pod-podaffinity-required created
# 查看Pod，已经将Pod调度到了k8s-node1上(和参照Pod在同一节点上)
[root@k8s-master ~]# kubectl get pod pod-podaffinity-required -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-podaffinity-required 1/1 Running 0 31s 10.244.2.15 k8s-node1 <none> <none>
3）podAntiAffinity
podAntiAffinity主要实现以运行的Pod为参照，让新创建的Pod跟参照Pod不在一个区域中的功能
它的配置方式和选项跟podAffinty是一样的，这里不再做详细解释，直接做一个测试案例
继续使用上个案例中目标Pod
[root@k8s-master ~]# kubectl get pod pod-podaffinity-target -n dev -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
pod-podaffinity-target 1/1 Running 0 18m 10.244.2.14 k8s-node1 <none> <none> podenv=pro
创建pod-podantiaffinity-required.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-podantiaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
podAntiAffinity: # 设置pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 匹配podenv的值在["pro"]中的标签
- key: podenv
operator: In
values: ["pro"]
topologyKey: kubernetes.io/hostname
上面配置表达的意思是：新Pod必须要与拥有标签podenv=pro的Pod不在同一Node上
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-podantiaffinity-required.yaml
pod/pod-podantiaffinity-required created
# 查看Pod，已经将Pod调度到了k8s-node2上(和参照Pod不在同一节点上)
[root@k8s-master ~]# kubectl get pod pod-podantiaffinity-required -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-podantiaffinity-required 1/1 Running 0 11s 10.244.1.13 k8s-node2 <none> <none>
3）、污点和容忍
1）污点（Taints）
前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来
Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去
污点的格式为：key=value:effect, key和value是污点的标签，effect描述污点的作用，支持如下三个选项：
- PreferNoSchedule：Kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
- NoSchedule：Kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
- NoExecute：Kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离
使用kubectl设置和去除污点的命令示例如下：
# 设置污点
kubectl taint node k8s-node1 key=value:effect
# 去除污点
kubectl taint node k8s-node1 key:effect-
# 去除所有污点
kubectl taint node k8s-node1 key-
接下来，演示下污点的效果：
- 准备节点k8s-node1（为了演示效果更加明显，暂时停止k8s-node2节点）
- 为k8s-node1节点设置一个污点:
tag=test:PreferNoSchedule；然后创建pod1（pod1可以） - 修改为k8s-node1节点设置一个污点:
tag=test:NoSchedule；然后创建pod2（pod1正常，pod2失败） - 修改为k8s-node1节点设置一个污点:
tag=test:NoExecute；然后创建pod3（3个pod都失败）
暂时停止k8s-node2节点，关闭该节点的虚拟机，关闭后k8s-node2状态为NotReady：
[root@k8s-master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 21h v1.18.0
k8s-node1 Ready <none> 21h v1.18.0
k8s-node2 NotReady <none> 21h v1.18.0
# 为k8s-node1设置污点(PreferNoSchedule)
[root@k8s-master ~]# kubectl taint node k8s-node1 tag=test:PreferNoSchedule
node/k8s-node1 tainted
[root@k8s-master ~]# kubectl describe node k8s-node1
Name: k8s-node1
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=k8s-node1
kubernetes.io/os=linux
nodeenv=pro
Annotations: flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"3a:ce:27:0c:c1:6c"}
flannel.alpha.coreos.com/backend-type: vxlan
flannel.alpha.coreos.com/kube-subnet-manager: true
flannel.alpha.coreos.com/public-ip: 10.0.2.15
kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Mon, 07 Feb 2022 10:13:56 +0800
Taints: tag=test:PreferNoSchedule
......
# 创建pod1
[root@k8s-master ~]# kubectl run taint1 --image=nginx:1.17.1 -n dev
pod/taint1 created
[root@k8s-master ~]# kubectl get pod -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
taint1 1/1 Running 0 14s 10.244.2.17 k8s-node1 <none> <none>
# 为k8s-node1设置污点(取消PreferNoSchedule，设置NoSchedule)
[root@k8s-master ~]# kubectl taint node k8s-node1 tag:PreferNoSchedule-
node/k8s-node1 untainted
[root@k8s-master ~]# kubectl taint node k8s-node1 tag=test:NoSchedule
node/k8s-node1 tainted
[root@k8s-master ~]# kubectl describe node k8s-node1
Name: k8s-node1
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=k8s-node1
kubernetes.io/os=linux
nodeenv=pro
Annotations: flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"3a:ce:27:0c:c1:6c"}
flannel.alpha.coreos.com/backend-type: vxlan
flannel.alpha.coreos.com/kube-subnet-manager: true
flannel.alpha.coreos.com/public-ip: 10.0.2.15
kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Mon, 07 Feb 2022 10:13:56 +0800
Taints: tag=test:NoSchedule
......
# 创建pod2
[root@k8s-master ~]# kubectl run taint2 --image=nginx:1.17.1 -n dev
pod/taint2 created
[root@k8s-master ~]# kubectl get pod -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
taint1 1/1 Running 0 3m16s 10.244.2.17 k8s-node1 <none> <none>
taint2 0/1 Pending 0 52s <none> <none> <none> <none>
# 为k8s-node1设置污点(取消NoSchedule，设置NoExecute)
[root@k8s-master ~]# kubectl taint node k8s-node1 tag:NoSchedule-
node/k8s-node1 untainted
[root@k8s-master ~]# kubectl taint node k8s-node1 tag=test:NoExecute
node/k8s-node1 tainted
[root@k8s-master ~]# kubectl describe node k8s-node1
Name: k8s-node1
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=k8s-node1
kubernetes.io/os=linux
nodeenv=pro
Annotations: flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"3a:ce:27:0c:c1:6c"}
flannel.alpha.coreos.com/backend-type: vxlan
flannel.alpha.coreos.com/kube-subnet-manager: true
flannel.alpha.coreos.com/public-ip: 10.0.2.15
kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Mon, 07 Feb 2022 10:13:56 +0800
Taints: tag=test:NoExecute
......
# 创建pod3
[root@k8s-master ~]# kubectl run taint3 --image=nginx:1.17.1 -n dev
pod/taint3 created
# 之前创建的pod1和pod2已被删除，pod3也无法调度
[root@k8s-master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
taint3 0/1 Pending 0 11s
小提示：
使用kubeadm搭建的集群，默认就会给master节点添加一个污点标记，所以Pod就不会调度到master节点上
2）容忍（Toleration）
上面介绍了污点的作用，我们可以在Node上添加污点用于拒绝Pod调度上来，但是如果就是想将一个Pod调度到一个有污点的Node上去，这时候应该怎么做呢？这就要使用到容忍
污点就是拒绝，容忍就是忽略，Node通过污点拒绝Pod调度上去，Pod通过容忍忽略拒绝
下面先通过一个案例看下效果：
- 上一小节，已经在k8s-node1节点上打上了
NoExecute的污点，此时Pod是调度不上去的 - 本小节，可以通过给Pod添加容忍，然后将其调度上去
创建pod-toleration.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
tolerations: # 添加容忍
- key: "tag" # 要容忍的污点的key
operator: "Equal" # 操作符
value: "test" # 容忍的污点的value
effect: "NoExecute" # 添加容忍的规则，这里必须和标记的污点规则相同
# 创建Pod
[root@k8s-master ~]# kubectl create -f pod-toleration.yaml
pod/pod-toleration created
# 添加容忍的pod创建成功(pod-toleration)，没有容忍规则的pod(taint3)依然无法创建
[root@k8s-master ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-toleration 1/1 Running 0 8s
taint3 0/1 Pending 0 7m10s
下面看一下容忍的详细配置：
[root@k8s-master ~]# kubectl explain pod.spec.tolerations
KIND: Pod
VERSION: v1
RESOURCE: tolerations <[]Object>
FIELDS:
effect <string> # 对应污点的effect，空意味着匹配所有影响
key <string> # 对应着要容忍的污点的键，空意味着匹配所有的键
operator <string> # key-value的运算符，支持Equal和Exists(默认)
tolerationSeconds <integer> # 容忍时间，当effect为NoExecute时生效，表示pod在Node上的停留时间
value <string> # 对应着要容忍的污点的值
5、容器设计模式
1）、案例
比如，现在要发布一个应用，这个应用是Java写的，有一个war包需要把它放到Tomcat的web APP目录下面，这样就可以把它启动起来了。可是像这样一个war包或Tomcat这样一个容器的话，怎么去做，怎么去发布？
-
方法一：可以把war包和Tomcat打包放进一个镜像里面。但是这样带来一个问题，无论是要更新war包还是要更新Tomcat，都要重新做一个新的镜像，这是比较麻烦的
-
方式二：镜像里面只打包Tomcat。它就是一个Tomcat，但是需要使用数据卷的方式，比如说hostPath，从宿主机上把war包挂载进Tomcat容器中，挂到web APP目录下面，这样把这个容器启用起来之后，里面就能用了。这样做的问题是需要维护一套分布式存储系统。因为这个容器可能第一次启动是在宿主机A上面，第二次重新启动就可能跑到B上去了，容器它是一个可迁移的东西，它的状态是不保持的。所以必须维护一套分布式存储系统，使容器不管是在A还是在B上，都可以找到这个war包
2）、InitContainer
在上图的yaml里，首先定义一个Init Container，它只做一件事情，就是把war包从镜像里拷贝到一个Volume里面，它做完这个操作就退出了，所以Init Container会比用户容器先启动，并且严格按照定义顺序来依次执行
然后，这个关键在于刚刚拷贝到的这样一个目的目录：APP目录，实际上是一个Volume。而一个Pod里面的多个容器，它们是可以共享Volume的，所以现在这个Tomcat容器，只是打包了一个Tomcat镜像。但在启动的时候，要声明使用APP目录作为我的Volume，并且要把它们挂载在web APP目录下面
而这个时候，由于前面已经运行过了一个Init Container，已经执行完拷贝操作了，所以这个Volume里面已经存在了应用的war包：就是sample.war。等到第二步执行启动这个Tomcat容器的时候，去挂这个Volume，一定能在里面找到前面拷贝来的sample.war
所以这是一个通过组合两个不同角色的容器，并且按照这样一些像Init Container这样一种编排方式，统一的去打包这样一个应用，把它用Pod来去做的非常典型的一个例子。像这样的一个概念，在Kubernetes里面就是一个非常经典的容器设计模式，叫做Sidecar
3）、容器设计模式：Sidecar
什么是Sidecar？就是说其实在Pod里面，可以定义一些专门的容器，来执行主业务容器所需要的一些辅助工作
这种做法一个非常明显的优势就是在于其实将辅助功能从我的业务容器解耦了，所以能够独立发布Sidecar容器，并且更重要的是这个能力是可以重用的，即同样的一个监控Sidecar或者日志Sidecar，可以被全公司的人共用的
1）Sidecar：应用与日志收集
应用日志收集，业务容器将日志写在一个Volume里面，而由于Volume在Pod里面是被共享的，所以日志容器——即Sidecar容器一定可以通过共享该Volume，直接把日志文件读出来，然后存到远程存储里面，或者转发到另外一个例子。现在业界常用的Fluentd日志进程或日志组件，基本上都是这样的工作方式
2）Sidecar：代理容器
假如现在有个Pod需要访问一个外部系统，或者一些外部服务，但是这些外部系统是一个集群，那么这个时候如何通过一个统一的、简单的方式，用一个IP地址，就把这些集群都访问到？有一种方法就是：修改代码。因为代码里记录了这些集群的地址；另外还有一种解耦的方法，即通过Sidecar代理容器
简单说，单独写一个这么小的Proxy，用来处理对接外部的服务集群，它对外暴露出来只有一个IP地址就可以了。所以接下来，业务容器主要访问Proxy，然后由Proxy去连接这些服务集群，这里的关键在于Pod里面多个容器是通过localhost直接通信的，因为它们同属于一个network Namespace，网络视图都一样，所以它们俩通信localhost，并没有性能损耗
所以说代理容器除了做了解耦之外，并不会降低性能，更重要的是，像这样一个代理容器的代码就又可以被全公司重用了
3）Sidecar：适配器容器
比如，现在业务容器暴露出来的监控接口是/metrics，访问这个这个容器的metrics的这个URL就可以拿到了。可是现在，这个监控系统升级了，它访问的URL是/health，我只认得暴露出health健康检查的URL，才能去做监控，metrics不认识。那这个怎么办？那就需要改代码了，但可以不去改代码，而是额外写一个Adapter，用来把所有对health的这个请求转发给metrics就可以了，所以这个Adapter对外暴露的是health这样一个监控的URL，这就可以了
这样的关键还在于Pod之中的容器是通过localhost直接通信的，所以没有性能损耗，并且这样一个Adapter容器可以被全公司重用起来
参考：