kubernetes: 深入了解Pod对象
kubernetes: 深入了解Pod对象
Pod是K8s中最小部署单元，我们实际的应用都是在pod中运行的，首先pod是k8S中最小的部署单元，也是一组容器的集合，可以是一个容器或多个容器去组成，可以理解为一个pod相当于一个虚拟机，在虚拟机里，你可以创建多个应用，应用就是容器。在一个pod中的容器共享一个网络命名空间。Pod是短暂的
Pod容器分类
Infrastructure Container
#基础容器，维护整个POD网络命名空间的，在一个pod中的容器共享一个网络命名空间，就是由基础容器来搞的，当你创建一个应用时，他就会启动起来，对于用户来说是透明的，所以你看到他创建的网络容器，但你能在节点上看到这个容器
[root@k8s02 ~]# docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ebd34651f2a4 nginx "nginx -g 'daemon of…" 29 minutes ago Up 29 minutes k8s_nginx_nginx-deployment-59c9f8dff-zrbf2_default_563161af-b117-4e0e-ae02-ca72370b072f_0
c5728b6e0a01 registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0 "/pause" 29 minutes ago Up 29 minutes k8s_POD_nginx-deployment-59c9f8dff-zrbf2_default_563161af-b117-4e0e-ae02-ca72370b072f_0
#你会发现有一个使用pause-amd64镜像启动的容器，如果你有印象会想道这个镜像的地址是在kubelet的配置文件中指定的，也就是这里。
[root@k8s02 ~]# cat /opt/kubernetes/cfg/kubelet.conf
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
#这个镜像默认是在Google镜像仓库拉取的，但是国内无法访问，在你每次创建pod的时候，都会启动一个pause-amd64容器，一一对应的，这个操作用户是没有感知的，用户不知道他还启了个这个。
Init Containers
#这种容器启动优先于业务容器开始执行，之前K8S中，一个pod中有多个容器，容器启动也是没有顺序的，都是并行启动，这种容器会早于业务容器启动，做一些初始化工作。
Containers
业务容器，也就是具体部署你应用程序的容器，并行启动，没有顺讯，所以在你定义了容器类型后，启动顺讯就是Infrastructure Container→Init Containers →Containers，目前容器就分这三类。
Pod共享网络
一个pod创建多个容器，在一个pod中定义两个容器，同一个pod包含两个容器，他们会共享一个网络命名空间，端口和网络都是同一个
[root@k8s01 yml]# vim my_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
- name: tomcat
image: tomcat
[root@k8s01 yml]# kubectl create -f my_pod.yaml
pod/my-pod created
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
my-pod 2/2 Running 0 19s
#因为一个pod创建了两个容器所以进入容器加-c
[root@k8s01 yml]# kubectl exec -it my-pod -c nginx bash
root@my-pod:/# exit
[root@k8s01 yml]# kubectl exec -it my-pod -c tomcat bash
root@my-pod:/usr/local/tomcat# cd
root@my-pod:~#
Pod共享存储
通过数据卷挂载进行数据持久化，可以在多个节点上面相互的漂移,emptyDir这个数据卷可以实现多个数据之间的共享
[root@k8s01 yml]# vim my_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod2
spec:
containers:
- name: write
image: centos
command: ["bash","-c","for i in {1..100};do echo $i >> /data/hello;sleep 1;done"]
volumeMounts:
- name: data
mountPath: /data
- name: read
image: centos
command: ["bash","-c","tail -f /data/hello"]
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: data
emptyDir: {}
#解释
emptyDir 会在k8s工作节点创建一个空目录，名字为data，让容器分别挂载data
[root@k8s01 yml]# kubectl apply -f my_pod.yaml
pod/my-pod2 created
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
my-pod2 2/2 Running 0 22s
[root@k8s01 yml]#
#验证结果
[root@k8s01 yml]# kubectl exec -it my-pod2 -c write bash
[root@my-pod2 /]# cd /data/
[root@my-pod2 data]# ls
hello
[root@my-pod2 data]# tail -f hello
28
29
30
31
32
33
34
35
36
37
38
^C
[root@my-pod2 data]# exit
[root@k8s01 yml]# kubectl logs my-pod2 read
1
2
3
4
5
6
7
8
9
10
11
12
13
Pod镜像拉取策略
#这个是通过imagePullpolicy这个字段来设置的，目前有三种策略
| 参数 | 描述 |
|---|---|
| IfNotPresent | 默认值，镜像在宿主机上不存在才会拉取 |
| Always | 每次创建一个Pod都会重新拉取一次镜像 |
| Never | Pod永远不会主动拉取这个镜像 |
Pod 拉取私有仓库镜像
私有仓库是需要登陆的，认证过了之后就能下载了，所以在YAML文件中要添加一个imagePullSecrets的认证凭据，在本机登陆了并不代表通过k8S去部署时也是以登陆状态去拉取镜像的，docker和K8S使用的凭证并不是一套，是独立的
#~/.docker目录下，这个文件会保存登陆信息，现在需要将它编码，使用base64
[root@docker01 harbor]# cat ~/.docker/config.json | base64 -w 0
ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjEwLjgwIjogewoJCQkiYXV0aCI6ICJZV1J0YVc0Nk1USXpORFUyIgoJCX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8xOS4wMy45IChsaW51eCkiCgl9Cn0=
这个就是配置凭据要用到的，然后需要创建一个Secret来管理这个凭据，主要是配置一下加密的数据
[root@k8s01 ~]# cat Secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: registry-secret
data:
.dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjEwLjgwIjogewoJCQkiYXV0aCI6ICJZV1J0YVc0Nk1USXpORFUyIgoJCX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8xOS4wMy45IChsaW51eCkiCgl9Cn0=
type: kubernetes.io/dockerconfigjson
#然后创建一下
[root@k8s01 ~]# kubectl apply -f Secret.yaml
secret/registry-secret created
[root@k8s01 ~]# kubectl get secrets
NAME TYPE DATA AGE
registry-secret kubernetes.io/dockerconfigjson 1 20s
[root@k8s01 ~]#
可以看到data是1，如果是0说明数据没有保存进去，所以我们现在拿着个名字就可以配置到文件了。
[root@k8s01 yml]# cat nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
imagePullSecrets:
- name: registry-secret
containers:
- image: 192.168.10.80/opesn/nginx:1.16.1
imagePullPolicy: Always
name: nginx
ports:
- containerPort: 80
创建
[root@k8s01 yml]# kubectl apply -f nginx.yaml
#查看创建过程
[root@k8s01 yml]# kubectl describe pods nginx-deployment-5d85999f48-2rzp4
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 116s default-scheduler Successfully assigned default/nginx-deployment-5d85999f48-2rzp4 to k8s03
Normal Pulling 116s kubelet, k8s03 Pulling image "192.168.10.80/opesn/nginx:1.16.1"
Normal Pulled 116s kubelet, k8s03 Successfully pulled image "192.168.10.80/opesn/nginx:1.16.1"
Normal Created 115s kubelet, k8s03 Created container nginx
Normal Started 115s kubelet, k8s03 Started container nginx
Pod资源限制
为了防止一个pod占用资源过高影响到宿主机，在K8S中，资源限制主要分为两个方面，一个是limits，一个是requests。
limits是对资源的总限制，而requests是在pod创建时分配的最低资源，在创建pod的时候，K8S会根据requests值去做调度分配，也就是说如果你现在有N个node，现在需要创建一个pod，但是node1的资源已经满足不了创建pod的requests值，这个pod就不会被调度到node1，只有满足requests这个值的服务器才会被调度过去
[root@k8s01 yml]# cat wordpress.yaml
apiVersion: v1
kind: Pod
metadata:
name: wordpress
spec:
containers:
- name: db
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "passwd"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: wp
image: wordpress
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
上面Pod有两个容器。每个容器的requests值为0.25 cpu 和 64MiB内存，因为是两个容器，所以请求最低的资源为0.5 cpu和 128MiB 内存，也就是pod在创建时需要分配的最低资源，这个值会比limits值低。
每个容器的limits值为0.5 cpu和 128MiB 内存，所以这个pod的总限制为1 cpu和256内存，其实上面写的那些他都是通过docker run的一些命令去实现的，request.cpu等同于用--cpu-shares参数去限制，limits.cpu等同于--cpu-quota参数去限制，内存这块相当于是使用--memory值去限制
#创建资源文件
[root@k8s01 yml]# kubectl create -f wordpress.yaml
pod/wordpress created
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
wordpress 2/2 Running 0 8s
[root@k8s01 yml]# kubectl describe pods wordpress
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 7s default-scheduler Successfully assigned default/wordpress to k8s03
Normal Pulling 7s kubelet, k8s03 Pulling image "mysql"
Normal Pulled 4s kubelet, k8s03 Successfully pulled image "mysql"
Normal Created 4s kubelet, k8s03 Created container db
Normal Started 4s kubelet, k8s03 Started container db
Normal Pulling 4s kubelet, k8s03 Pulling image "wordpress"
Normal Pulled 1s kubelet, k8s03 Successfully pulled image "wordpress"
Normal Created 1s kubelet, k8s03 Created container wp
Normal Started 0s kubelet, k8s03 Started container wp
可以看到他是被调度到k8s03节点了，然后去看一下k8s03上所有pod的资源利用率。
[root@k8s01 yml]# kubectl describe nodes k8s03
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
default wordpress 500m (50%) 1 (100%) 128Mi (6%) 256Mi (13%) 62s
kube-system coredns-6d8cfdd59d-qlp8l 100m (10%) 0 (0%) 70Mi (3%) 170Mi (9%) 43m
kube-system kube-flannel-ds-amd64-t7xsj 100m (10%) 100m (10%) 50Mi (2%) 50Mi (2%) 37h
kubernetes-dashboard dashboard-metrics-scraper-566cddb686-cb2g7 0 (0%) 0 (0%) 0 (0%) 0 (0%) 43m
kubernetes-dashboard kubernetes-dashboard-7b5bf5d559-zqp2h 0 (0%) 0 (0%) 0 (0%) 0 (0%) 43m
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 700m (70%) 1100m (110%)
memory 248Mi (13%) 476Mi (25%)
ephemeral-storage 0 (0%) 0 (0%)
可以看到CPU Requests为500，也就是0.5 CPU，CPU Limits为1，也就是1 cpu，Memory Requests为128M，Memory Limits为256M，后面的百分号是代表目前使用了多少，没问题，和指定的一样，删掉就行了
Pod重启策略
决定了pod在故障后所做的动作，这个策略是由restartPolicy参数来设置的，，和--restart的选项几乎一样，一共有三个参数,现默认是Always，也就是说你容器停了，不管是什么原因停的，他就会帮你再启动一个新的，不是重启，pod是没有重启这个概念的，之前的容器挂了就是挂了，不管，他会直接去启一个新的。
| 参数 | 描述 |
|---|---|
| Always | 容器终止退出后总是重启容器，默认策略 |
| OnFailure | 当容器异常退出(退出状态码非0)时才重启容器 |
| Never | 当容器终止退出，从不重启容器 |
指定重启策略
[root@k8s01 yml]# vim nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
restartPolicy: Never
现在是Never，也就是说你容器停了，再也不会启动了。
Pod健康检查
健康检查，用来检测你容器里应用是否存活，保障应用程序在生产环境存活的重要手段，目前为止Probe有两种类型
| 类型 | 描述 |
|---|---|
| livenessProbe | 如果检查失败，杀死容器，根据pod的restartPolicy来操作 |
| readinessProbe | 如果检查失败，Kubernetes会把Pod从service endpoints中剔除掉 |
livenessProbe 类型
livenessProbe类型的逻辑是这样，restartPolicy策略上文提到过了，也就是重启策略，如果一个容器健康检查失败，就杀了这个容器，根据重启策略去操作，如果是Always就会重新启动一个新的容器，以恢复他的正常工作，以此类推
readinessProbe 类型
service是为pod提供统一入口，endpoints是一个控制器，用来管理所有pod容器的IP的，下面看一下
[root@k8s01 yml]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3d20h
nginx-service NodePort 10.0.0.39 <none> 80:32301/TCP 14s
[root@k8s01 yml]# kubectl get endpoints
NAME ENDPOINTS AGE
kubernetes 192.168.10.91:6443,192.168.10.94:6443 3d20h
nginx-service 10.244.0.24:80,10.244.1.53:80,10.244.2.19:80 28s
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-576cc76cc7-frs8l 1/1 Running 0 36m
nginx-deployment-576cc76cc7-kps4d 1/1 Running 0 36m
nginx-deployment-576cc76cc7-tswqm 1/1 Running 0 36m
上面提到了ENDPOINTS也是一个控制器，他的作用就是动态感知你所有pod的是由哪些IP组成的，这个IP也就是容器的IP，上图可以看到nginx的pod是由三个容器组成的，也有相对应的三个容器IP，并且这个pod被关联到了名为nginx-service的service，可以理解为ENDPOINTS控制器相当于一个地址池，但这个地址池是动态的。
service只是提供了一个负载均衡入口，他并不能知道service所关联的pod是哪些容器IP组成的，所以动态感知这些信息是由ENDPOINTS控制器去做的，这样service才知道要把请求转发到哪里。
所以readinessProbe类型的健康检查失败之后，他的逻辑就是将健康检查失败容器的IP在下面的列表中剔除掉。
健康检查方法
目前健康检查有三种方法
| 方法 | 描述 |
|---|---|
| httpGet | 发送http请求，返回200-400状态码视为成功 |
| exec | 执行shell命令返回状态码为0视为成功 |
| tcpSocket | 发起TCP Socket 建立成功视为成功 |
看实际情况选择使用哪种方法吧，说白了httpGet就是获取http响应头的状态码，exec就是在容器内执行一条命令去判断返回码，tcpSocket就是判断能否和目标端口建立连接
httpGet
常用参数如下
| 参数 | 描述 |
|---|---|
| path | http服务器上请求访问的路径 |
| port | 要访问容器上的哪个端口 |
| scheme | 连接端口的协议(HTTP/HTTPS),默认HTTP(要大写) |
| initialDelaySeconds | 容器启动多长时间开始健康检查 |
| periodSeconds | 监控频率，默认10s，最小1s |
| timeoutSeconds | 超时秒数，默认1s，最小值为1s |
| successThreshold | 检查失败之后最小成功连续次数，默认1，活跃度必须为1 |
| failureThreshold | 检查失败次数，超了这个次数直接根据重启策略进行操作 |
[root@k8s01 yml]# cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /
port: 81
scheme: HTTP
initialDelaySeconds: 3
timeoutSeconds: 1
periodSeconds: 5
successThreshold: 1
failureThreshold: 3
readinessProbe:
httpGet:
path: /
port: 81
scheme: HTTP
initialDelaySeconds: 3
timeoutSeconds: 1
periodSeconds: 5
successThreshold: 1
failureThreshold: 3
这个Deployment两种检查方法都加上了，常用的参数就这些，端口是故意写错的
[root@k8s01 yml]# kubectl create -f deployment.yaml
deployment.apps/nginx-deployment created
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 0/1 Completed 0 44m
nginx-deployment-67c9769f5c-6c85s 0/1 Running 5 3m50s
nginx-deployment-67c9769f5c-6m5gb 0/1 CrashLoopBackOff 5 3m50s
nginx-deployment-67c9769f5c-lcv66 0/1 Running 5 3m50s
可以看到无法启动了，其实端口不对，检查失败，无限重启
[root@k8s01 yml]# kubectl describe pods nginx-deployment-67c9769f5c-lcv66
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned default/nginx-deployment-67c9769f5c-lcv66 to k8s05
Normal Pulled 28s (x2 over 61s) kubelet, k8s05 Successfully pulled image "nginx:latest"
Normal Created 28s (x2 over 61s) kubelet, k8s05 Created container nginx
Normal Started 28s (x2 over 61s) kubelet, k8s05 Started container nginx
Warning Unhealthy 17s (x5 over 57s) kubelet, k8s05 Readiness probe failed: Get http://10.244.2.21:81/: dial tcp 10.244.2.21:81: connect: connection refused
Normal Pulling 14s (x3 over 85s) kubelet, k8s05 Pulling image "nginx:latest"
Warning Unhealthy 14s (x6 over 54s) kubelet, k8s05 Liveness probe failed: Get http://10.244.2.21:81/: dial tcp 10.244.2.21:81: connect: connection refused
Normal Killing 14s (x2 over 44s) kubelet, k8s05 Container nginx failed liveness probe, will be restarted
可以看到在健康检查时连接被拒绝，接下来容器被杀死后重新创建，说明健康检查没有问题，现在已经进入无限重启的状态了，从Started到被Killing用了18，秒简单算一下，用上文的健康检查配置，pod内应用需要在多少秒内启动才不会被杀。
第一个参数initialDelaySeconds设置的3，也就是容器启动三秒后开始检查，如果响应时间超过一秒认为失败(timeoutSeconds)，然后开始重试三次(failureThreshold)，每隔五秒进行一次尝试(periodSeconds)，如果这三次内有一次成功则认为成功(successThreshold)，如果这三次都失败就会根据重启策略进行下一步操作，所以满打满算就是3(容器启动后时间)+3(超时时间)+15(每隔五秒重试三次时间)总共二十一秒，但是实际时间会比这个短一点，如你上文所看到的，所以根据你实际情况对参数进行修改吧，其实只添加initialDelaySeconds&periodSeconds就可以了，剩下的用默认的就够了，下面试试exec方法的。
exec
这种方法就是在容器中执行命令，命令返回结果为0表示健康
[root@k8s01 yml]# cat nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
livenessProbe:
exec:
command:
- cat
- /etc/nginx/nginx.conf
initialDelaySeconds: 3
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 3
我定义的健康检查方式为cat /etc/nginx/nginx.conf这个文件，如果这条命令能执行成功就算健康的，一会正常启动之后吧nginx.conf文件删了就cat不到了
[root@k8s01 yml]# kubectl create -f nginx_pod.yaml
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 22s
[root@k8s01 yml]#
正常启动了，然后去容器里把/etc/nginx/nginx.conf文件删了。
[root@k8s01 ~]# kubectl describe pods nginx
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned default/nginx to k8s02
Normal Pulling 59s (x2 over 2m24s) kubelet, k8s02 Pulling image "nginx:latest"
Warning Unhealthy 59s (x3 over 69s) kubelet, k8s02 Liveness probe failed: cat: /etc/nginx/nginx.conf: No such file or directory
Normal Killing 59s kubelet, k8s02 Container nginx failed liveness probe, will be restarted
Normal Pulled 44s (x2 over 2m9s) kubelet, k8s02 Successfully pulled image "nginx:latest"
Normal Created 44s (x2 over 2m9s) kubelet, k8s02 Created container nginx
Normal Started 43s (x2 over 2m9s) kubelet, k8s02 Started container nginx
还是检查失败容器重启了，这个也可以执行脚本，所以这个适合检查比较复杂的应用程序
tcpSocket
[root@k8s01 yml]# cat nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 3
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 3
[root@k8s01 yml]#
[root@k8s01 yml]# kubectl create -f nginx_pod.yaml
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 22s
[root@k8s01 yml]#
健康检查检查的是80端口，现在把默认的端口换了，重载nginx
root@nginx:/# sed -i 's#80#81#g' /etc/nginx/conf.d/default.conf
root@nginx:/# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
root@nginx:/# nginx -s reload
2020/05/29 08:26:51 [notice] 17#17: signal process started
root@nginx:/# command terminated with exit code 137
[root@k8s01 yml]#
被杀了，看一下现在的状态。
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 1 2m32s
[root@k8s01 yml]#
[root@k8s01 yml]# kubectl describe pods nginx
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned default/nginx to k8s02
Normal Pulling 55s (x2 over 2m52s) kubelet, k8s02 Pulling image "nginx:latest"
Warning Unhealthy 55s (x3 over 65s) kubelet, k8s02 Liveness probe failed: dial tcp 10.244.0.33:80: connect: connection refused
Normal Killing 55s kubelet, k8s02 Container nginx failed liveness probe, will be restarted
Normal Pulled 54s (x2 over 2m40s) kubelet, k8s02 Successfully pulled image "nginx:latest"
Normal Created 54s (x2 over 2m40s) kubelet, k8s02 Created container nginx
Normal Started 54s (x2 over 2m40s) kubelet, k8s02 Started container nginx
阔以看到健康检查失败了，容器被杀重启了，这个tcpSocket比较适合去检查非http服务，像是什么zookeeper&redis之类的东西
健康检查的使用目的就是为了防止容器内的服务异常，如果出现异常会重建容器，保证pod的可用性，在加了健康检查之后，在服务滚动更新创建或是扩展的时候，如果容器健康检查失败，这个容器是不会对外提供服务的，直到健康检查成功之后才会接收请求，生产环境必加。
Pod调度约束
目的是可以将制定的Pod调度的制定的节点上，默认的调度是根据节点的资源利用率去调度，在我们用命令行创建一个Pod的时候，他大概会经历这些步骤。
基于write的机制来做组件之间的协作，当用户创建一个pod时，apiserver接收到创建pod的请求，apiserver会将写请求写入到etcd中，你要创建什么样的pod，pod具有什么属性，都会被写进去。
然后Scheduler调度器通过watch获取到etcd中创建的新pod，调度器根据调度算法，选出新创建的pod应该被调度到那个节点上，然后更新到etcd中，kubectl也会通过watch在etcd中获取到绑定自己的pod，这个的理解就是譬如我当前是node-1上的kubelet，我就会拉取etcd中绑定到node-1的pod，获取到之后通过docker run 将容器启动起来，启动起来之后再更新到etcd中，就是报告当前pod的状态，是ContainerCreating状态还是Running状态，我们通过kubectl get pod去查看的时候，会再次向apiserver发送一个请求，他会获取到etcd中当前pod的状态，然后展现给用户的，调度的流程就是这样。
调度约束
| 字段 | 释义 |
|---|---|
| nodeName | 用于将Pod调度到指定的Node名称上 |
| nodeSelector | 用于将Pod调度到匹配Label的Node上 |
nodeName
指定到k8s02节点上运行
[root@k8s01 yml]# cat nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: web
spec:
nodeName: k8s02
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
[root@k8s01 yml]# kubectl create -f nginx_pod.yaml
pod/nginx created
[root@k8s01 yml]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 41s 10.244.0.34 k8s02 <none> <none>
[root@k8s01 yml]#
大概就是这样，现在就是在k8s02上面了
nodeSelector
既然是使用标签，就需要先给Node节点打一下标签，下面给节点打一个标签
[root@k8s01 yml]# kubectl label nodes k8s02 regin=node-1
node/k8s02 labeled
[root@k8s01 yml]# kubectl label nodes k8s03 regin=node-2
node/k8s03 labeled
[root@k8s01 yml]# kubectl label nodes k8s05 regin=node-3
node/k8s05 labeled
[root@k8s01 yml]#
可以看到有一些默认的标签，这是K8S默认为node打的标签
[root@k8s01 yml]# kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
k8s02 Ready <none> 3d19h v1.16.10 regin=node-1
k8s03 Ready <none> 3d18h v1.16.10 regin=node-2
k8s05 Ready <none> 2d23h v1.16.10 regin=node-3
[root@k8s01 yml]#
#删除标签的方法
kubectl label nodes k8s02 regin-
指定pod只能运行在标签为node-3`节点上
[root@k8s01 yml]# cat nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: web
spec:
nodeSelector:
regin: node-3
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
[root@k8s01 yml]# kubectl create -f nginx_pod.yaml
pod/nginx created
[root@k8s01 yml]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 26s 10.244.2.22 k8s05 <none> <none>
[root@k8s01 yml]#
Pod故障排查
出现如上问题可以使用以下三个命令去排查。
使用kubectl describe查看pod的事件，使用kubectl logs查看容器内日志，使用kubect exec进入到容器中查看应用处于什么样的状态，所以需要了解一个调度的流程
