目录
一、什么是pod?
Pod是kubernetes中最小的资源管理组件,Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。
二、在kubernets集群中使用pod的两种方式
1、一个Pod中运行一个容器。这是最常见的用法
2、在一个Pod中同时运行多个容器。
三、pause容器
每个Pod都有一个特殊的被称为“基础容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod还包含一个或者多个紧密相关的用户应用容器。
pause容器使得Pod中的所有容器可以共享两种资源:网络和存储。
(1)网络:
每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间,包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时,必须分配共享网络资源。
(2)存储:
Pod可以指定多个共享的Volume。Pod中的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源,以防容器重启后文件丢失。
pause容器主要为每个容器提供在pod中担任Linux命名空间共享的基础以及启用PID命名空间,开启init进程的功能。
四、pod的种类
1、自主式pod:这中pod不能够被自我修复,当pod创建后,会被调度到node上,直到pod的进程终止、被删掉、缺少资源被驱逐、node故障之前这个Pod都会一直保持在那个node上。
2、控制管理器:Kubernetes使用更高级的称为Controller的抽象层,来管理Pod实例。Controller可以创建和管理多个Pod,提供副本管理、滚动升级和集群级别的自愈能力。
五、pod容器的分类
1、基础容器:维护整个 Pod 网络和存储空间,node 节点中操作,启动一个Pod时,k8s会自动启动一个基础容器
cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
2、初始化容器:init容器必须在应用程序容器启动之前运行完成,而应用程序容器是并行运行的,所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法。
Init 容器有不同于普通的容器的两点:(1)init 容器总是运行到成功完成为止,(2)每个 Init 容器都必须在下一个 Init 容器启动之前成功完成启动和退出,如果 Pod 的 Init 容器失败,k8s 会不断地重启该 Pod,直到 Init 容器成功为止。然而,如果 Pod 对应的重启策略为 Never,它不会重新启动。
init 的容器作用
因为init容器具有与应用容器分离的单独镜像,其启动相关代码具有如下优势:
(1)init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如,没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像。
(2)Init 容器可以安全地运行这些工具,避免这些工具导致应用镜像的安全性降低。
(3)应用镜像的创建者和部署者可以各自独立工作,而没有必要联合构建一个单独的应用镜像。
(4)init 容器能以不同于Pod内应用容器的文件系统视图运行。因此,init容器可具有访问 Secrets 的权限,而应用容器不能够访问。
(5)由于init 容器必须在应用容器启动之前运行完成,因此init 容器提供了一种机制来阻塞或延迟应用容器的启动,
直到满足了一组先决条件。一旦前置条件满足,Pod内的所有的应用容器会并行启动。
3、应用容器:并行启动
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
这个例子是定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动, 第二个等待 mydb 启动。 一旦这两个 Init容器都启动完成,Pod 将启动 spec 中的应用容器。
六、镜像拉取策略
1、IfNotPresent:在镜像已经存在的情况下,kubelet 将不再去拉取镜像,仅当本地缺失时才从仓库中拉取,默认的镜像拉取策略
2、Always:每次创建 Pod 都会重新拉取一次镜像;
3、Never:Pod 不会主动拉取这个镜像,仅使用本地镜像。
七、重启策略
重启策略:当 Pod 中的容器退出时通过节点上的 kubelet 重启容器。适用于 Pod 中的所有容器。
1、Always:当容器终止退出后,总是重启容器,默认策略
2、OnFailure:当容器异常退出(退出状态码非0)时,重启容器;正常退出则不重启容器
3、Never:当容器终止退出,从不重启容器。
注意:K8S 中不支持重启 Pod 资源,只有删除重建
八、资源限制
资源限制主要分为两类:cpu和内存
request:指定所需的资源量
limit:指定资源上限量
CPU 资源的 request 和 limit 以 cpu 为单位,一个 cpu 相当于1个 vCPU
内存的 request 和 limit 以字节为单位,可以以整数表示,或者以10为底数的指数的单位(E、P、T、G、M、K)来表示, 或者以2为底数的指数的单位(Ei、Pi、Ti、Gi、Mi、Ki)来表示。
1KB=10^3=1000,1MB=10^6=1000000=1000KB,1GB=10^9=1000000000=1000MB
1KiB=2^10=1024,1MiB=2^20=1048576=1024KiB
举例:
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
此例子中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 64MiB 内存,每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5 cpu 和 128 MiB 内存,总的资源 limit 为 1 cpu 和 256MiB 内存。