学习云计算来千锋教育-云计算学院
免费视频学习--拿走不谢
https://m.bilibili.com/video/av97815587?share_source=weixin_moments&share_medium=iphone&bbid=Z94D8B93F966C9BC431E98FDE5D298560A3B&ts=1584921175&from=timeline
Pod API 对象
Pod是 k8s 项目中的最小编排单位。将这个设计落实到 API 对象上,容器(Container)就成了 Pod 属性里一个普通的字段。
问题:
通过yaml文件创建pod的时候里面有容器,这个文件里面到底哪些属性属于 Pod 对象,哪些属性属于 Container?
解决:
Pod 扮演的是传统环境里"虚拟机"的角色。是为了使用户从传统环境(虚拟机环境)向 k8s(容器环境)的迁移,更加平滑。
把 Pod 看成传统环境里的"机器"、把容器看作是运行在这个"机器"里的"用户程序",那么很多关于 Pod 对象的设计就非常容易理解了。
凡是调度、网络、存储,以及安全相关的属性,基本上是 Pod 级别的
共同特征是,它们描述的是"机器"这个整体,而不是里面运行的"程序"。
比如:
配置这个"机器"的网卡(即:Pod 的网络定义)
配置这个"机器"的磁盘(即:Pod 的存储定义)
配置这个"机器"的防火墙(即:Pod 的安全定义)
这台"机器"运行在哪个服务器之上(即:Pod 的调度)
kind:指定了这个 API 对象的类型(Type),是一个 Pod,根据实际情况,此处资源类型可以是Deployment、Job、Ingress、Service等。
metadata:包含Pod的一些meta信息,比如名称、namespace、标签等信息.
spec:specification of the resource content 指定该资源的内容,包括一些container,storage,volume以及其他Kubernetes需要的参数,以及诸如是否在容器失败时重新启动容器的属性。可在特定Kubernetes API找到完整的Kubernetes Pod的属性。
ˌ
specification----->[spesɪfɪˈkeɪʃn]
容器可选的设置属性:
除了上述的基本属性外,还能够指定复杂的属性,包括容器启动运行的命令、使用的参数、工作目录以及每次实例化是否拉取新的副本。 还可以指定更深入的信息,例如容器的退出日志的位置。
容器可选的设置属性包括:
"name"、"image"、"command"、"args"、"workingDir"、"ports"、"env"、resource、"volumeMounts"、livenessProbe、readinessProbe、livecycle、terminationMessagePath、"imagePullPolicy"、securityContext、stdin、stdinOnce、tty
跟"机器"相关的配置
[root@kub-k8s-master ~]# cd prome/
[root@kub-k8s-master prome]# kubectl get pods
NAME READY STATUS RESTARTS AGE
website 1/1 Running 0 2d23h
[root@kub-k8s-master prome]# kubectl get pod -o wide #查看pod运行在哪台机器上面
![ba6518f79aae34a7e65ea2bfd4f04ab3.png](https://i-blog.csdnimg.cn/blog_migrate/8f78d3b2cf2f0db81a76418edf9d53f3.png)
nodeSelector
nodeName
这两个属性的功能是一样的都是用于人工干预调度器
实战
将node1上面的pod删除掉
[root@kub-k8s-master prome]# kubectl delete -f pod.yml
pod "website" deleted
===========================================
nodeName:是一个供用户将 Pod 与 Node 进行绑定的字段,用法:
现在指定将pod创在node2上面:
[root@kub-k8s-master prome]# vim pod.yml
---
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
spec:
containers:
- name: test-website
image: daocloud.io/library/nginx
ports:
- containerPort: 80
nodeName: kub-k8s-node2 #指定node节点的名称
创建
[root@kub-k8s-master prome]# kubectl apply -f pod.yml
pod/website created
![5af0b87b11767c1918e1be1a431a7739.png](https://i-blog.csdnimg.cn/blog_migrate/fc869682be625894906e0dbdf1fca0ba.png)
NodeName:
一旦 Pod 的这个字段被赋值,k8s就会被认为这个 Pod 已经经过了调度,调度的结果就是赋值的节点名字。这个字段一般由调度器负责设置,用户也可以设置它来"骗过"调度器,这个做法一般是在测试或者调试的时候才会用到。
第二种方式通过node标签
首先我们需要知道node2上面你的标签有哪些?
1.查看node2上面的标签
[root@kub-k8s-master prome]# kubectl describe node kub-k8s-node2
![e1d15e5aaa8e4581dfbacbdf859df63b.png](https://i-blog.csdnimg.cn/blog_migrate/2c9184375afa4aeba54704655258cb2c.jpeg)
1.重新创建一个新的pod
"nodeSelector:是一个供用户将 Pod 与 Node 进行绑定的字段",,通过指定标签来指定
[root@kub-k8s-master prome]# vim tomcat.yml
---
apiVersion: v1
kind: Pod
metadata:
name: tomcat
labels:
app: tomcat
spec:
containers:
- name: test-tomcat
image: daocloud.io/library/tomcat:8
ports:
- containerPort: 8080
nodeSelector: #指定标签
kubernetes.io/hostname: kub-k8s-node2
2.创建pod
[root@kub-k8s-master prome]# kubectl apply -f tomcat.yml
pod/tomcat created
![6e29bbf74c0731eb52af5de3f0fe7103.png](https://i-blog.csdnimg.cn/blog_migrate/ab88dd63d74df38b896e8fcebd26fdb8.png)
表示这个 Pod 永远只能运行在携带了"kubernetes.io/hostname: kub-k8s-node2"标签(Label)的节点上;否则,它将调度失败。
第三个方式主机别名
设置pod容器里面的hosts文件内容,也是做本地解析
HostAliases:定义 Pod 的 hosts 文件(比如 /etc/hosts)里的内容,用法:
![4d85e0fe8d9c40309cd013ef7c3c6bc8.png](https://i-blog.csdnimg.cn/blog_migrate/cba38bc57827610b7a64336c0a27e5e9.png)
1.首先先将刚创建的pod删除掉
[root@kub-k8s-master prome]# kubectl delete -f tomcat.yml
pod "tomcat" deleted
[root@kub-k8s-master prome]# vim tomcat.yml
---
apiVersion: v1
kind: Pod
metadata:
name: tomcat
labels:
app: tomcat
spec:
hostAliases:
- ip: "192.168.246.113" #给哪个ip做解析。实验环境下这个ip自定义的
hostnames:
- "foo.remote" #解析的名字。用引号引起来可以写多个
- "bar.remote"
containers:
- name: test-tomcat
image: daocloud.io/library/tomcat:8
ports:
- containerPort: 8080
2.创建pod
[root@kub-k8s-master prome]# kubectl apply -f tomcat.yml
pod/tomcat created
3.连接pod
[root@kub-k8s-master prome]# kubectl exec -it tomcat /bin/bash
root@tomcat:/usr/local/tomcat# cat /etc/hosts #查看hosts文件
![14fda732bb8265eda3346ebb6052cb23.png](https://i-blog.csdnimg.cn/blog_migrate/056aee81f7b505eb38f1fdb40686f220.jpeg)
注意:在 k8s 中,如果要设置 hosts 文件里的内容,一定要通过这种方法。否则,如果直接修改了 hosts 文件,在 Pod 被删除重建之后,kubelet 会自动覆盖掉被修改的内容。
凡是跟容器的 Linux Namespace 相关的属性,也一定是 Pod 级别的
原因:Pod 的设计,就是要让它里面的容器尽可能多地共享 Linux Namespace,仅保留必要的隔离和限制能力。这样,Pod 模拟出的效果,就跟虚拟机里程序间的关系非常类似了。
举例,一个 Pod 定义 yaml 文件如下:
[root@kub-k8s-master prome]# kubectl delete -f pod.yml
pod "website" deleted
[root@kub-k8s-master prome]# vim pod.yml #修改如下。最好是提前将镜像pull下来。
---
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
spec:
shareProcessNamespace: true #共享进程名称空间
containers:
- name: test-web
image: daocloud.io/library/nginx
ports:
- containerPort: 80
- name: busybos
image: daocloud.io/library/busybox
stdin: true
tty: true
2.创建
[root@kub-k8s-master prome]# kubectl apply -f pod.yml
pod/website created
1. 定义了 shareProcessNamespace=true
表示这个 Pod 里的容器要共享进程(PID Namespace)如果是false则为不共享。
2. 定义了两个容器:
一个 nginx 容器
一个开启了 tty 和 stdin 的 busybos 容器
在 Pod 的 YAML 文件里声明开启它们俩,等同于设置了 docker run 里的 -it(-i 即 stdin,-t 即 tty)参数。
可以直接认为 tty 就是 Linux 给用户提供的一个常驻小程序,用于接收用户的标准输入,返回操作系统的标准输出。为了能够在 tty 中输入信息,需要同时开启 stdin(标准输入流)。
此 Pod 被创建后,就可以使用 shell 容器的 tty 跟这个容器进行交互了。
查看运行在那台机器上面:
![00f4f8a70234865e4305e62a853a19d7.png](https://i-blog.csdnimg.cn/blog_migrate/1ad307293c9bb50735b875ab400bd1ca.png)
我们登录node1的机器连接busybox的容器
![03ade9d5d8cda6769a7a2a7bd824bdf6.png](https://i-blog.csdnimg.cn/blog_migrate/d1584e680d6fe6210e9dbecf8ef3fb91.png)
[root@kub-k8s-node1 ~]# docker exec -it f684bd1d05b5 /bin/sh
![edc560d64c814277264b234a2714b2ac.png](https://i-blog.csdnimg.cn/blog_migrate/b306488a7385075e976655f851373390.jpeg)
在容器里不仅可以看到它本身的 ps 指令,还可以看到 nginx 容器的进程,以及 Infra 容器的 /pause 进程。也就是说整个 Pod 里的每个容器的进程,对于所有容器来说都是可见的:它们共享了同一个 PID Namespace。
将shareProcessNamespace=true修改为false
[root@kub-k8s-master prome]# kubectl delete -f pod.yml
[root@kub-k8s-master prome]# vim pod.yml
将shareProcessNamespace=true修改为false
[root@kub-k8s-master prome]# kubectl apply -f pod.yml
pod/website created
![79b01178a59308e8a247308fed1cb6a8.png](https://i-blog.csdnimg.cn/blog_migrate/d76a4ea9ccadd8d938e8685a1641ee0f.png)
验证:
![411c7d7ebf2c01edb33234439996856c.png](https://i-blog.csdnimg.cn/blog_migrate/8a7bb9ed7bb3c9bb92d571390948ea19.png)
凡是 Pod 中的容器要共享宿主机的 Namespace,也一定是 Pod 级别的定义。
刚才的都是pod里面容器的Namespace,并没有和本机的Namespace做共享,接下来我们可以做与本机的Namespace共享,可以在容器里面看到本机的进程。
[root@kub-k8s-master prome]# kubectl delete -f pod.yml
pod "website" deleted
[root@kub-k8s-master prome]# vim pod.yml #修改如下
---
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
spec:
hostNetwork: true #共享宿主机网络
hostIPC: true #共享ipc通信
hostPID: true #共享宿主机的pid
containers:
- name: test-web
image: daocloud.io/library/nginx
ports:
- containerPort: 80
- name: busybos
image: daocloud.io/library/busybox
stdin: true
tty: true
创建pod
[root@kub-k8s-master prome]# kubectl apply -f pod.yml
pod/website created
![6760056e99d35fbb09ef60180aefe35e.png](https://i-blog.csdnimg.cn/blog_migrate/e13a2587fd5598292b20ca2e706b79a8.png)
验证:
![c72b04aa5d3dc85e192cdeee2d4b961b.png](https://i-blog.csdnimg.cn/blog_migrate/467e23940a1791040f1302b0a7ab6d52.jpeg)
定义了共享宿主机的 Network、IPC 和 PID Namespace。这样,此 Pod 里的所有容器,会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。
容器属性:
Pod 里最重要的字段"Containers":
"Containers"和"Init Containers"这两个字段都属于 Pod 对容器的定义,内容也完全相同,只是 Init Containers 的生命周期,会先于所有的 Containers,并且严格按照定义的顺序执行.
k8s 对 Container 的定义,和 Docker 相比并没有什么太大区别。
Docker中Image(镜像)、Command(启动命令)、workingDir(容器的工作目录)、Ports(容器要开发的端口),以及 volumeMounts(容器要挂载的 Volume)都是构成 k8s 中 Container 的主要字段。
其他的容器属性:
ImagePullPolicy 字段:定义镜像的拉取策略。之所以是一个 Container 级别的属性,是因为容器镜像本来就是 Container 定义中的一部分。
默认值: Always:表示每次创建 Pod 都重新拉取一次镜像。
1.镜像存在而且已经是最新版本就不在拉取镜像
2.如果不存在下载镜像
3.如果镜像存在但是版本不是新版本也会下载镜像
避免:不用latest,下载镜像的时候直接指定版本
#但是有bug,当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时,ImagePullPolicy 也会被认为 Always。
值:
Never:表示Pod永远不会主动拉取这个镜像
IfNotPresent:表示只在宿主机上不存在这个镜像时才拉取。
Lifecycle 字段:定义 Container Lifecycle Hooks。作用是在容器状态发生变化时触发一系列"钩子"。
注:
lifecycle /laɪf ˈsaɪkl/ n 生命周期
例子:这是 k8s 官方文档的一个 Pod YAML 文件
在这个例子中,容器成功启动之后,在 /usr/share/message 里写入了一句"欢迎信息"(即 postStart 定义的操作)。而在这个容器被删除之前,我们则先调用了 nginx 的退出指令(即 preStop 定义的操作),从而实现了容器的"优雅退出"。
[root@kub-k8s-master prome]# kubectl delete -f pod.yml
pod "website" deleted
[root@kub-k8s-master prome]# cp pod.yml pod.yml.bak
[root@kub-k8s-master prome]# vim pod.yml
---
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: daocloud.io/library/nginx
lifecycle:
postStart: #容器启动之后
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop: #容器关闭之前
exec:
command: ["/usr/sbin/nginx","-s","quit"]
![6a189339c1428a3e8ea78fdb961260b2.png](https://i-blog.csdnimg.cn/blog_migrate/41bc7847744033e96ddd6714e9334fa6.png)
验证:
[root@kub-k8s-node1 ~]# docker exec -it 3d404e658 /bin/bash
root@lifecycle-demo:~# cat /usr/share/message
Hello from the postStart handler
1. 定义了一个 nginx 镜像的容器
2. 设置了一个 postStart 和 preStop 参数
postStart:是在容器启动后,立刻执行一个指定的操作。
注意:postStart 定义的操作,虽然是在 Docker 容器 ENTRYPOINT 执行之后,但它并不严格保证顺序。也就是说,在 postStart 启动时,ENTRYPOINT 有可能还没有结束。
如果 postStart执行超时或者错误,k8s 会在该 Pod 的 Events 中报出该容器启动失败的错误信息,导致 Pod 也处于失败的状态。
preStop:是容器被杀死之前(比如,收到了 SIGKILL 信号)。
注意:preStop 操作的执行,是同步的。
所以,它会阻塞当前的容器杀死流程,直到这个 Hook 定义操作完成之后,才允许容器被杀死,这跟 postStart 不一样。
=======================================================================================
一个Pod 对象在 Kubernetes 中的生命周期:
Pod 生命周期的变化,主要体现在 Pod API 对象的Status 部分,这是除了 Metadata 和 Spec 之外的第三个重要字段。其中,pod.status.phase,就是 Pod 的当前状态,有如下几种可能的情况:
Pending:此状态表示Pod 的 YAML 文件已经提交给了 Kubernetes,API 对象已经被创建并保存在 Etcd 当中(准备状态)。但这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如,调度不成功。
Running:此状态表示Pod 已经调度成功,跟一个具体的节点绑定。它包含的容器都已经创建成功,并且至少有一个正在运行中。
Succeeded:此状态表示 Pod 里的所有容器都正常运行完毕,并且已经退出了。这种情况在运行一次性任务时最为常见。
Failed:此状态表示 Pod 里至少有一个容器以不正常的状态(非 0 的返回码)退出。这个状态的出现,意味着你得想办法 Debug 这个容器的应用,比如查看 Pod 的 Events 和日志。
Unknown:这是一个异常状态(未知状态),表示 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver
这很有可能是主从节点(Master 和 Kubelet)间的通信出现了问题
扩展:
Pod 对象的 Status 字段,还可以再细分出一组 Conditions:
这些细分状态的值包括:PodScheduled、Ready、Initialized,以及 Unschedulable
它们主要用于描述造成当前 Status 的具体原因是什么。
比如, Pod 当前的 Status 是 Pending,对应的 Condition 是 Unschedulable,这表示它的调度出现了问题。
比如, Ready 这个细分状态表示 Pod 不仅已经正常启动(Running 状态),而且已经可以对外提供服务了。这两者之间(Running 和 Ready)是有区别的,仔细思考一下。
Pod 的这些状态信息,是判断应用运行情况的重要标准,尤其是 Pod 进入了非"Running"状态后,一定要能迅速做出反应,根据它所代表的异常情况开始跟踪和定位,而不是去手忙脚乱地查阅文档。
有基础的可以仔细阅读 $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/api/core/v1/types.go 里,type Pod struct ,尤其是 PodSpec 部分的内容。