网站建设与管理 管理课程,办公管理系统有哪些,seo是什么意思以及怎么做,做义工的网站一、资源限制
Pod是k8s中的最小的资源管理组件#xff0c;pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。k8s中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的#xff0c;例如#xff0c;用于管理Pod运行的StatefulSet和Deployment等…一、资源限制
Pod是k8s中的最小的资源管理组件pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。k8s中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的例如用于管理Pod运行的StatefulSet和Deployment等控制器对象用于暴露Pod应用的Service和Ingress对象为Pod提供存储的PersistentVolume存储资源对象等。
二、Pod的两种使用方式
2.1、一个pod中运行一个容器
每个Pod中一个容器”的模式是最常见的用法在这种使用方式中你可以把Pod想象成是单个容器的封装kuberentes管理的是Pod而不是直接管理容器。
2.2、一个Pod中同时运行多个容器
一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位比如一个容器共享文件另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。
三、Pod资源共享
一个Pod下的容器必须运行于同一节点上。现代容器技术建议一个容器只运行一个进程该进程在容器中PID命令空间中的进程号为1可直接接收并处理信号进程终止时容器生命周期也就结束了。若想在容器内运行多个进程需要有一个类似Linux操作系统init进程的管控类进程以树状结构完成多进程的生命周期管理。运行于各自容器内的进程无法直接完成网络通信这是由于容器间的隔离机制导致k8s中的Pod资源抽象正是解决此类问题Pod对象是一组容器的集合这些容器共享Network、UTS及IPC命令空间因此具有相同的域名、主机名和网络接口并可通过IPC直接通信。
namespace功能说明mnt提供磁盘挂载点和文件系统的隔离能力ipc提供进程间通信的隔离能力net提供网络隔离能力uts提供主机名隔离能力pid提供进程隔离能力user提供用户隔离能力
四、底层容器pause
Pod资源中针对各容器提供网络命令空间等共享机制的是底层基础容器pause基础容器也可称为父容器pause就是为了管理Pod容器间的共享操作这个父容器需要能够准确地知道如何去创建共享运行环境的容器还能管理这些容器的生命周期。为了实现这个父容器的构想kubernetes中用pause容器来作为一个Pod中所有容器的父容器。这个pause容器有两个核心的功能一是它提供整个Pod的Linux命名空间的基础。二来启用PID命名空间它在每个Pod中都作为PID为1进程init进程并回收僵尸进程。
4.1、容器共享资源网络和存储
网络
每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时必须分配共享网络资源例如使用宿主机的端口映射。
存储
Pod可以指定多个共享的Volume。Pod中的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源以防容器重启后文件丢失。
总结
每个pod都有一个特殊的被称为基础容器的pause容器pause容器对应的镜像属于k8s平台的一部分除了pause容器每个pod还包含一个或者多个紧密相关的用户应用容器。
4.2、pause的主要功能
kubernetes中的pause容器主要为每个容器提供以下功能
①在pod中担任linux的命名空间如网络命名空间共享的基础
②启动pid命名空间开启init进程。
协调他的容器生命周期
提供健康检查和生存探针
4.3、Pod与Pause结构的设计初衷
原因一在一组容器作为一个单元的情况下难以对整体的容器简单地进行判断及有效地进行行动。比如一个容器死亡了 那么引入与业务无关的Pause容器作为Pod的基础容器以它的状态代表着整个容器组的状态这样就可以解决该问题。
原因二Pod里的多个应用容器共享Pause容器的IP共享Pause容器挂载的Volume这样简化了应用容器之间的通信问题也解决了容器之间的文件共享问题。
五、pod的分类
5.1、自主式Pod
这种Pod本身是不能自我修复的当Pod被创建后不论是由你直接创建还是被其他Controller都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。Pod不会自愈。如果Pod运行的Node故障或者是调度器本身故障这个Pod就会被删除。同样的如果Pod所在Node缺少资源或者Pod处于维护状态Pod也会被驱逐。
5.2、控制器管理的Pod
Kubernetes使用更高级的称为Controller的抽象层来管理Pod实例。Controller可以创建和管理多个Pod提供副本管理、滚动升级和集群级别的自愈能力。例如如果一个Node故障Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod但是在Kubernetes中通常是使用Controller来管理Pod的。
六、Pod容器的分类
6.1、基础容器infrastructure container
①维护整个 Pod 网络和存储空间 ②node 节点中操作 ③启动一个Pod时k8s会自动启动一个基础容器
6.2、初始化容器
Init容器必须在应用程序容器启动之前运行完成而应用程序容器是并行运行的所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法。Init 容器与普通的容器非常像除了以下两点
①init容器总是运行到成功完成为止
②每个init容器都必须在下一个init容器启动之前成功完成启动和退出。
如果 Pod 的 Init 容器失败k8s 会不断地重启该 Pod直到 Init 容器成功为止。然而如果 Pod 对应的重启策略restartPolicy为 Never它不会重新启动。
Init 的容器作用
因为init容器具有与应用容器分离的单独镜像其启动相关代码具有如下优势
①Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像。
②Init 容器可以安全地运行这些工具避免这些工具导致应用镜像的安全性降低。
③应用镜像的创建者和部署者可以各自独立工作而没有必要联合构建一个单独的应用镜像。
④Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此Init容器可具有访问 Secrets 的权限而应用容器不能够访问。
⑤由于 Init 容器必须在应用容器启动之前运行完成因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动 直到满足了一组先决条件。一旦前置条件满足Pod内的所有的应用容器会并行启动。
6.3、应用容器
应用容器会在init容器完成并退出后并行启动。
七、操作实例
7.1、编写myapp.yaml
cat myapp.yaml apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app: myapp
spec:containers:- name: myapp-containerimage: busybox:1.28command: [sh,-c,echo The app is running! sleep 3600]initContainers:- name: init-myserviceimage: busybox:1.28command: [sh,-c,until nslookup myservice;do echo waiting for myservice; sleep2; done;]- name: init-mydbimage: busybox:1.28command: [sh,-c,until nslookup mydb; do echo waiting for mydb; sleep 2; done;] 这个例子是定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动 第二个等待 mydb 启动。 一旦这两个 Init容器都启动完成Pod 将启动 spec 中的应用容器。
7.2、创建myapp.yaml配置资源 kubectl apply -f myapp.yaml kubectl get pod 该pod会一直处于init0/2的状态
7.3、查看pod创建过程 kubectl describe pod myapp-pod 发现开启init-myservice容器后创建步骤停滞查看init-myservice日志进一步查明原因。
7.4、查看pod日志 kubectl logs myapp-pod -c init-myservice 发现问题服务器服务器未能找到myservice域名所以无法跳出循环
7.5、编写myservice.yaml
vim myservice.yamlapiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376 7.6、创建myservice.yaml配置资源 kubectl create -f myservice.yaml kubectl logs myapp-pod -c init-mydb 7.7、编写mydb.yaml
vim mydb.yamlapiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 2222 7.8、创建mydb.yaml配置资源 kubectl create -f mydb.yaml 7.9、查看myapp-pod创建全过程 kubectl describe pod myapp-pod 原因总结 ①创建过程中的第一次停滞是init-myservoce容器启动后未能发现myservice域名无法得到解析因此陷入循环。
②第二次停滞是init-mydb容器启动后未能发现mydb域名无法得到解析因此再次陷入循环之中
③在上述两个容器成功并退出之后myapp-pod才开始创建否则pod无法创建。
7.10、总结
①在Pod启动过程中Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。
②如果由于运行时或失败退出将导致容器启动失败它会根据Pod的restartPolicy指定的策略进行重试。然而如果Pod的restartPolicy设置为AlwaysInit容器失败时会使用RestartPolicy策略。
③在所有的Init容器没有成功之前Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态但应该会将Initializing状态设置为true。
④如果Pod重启所有Init容器必须重新执行。
⑤对Init容器spec的修改被限制在容器image字段修改其他字段都不会生效。更改Init容器的image字段等价于重启该Pod。
⑥Init容器具有应用容器的所有字段。除了readinessProbe因为Init容器无法定义不同于完成completion的就绪readiness之外的其他状态。这会在验证过程中强制执行。
⑦在Pod中的每个app和Init容器的名称必须唯一与任何其它容器共享同一个名称会在验证时抛出错误。
八、镜像拉取策略Image Pullpolicy
Pod 的核心是运行容器必须指定容器引擎比如 Docker启动容器时需要拉取镜像k8s 的镜像拉取策略可以由用户指定
1、IfNotPresent在镜像已经存在的情况下kubelet 将不再去拉取镜像仅当本地缺失时才从仓库中拉取默认的镜像拉取策略。
2、Always每次创建 Pod 都会重新拉取一次镜像。
3、NeverPod 不会主动拉取这个镜像仅使用本地镜像。
注意对于标签为“:latest”的镜像文件其默认的镜像获取策略即为“Always”而对于其他标签的镜像其默认策略则为“IfNotPresent”。
8.1、官方示例
创建使用私有镜像的pod来验证
kubectl apply -f - EOF
apiVersion: v1
kind: Pod
metadata:name: private-image-test-1
spec:containers:- name: uses-private-imageimage: $PRIVATE_IMAGE_NAMEimagePullPolicy: Alwayscommand: [ echo, SUCCESS ]
EOF
输出类似于 pod/private-image-test-1 created 如果一切顺利那么一段时间后你可以执行 kubectl logs private-image-test-1 然后可以看到success如果你怀疑命令失败了可以运行 kubectl describe pods/private-image-test-1 | grep Failed 如果命令失败了输出类似于 Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image user/privaterepo:v1: Error: image user/privaterepo:v1 not found ①必须确保集群中所有节点的 .docker/config.json 文件内容相同。 否则 Pod会能在一些节点上正常运行而无法在另一些节点上启动。 例如如果使用节点自动扩缩那么每个实例模板都需要包含.docker/config.json或者挂载一个包含该文件的驱动器。
②在 .docker/config.json 中配置了私有仓库密钥后所有 Pod 都将能读取私有仓库中的镜像
8.2、不指定版本查看默认拉取策略
①不指定版本号创建pod kubectl run nginx-test1 --imagenginx ②查看默认拉取策略 kubectl edit pod nginx-cs ③查看创建过程 kubectl describe pod nginx-cs 由于拉取策略为Always因此不管本地有没有对应镜像kubectl都会前往共有仓库下载最新版本应用。
8.3、测试案例非循环命令
①创建测试案例mypod.yaml并启动查看
vim mypod.yaml apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: nginximage: nginximagePullPolicy: Alwayscommand: [ echo,SUCCESS ]
该pod状态为CrashLoopBackOff说明pod进入异常循环状态。原因是echo执行完进程终止容器声明周期也就结束了。
②查看创建过程 kubectl describe pod mypod 因为重启策略为Always因此成功之后依然重复拉取。
可以发现pod中的容器在生命周期结束之后由于pod的重启策略为Always容器再次重启了并且又重新开始拉取镜像。
③修改mypod.yaml
失败的状态的原因是因为命令启动冲突
删除 command[echo,SUCCESS]
同时更改一下版本
imagenginx1.14 vim mypod.yaml ④删除原有资源 kubectl delete -f mypod.yaml ⑤更新资源 kubectl apply -f mypod.yaml #查看分配节点 kubectl get pods -o wide ⑥在node1节点使用curl查看头部信息 8.4、测试案例循环命令
①修改mypod.yaml
vim mypod.yaml apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentcommand: [ sh,while true;do echo SUCCESS;done ]
②生成新的mypod.yaml配置资源 #删除原有资源 kubectl delete -f mypod.yaml #生成新的资源 kubectl apply -f mypod.yaml ③查看pod的状态 kubectl get pod -o wide 进入异常循环状态
④查看创建过程 kubectl describe pod mypod 错误发生在command步骤
⑤查看pod日志 kubectl logs mypod 发现命令是错误的
⑥检查mypod.yaml文件 vim mypod.yaml ⑦再次生成新的mypod.yaml配置资源 #删除原有的资源 kubectl delete -f mypod.yaml #生成新的资源 kubectl apply -f mypod.yaml ⑧查看创建过程
由于镜像拉取策略设定的是 IfNotPresent因此 kubelet 会先检查本地镜像仓库如果有对应版本镜像就直接使用没有的话才会前往镜像仓库拉取。
⑨查看pod日志 kubectl logs mypod
