公司网站建设招标文件范本,施工企业营业额和营业收入区别,如何查看网站权重,网站建设与维护作业目录 一、资源限制
二、Pod 的两种使用方式
三、Pod 资源共享
四、底层容器Pause
1、Pause共享资源
1.1 网络
1.2 存储
1.3 小结
2、Pause主要功能
3、Pod 与 Pause 结构的设计初衷
五、Pod容器的分类
1、基础容器#xff08;infrastructure container#xff09;…目录 一、资源限制
二、Pod 的两种使用方式
三、Pod 资源共享
四、底层容器Pause
1、Pause共享资源
1.1 网络
1.2 存储
1.3 小结
2、Pause主要功能
3、Pod 与 Pause 结构的设计初衷
五、Pod容器的分类
1、基础容器infrastructure container
2、初始化容器init container
3、应用容器main container
六、操作示例
1、编写myapp.yaml
2、创建myapp.yaml配置资源
3、查看pod创建过程
4、查看pod日志
5、编写myservice.yaml
6、创建 myservice.yaml 配置资源
7、编写mydb.yaml
8、创建mydb.yaml配置资源
9、查看 myapp-pod 创建全过程
10、小结
七、镜像拉取策略Image PullPolicy
1、官方示例
2、不指定版本查看默认拉取策略
2.1 不指定版本号创建pod
2.2 查看默认拉取策略
2.3 查看创建过程
3、测试案例非循环命令
3.1 创建测试案例mypod.yaml
3.2 生成mypod配置资源
3.3 查看创建过程
3.4 修改mypod.yaml
3.5 删除原有资源
3.6 更新资源
3.7 在node1节点使用curl查看头部信息
4、测试案例循环命令
4.1 修改mypod.yaml
4.2 生成新的 mypod.yaml 配置资源
4.3 查看pod状态
4.4 查看创建过程
4.5 查看pod日志
4.6 检查mypod.yaml文件
4.7 再次生成新的mypod.yaml配置资源
4.8 查看创建过程
4.9 查看pod日志
5、总结镜像拉取 一、资源限制
Pod 是 kubernetes 中最小的资源管理组件Pod 也是最小化运行容器化应用的资源对象。一个 Pod 代表着集群中运行的一个进程。kubernetes 中其他大多数组件都是围绕着 Pod 来进行支撑和扩展 Pod 功能的例如用于管理 Pod 运行的 StatefulSet 和 Deployment 等控制器对象用于暴露 Pod 应用的 Service 和 Ingress 对象为 Pod 提供存储的 PersistentVolume 存储资源对象等。 二、Pod 的两种使用方式
一个 Pod 中运行一个容器。每个 Pod 中一个容器的模式是最常见的用法在这种使用方式中你可以把 Pod想象成是单个容器的封装kubernetes 管理的是 Pod 而不是直接管理容器。在一个 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 进程并回收僵尸进程。 1、Pause共享资源 1.1 网络
每个 Pod 都会被分配一个唯一的 IP 地址。Pod 中的所有容器共享网络空间包括 IP 地址和端口。Pod 内部的容器可以使用 localhost 互相通信。Pod 中的容器与外界通信时必须分配共享网络资源例如使用宿主机的端口映射。 1.2 存储
可以 Pod 指定多个共享的 Volume。Pod 中的所有容器都可以访问共享的 Volume。Volume 也可以用来持久化 Pod 中的存储资源以防容器重启后文件丢失。 1.3 小结
每个 Pod 都有一个特殊的被称为 “基础容器” 的 Pause 容器。Pause 容器对应的镜像属于 Kubernetes 平台的一部分除了 Pause 容器每个 Pod 还包含一个或者多个紧密相关的用户应用容器。 2、Pause主要功能
kubernetes 中的 pause 容器主要为每个容器提供以下功能
在 pod 中担任 Linux 命名空间如网络命令空间共享的基础启用 PID 命名空间开启 init 进程3、Pod 与 Pause 结构的设计初衷
原因一在一组容器作为一个单元的情况下难以对整体的容器简单地进行判断及有效地进行行动。比如一个容器死亡了此时是算整体挂了么那么引入与业务无关的Pause 容器作为 Pod 的基础容器以它的状态代表着整个容器组的状态这样就可以解决该问题。原因二Pod 里的多个应用容器共享 Pause 容器的 IP共享 Pause 容器挂载的Volume这样简化了应用容器之间的通信问题也解决了容器之间的文件共享问题。五、Pod容器的分类 1、基础容器infrastructure container
维护整个 Pod 网络和存储空间 node 节点中操作 启动一个容器时k8s会自动启动一个基础容器 2、初始化容器init container
init运行四步启动运行完成退出
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 内的所有的应用容器会并行启动。3、应用容器main container
应用容器会在 init 容器完成并退出后并行启动。 六、操作示例 1、编写myapp.yaml [rootmaster ~]# 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 中的应用容器。 2、创建myapp.yaml配置资源 kubectl apply -f myapp.yaml
kubectl get pod 3、查看pod创建过程 kubectl describe pod myapp-pod 发现开启 init-myservice 容器后创建步骤停滞查看 init-myservice 日志进一步查明原因。 4、查看pod日志 kubectl logs myapp-pod -c init-myservice 5、编写myservice.yaml [rootmaster ~]# vim myservice.yamlapiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 1111 6、创建 myservice.yaml 配置资源 kubectl create -f myservice.yaml 7、编写mydb.yaml [rootmaster ~]# vim mydb.yamlapiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 2222 8、创建mydb.yaml配置资源 kubectl create -f mydb.yaml
kubectl get pod,svc 9、查看 myapp-pod 创建全过程 kubectl describe pod myapp-pod 创建过程中第一次停滞是 init-myservice 容器启动后未能发现 myservice 域名无法得到解析因此陷入循环。第二次停滞是 init-mydb 容器启动后未能发现 mydb 域名无法得到解析因此再次陷入循环中。在上述两个 init 容器成功并退出后myapp-pod 才开始创建否则 pod 无法创建。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的镜像拉取策略可以由用户指定
IfNotPresent:在镜像已经存在的情况下kubelet将不再去拉取镜像仅当本地缺失时才会从仓库中拉取默认的镜像拉取策略。Alaways:每次创建Pod都会重新拉取一次镜像Never:Pod不会主动拉取这个镜像仅使用本地镜像。
注意对于标签为latest的镜像文件其默认的镜像获取策略即为Always而对于其他标签的镜像其默认策略则为IfNotPresent。 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 都将能读取私有仓库中的镜像。2、不指定版本查看默认拉取策略 2.1 不指定版本号创建pod kubectl run nginx-test1 --imagenginx 2.2 查看默认拉取策略 kubectl edit pod nginx-test1 2.3 查看创建过程 kubectl describe pod nginx-test1 由于拉取策略为Always,因此不管本地有没有对应镜像kubectl都会前往共有仓库下载最新版本应用。 3、测试案例非循环命令 3.1 创建测试案例mypod.yaml [rootmaster ~]# vim mypod.yaml apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: nginximage: nginximagePullPolicy: Alwayscommand: [ echo,SUCCESS ] 3.2 生成mypod配置资源 kubectl create -f mypod.yaml
kubectl get pods 该pod状态为CrashLoopBackOff说明pod进入异常循环状态。原因是echo执行完进程终止容器声明周期也就结束了。 3.3 查看创建过程 kubectl describe pod mypod 可以发现 Pod 中的容器在生命周期结束后由于 Pod 的重启策略为 Always容器再次重启了并且又重新开始拉取镜像。 3.4 修改mypod.yaml
失败的状态的原因是因为命令启动冲突 删除 command: [ “echo”, “SUCCESS” ]同时更改一下版本 image: nginx:1.14 vim mypod.yaml 3.5 删除原有资源 kubectl delete -f mypod.yaml 3.6 更新资源 kubectl apply -f mypod.yaml#查看分配节点
kubectl get pods -o wide 3.7 在node1节点使用curl查看头部信息 curl -I 10.244.1.18 4、测试案例循环命令 4.1 修改mypod.yaml [rootmaster ~]# vim mypod.yaml apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentcommand: [ sh,while true;do echo SUCCESS;done ] 4.2 生成新的 mypod.yaml 配置资源 #删除原有资源
kubectl delete -f mypod.yaml#生成新的资源
kubectl apply -f mypod.yaml 4.3 查看pod状态 kubectl get pod -o wide 4.4 查看创建过程 kubectl describe pod mypod 4.5 查看pod日志 kubectl logs mypod 发现是命令错误 4.6 检查mypod.yaml文件 vim mypod.yaml 4.7 再次生成新的mypod.yaml配置资源 #删除原有的资源
kubectl delete -f mypod.yaml#生成新的资源
kubectl apply -f mypod.yaml#查看pod状态
kubectl get pod -o wide 4.8 查看创建过程 kubectl describe pod mypod 由于镜像拉取策略设定的是 IfNotPresent因此 kubelet 会先检查本地镜像仓库如果有对应版本镜像就直接使用没有的话才会前往镜像仓库拉取。 4.9 查看pod日志 kubectl logs mypod 回到顶部
5、总结镜像拉取
pod容器镜像拉取策略 (imagePullPolicy) 三种容器
ifNotPresent: 优先使用本地已存在的镜像如本地没有则从仓库拉取镜像默认的拉取策略Always: 总算是从仓库拉取镜像无论本地是否已存在的镜像标签为“latest”时默认的拉取策略Never:总是补充仓库拉取镜像仅使用本地镜像
镜像重启策略
always:当容器终止退出后总是重启容器默认策略ONEailure: 当容器异常退出时 (退出状态码非0) 时重启容器:正常退出则不重启容器Never:当容器终止退出从不重启容器注意: k8s中不支持重启Pod资源只有删除重建
