Pod
Pod概述
Pod是k8s系统中国可以创建和管理的最小单元,是资源对象模型中又用户创建或部署的最小资源对象模型,也是在k8s上运行容器化应用的资源对象,其他的资源对象都是用来支撑或者扩展Pod对象功能的,比如控制器对象是用来管控Pod对象的,Service或者Ingress资源对象是用来暴露Pod引用对象的,PersistenVolume资源对象是用来为Pod提供存储等等,k8s不会直接处理容器,而是Pod,Pod是由一个或多个container组成。
Pod是Kubernetes的最重要概念,每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod还包含一个或多个紧密相关的用户业务容器。
- Pod vs应用
每个 Pod 都是应用的一个实例, 有专用的 IP
- Pod vs 容器
一个 Pod 可以有多个容器, 彼此间共享网络和存储资源, 每个 Pod 中有一个 Pause 容器保存所有的容器状态, 通过管理 pause 容器, 达到管理 pod 中所有容器的效果 。
- Pod vs 节点
同一个 Pod 中的容器总会被调度到相同 Node 节点, 不同节点间 Pod 的通信基于虚拟二层网络技术实现
- Pod vs Pod
普通的 Pod 和静态 Pod
Pod特性
1、资源共享
一个 Pod
里的多个容器可以共享存储和网络, 可以看作一个逻辑的主机。 共享的如namespace
,cgroups
或者其他的隔离资源。
多个容器共享同一 network namespace
, 由此在一个 Pod
里的多个容器共享 Pod
的IP
和端口 namespace
, 所以一个Pod
内的多个容器之间可以通过localhos
t 来进行通信,所需要注意的是不同容器要注意不要有端口冲突即可。 不同的 Pod
有不同的 IP,不同 Pod
内的多个容器之前通信, 不可以使用 IPC
(如果没有特殊指定的话)通信, 通常情况下使用 Pod
的 IP
进行通信。
一个 Pod
里的多个容器可以共享存储卷, 这个存储卷会被定义为 Pod
的一部分, 并且可以挂载到该 Pod
里的所有容器的文件系统上。
2、生命周期短暂
Pod 属于生命周期比较短暂的组件, 比如, 当 Pod 所在节点发生故障, 那么该节点上的 Pod会被调度到其他节点, 但需要注意的是, 被重新调度的 Pod 是一个全新的 Pod,跟之前的Pod 没有半毛钱关系。
3、平坦的网络
K8s 集群中的所有 Pod 都在同一个共享网络地址空间中, 也就是说每个 Pod 都可以通过其他 Pod 的 IP 地址来实现访问。
Pod 定义
1、下面是 yaml 文件定义的 Pod 的完整内容。
apiVersion: v1 kind: Pod metadata: //元数据 name: string namespace: string labels: -name: string annotations: -name: string spec:containers: //pod 中的容器列表, 可以有多个容器 - name: string //容器的名称 image: string //容器中的镜像 imagesPullPolicy: [Always|Never|IfNotPresent]//获取镜像的策略, 默认值为Always, 每次都尝试重新下载镜像 command: [string] //容器的启动命令列表(不配置的话使用镜像内部的命令) args:[string] //启动参数列表 workingDir: string //容器的工作目录 volumeMounts: //挂载到到容器内部的存储卷设置 -name: string mountPath: string //存储卷在容器内部 Mount 的绝对路径 readOnly: boolean //默认值为读写 ports: //容器需要暴露的端口号列表 -name: string containerPort: int //容器要暴露的端口 hostPort: int //容器所在主机监听的端口(容器暴露端口映射到宿主机的端口, 设置hostPort 时同一台宿主机将不能再启动该容器的第 2 份副本) protocol: string //TCP 和 UDP, 默认值为 TCP env: //容器运行前要设置的环境列表 -name: string value: string resources: limits: //资源限制, 容器的最大可用资源数量 cpu: Srting memory: string requeste: //资源限制, 容器启动的初始可用资源数量 cpu: string memory: string livenessProbe: //pod 内容器健康检查的设置 exec: command: [string] //exec 方式需要指定的命令或脚本 httpGet: //通过 httpget 检查健康 path: string port: number host: string scheme: Srtring httpHeaders: - name: Stirng value: string tcpSocket: //通过 tcpSocket 检查健康 port: number initialDelaySeconds: 0//首次检查时间 timeoutSeconds: 0 //检查超时时间 periodSeconds: 0 //检查间隔时间 successThreshold: 0 failureThreshold: 0 securityContext: //安全配置 privileged: falae restartPolicy: [Always|Never|OnFailure]//重启策略, 默认值为 Always nodeSelector: object //节点选择, 表示将该 Pod 调度到包含这些 label 的 Node 上, 以key:value 格式指定 imagePullSecrets: -name: string hostNetwork: false //是否使用主机网络模式, 弃用 Docker 网桥, 默认否 volumes: //在该 pod 上定义共享存储卷列表 -name: string emptyDir: {} hostPath: path: string secret: secretName: string item: -key: string path: string configMap: name: string items: -key: string path: string
Pod 的基本使用方法
在 kubernetes
中对运行容器的要求为: 容器的主程序需要一直在前台运行, 而不是后台运行。 应用需要改造成前 台运行的方式。 如果我们创建的 Docker
镜像的启动命令是后台执行程序, 则在 kubelet
创建包含这个容器的 pod
之 后运行完该命令, 即认为 Pod
已经结束,将立刻销毁该 Pod
。 如果为该 Pod
定义了 RC
, 则创建、 销毁会陷入一个无 限循环的过程中。Pod
可以由 1 个或多个容器组合而成。
1、一个容器组成的 Pod 的 yaml 示例
apiVersion: v1 kind: Pod metadata: name: mynginx labels: app: mynginx spec: containers: - name: mynginx image: reg.harbor.com/public/nginx:latest ports: - containerPort: 80
2、多个容器组成的 Pod 的 yaml 示例
apiVersion: v1 kind: Pod metadata: name: nginx-mysql labels: app: nginx-mysql spec: containers: - name: ningx image: reg.harbor.com/public/nginx:latest ports: - containerPort: 80 - name: mysql image: reg.harbor.com/public/mysql:5.7.17 ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD value: "123456"
3、创建
#进入yaml文件所在的目录下执行 kubectl create -f xxx.yaml 或者 kubectl apply -f xxx.yaml [root@master1 pod]# kubectl apply -f nginx_mysql.yaml pod/nginx-mysql created
4、查看
kubectl get pod/po <Pod_name> kubectl get pod/po <Pod_name> -o wide kubectl describe pod/po <Pod_name>
5、删除
kubectl delete -f pod pod_name.yaml kubectl delete pod [pod_name] kubectl delete pod --all #删除默认命名空间下的所有Pod资源
Pod的分类
1、普通Pod
普通 Pod
一旦被创建, 就会被放入到 etcd
中存储, 随后会被 Kubernetes Master
调度到某个具体的 Node
上并进行绑定, 随后该 Pod
对应的 Node
上的 kubelet
进程实例化成一组相关的 Docker
容器并启动起来。 在默认情 况下, 当 Pod
里某个容器停止时, Kubernetes
会自动检测到这个问题并且重新启动这个 Pod
里某所有容器, 如果 Pod
所在的 Node
宕机,则会将这个 Node
上的所有 Pod
重新调度到其它节点上。
2、静态Pod
静态 Pod
是由 kubelet
进行管理的仅存在于特定 Node
上的 Pod
,它们不能通过API Server
进行管理, 无法与 ReplicationController
、 Deployment
或 DaemonSet
进行关联, 并且kubelet
也无法对它们进行健康检查。
Pod生命周期和重启策略
1、Pod 的状态
状态值 |
说明 |
|
Pending |
API Server已经创建该Pod,但Pod中的一个或多个容器镜像还没创建,包括镜像下载过程 |
|
Running |
Pod内所有容器已创建,且至少一个容器处于运行状态、正在启动状态或正在重启状态 |
|
Completed |
Pod内所有容器均成功执行退出,且不会重启 |
|
Failed |
Pod内所有容器均已退出,但至少一个容器退出失败 |
|
Unknown |
由于某种原因无法获取Pod状态,例如网络通信不通 |
2、Pod重启策略
Pod
的重启策略包括 Always
、 OnFailure
和 Never
, 默认值是 Always
重启策略 |
说明 |
|
Always |
当容器失效时,由kubelet自动重启该容器 |
|
OnFailure |
当容器终止运行且退出码不为0时,由kubelet自动重启该容器 |
|
Never |
不论容器运行状态如何,kubelet都不会重启该容器 |
Pod资源配置
每个Pod
都可以对其能使用的服务器上的计算资源设置限额, Kubernetes
中可以设置限额的计算资源有CPU
与 Memory
两种, 其中CPU
的资源单位为CPU
数量,是一个绝对值而非相对值。 Memory
配额也是一个绝对值, 它的单位是内存字节数。
Kubernetes
里, 一个计算资源进行配额限定需要设定以下两个参数: Requests
该资源最小申请数量, 系统必须满足要求Limits
该资源最大允许使用的量, 不能突破, 当容器试图使用超过这个量的资源时, 可能会被 Kubernetes Kill
并重启。
apiVersion: v1 kind: Pod metadata: name: mynginx labels: app: mynginx spec: containers: - name: mynginx image: reg.harbor.com/public/nginx:latest ports: - containerPort: 80 resources: requests: memory: "64Mi" cpu: '250m' limits: memory: "128Mi" cpu: "500m"
上述代码表明Nginx
容器申请最少 0.25 个CPU
以及64MiB
内存, 在运行过程中容器所能使用的资源配额为 0.5 个CPU
以及128MiB
内存。