校园网站建设建议,html代码颜色,浦东注册公司流程和费用,小企业网站价格一、Pod介绍 1.1.概念 Pod是kubernetes中最小的资源管理组件#xff0c;Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的#xff0c;例如#xff0c;用于管理Pod运行的State…一、Pod介绍 1.1.概念 Pod是kubernetes中最小的资源管理组件Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的例如用于管理Pod运行的StatefulSet和Deployment等控制器对象用于暴露Pod应用的Service和Ingress对象为Pod提供存储的PersistentVolume存储资源对象等。 1.2.图形化描述 1.2.1.Pod 1.2.2.Node  1.2.3.service 1.3.K8S集群中Pod的使用方式 1一个Pod中运行一个容器 每个Pod中一个容器”的模式是最常见的用法在这种使用方式中你可以把Pod想象成是单个容器的封装kuberentes管理的是Pod而不是直接管理容器。 2在一个Pod中同时运行多个容器。 一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位比如一个容器共享文件另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。 1.4.Pod进程描述 一个Pod下的容器必须运行于同一节点上。现代容器技术建议一个容器只运行一个进程该进程在容器中PID命令空间中的进程号为1可直接接收并处理信号进程终止时容器生命周期也就结束了。若想在容器内运行多个进程需要有一个类似Linux操作系统init进程的管控类进程以树状结构完成多进程的生命周期管理。运行于各自容器内的进程无法直接完成网络通信这是由于容器间的隔离机制导致k8s中的Pod资源抽象正是解决此类问题Pod对象是一组容器的集合这些容器共享Network、UTS及IPC命令空间因此具有相同的域名、主机名和网络接口并可通过IPC直接通信。 Pod资源中针对各容器提供网络命令空间等共享机制的是底层基础容器pause基础容器也可称为父容器pause就是为了管理Pod容器间的共享操作这个父容器需要能够准确地知道如何去创建共享运行环境的容器还能管理这些容器的生命周期。为了实现这个父容器的构想kubernetes中用pause容器来作为一个Pod中所有容器的父容器。这个pause容器有两个核心的功能一是它提供整个Pod的Linux命名空间的基础。二来启用PID命名空间它在每个Pod中都作为PID为1进程init进程并回收僵尸进程。 1.5.pause容器 1.5.1.pause容器共享两种资源网络和存储 1网络         每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时必须分配共享网络资源例如使用宿主机的端口映射。 2存储         Pod可以指定多个共享的VolumePod中的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源以防容器重启后文件丢失。 总结每个Pod都有一个特殊的被称为基础容器的Pause容器Pause容器对应的镜像属于Kubernetes平台的一部分除Pause容器每个Pod还包含一个或多个紧密相关的用户应用容器。 1.5.2.pause容器功能 1在pod中担任Linux命名空间如网络命令空间共享的基础 2启用PID命名空间开启init进程。 1.6.pod设计特殊组成结构目的 ① 原因一在一组容器作为一个单元的情况下难以对整体的容器简单地进行判断及有效地进行行动。比如一个容器死亡了此时是算整体挂了么那么引入与业务无关的Pause容器作为Pod的基础容器以它的状态代表着整个容器组的状态这样就可以解决该问题。 ② 原因二Pod里的多个应用容器共享Pause容器的IP共享Pause容器挂载的Volume这样简化了应用容器之间的通信问题也解决了容器之间的文件共享问题。 1.7.Pod 的分类 1自主式Pod这种Pod本身是不能自我修复的当Pod被创建后不论是由你直接创建还是被其他Controller都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐。Pod不会自愈如果Pod运行的Node故障或者是调度器本身故障这个Pod就会被删除。同样的如果Pod所在Node缺少资源或者Pod处于维护状态Pod也会被驱逐。    2控制器管理的PodKubernetes使用更高级的称为Controller的抽象层来管理Pod实例。Controller可以创建和管理多个Pod提供副本管理、滚动升级和集群级别的自愈能力。例如如果一个Node故障Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod但是在Kubernetes中通常是使用Controller来管理Pod的。 二、Pod的yaml文件相关配置 在kubernetes中基本所有资源的一级属性都是一样的主要包含5部分 apiVersion string 版本由kubernetes内部定义版本号必须可以用 kubectl api-versions 查询到kind string 类型由kubernetes内部定义必须可以用 kubectl api-resources 查询到metadata Object 元数据主要是资源标识和说明常用的有name、namespace、labels等spec Object 描述这是配置中最重要的一部分里面是对各种资源配置的详细描述status Object 状态信息里面的内容不需要定义由kubernetes自动生成 在上面的属性中spec是接下来研究的重点继续看下它的常见子属性: containers []Object 容器列表用于定义容器的详细信息nodeName String 根据nodeName的值将pod调度到指定的Node节点上nodeSelector map[] 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node 上hostNetwork boolean 是否使用主机网络模式默认为false如果设置为true表示使用宿主机网络volumes []Object 存储卷用于定义Pod上面挂在的存储信息restartPolicy string 重启策略表示Pod在遇到故障的时候的处理策略   2.1.Pod的基本yaml配置 apiVersion: v1 kind: Pod metadata:name: pod-basenamespace: devlabels:user: heima spec:containers:- name: nginximage: nginx:1.17.1- name: busyboximage: busybox:1.302.2.镜像拉取pod-imagepullpolicy.yaml imagePullPolicy用于设置镜像拉取策略kubernetes支持配置三种拉取策略 Always总是从远程仓库拉取镜像一直远程下载IfNotPresent本地有则使用本地镜像本地没有则从远程仓库拉取镜像Never只使用本地镜像从不去远程仓库拉取本地没有就报错 一直使用本地 apiVersion: v1 kind: Pod metadata:name: pod-imagepullpolicynamespace: dev spec:containers:- name: nginximage: nginx:1.17.1imagePullPolicy: Always # 用于设置镜像拉取策略- name: busyboximage: busybox:1.302.3.启动命令command command用于在pod中的容器初始化完毕之后运行一个命令 apiVersion: v1 kind: Pod metadata:name: pod-commandnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1- name: busyboximage: busybox:1.30command: [/bin/sh,-c,touch /tmp/hello.txt;while true;do /bin/echo $(date %T) /tmp/hello.txt; sleep 3; done;]2.4.env 环境变量用于在pod中的容器设置环境变量 apiVersion: v1 kind: Pod metadata:name: pod-envnamespace: dev spec:containers:- name: busyboximage: busybox:1.30command: [/bin/sh,-c,while true;do /bin/echo $(date %T);sleep 60; done;]env: # 设置环境变量列表- name: usernamevalue: admin- name: passwordvalue: 1234562.5.端口设置 apiVersion: v1 kind: Pod metadata:name: pod-portsnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1ports: # 设置容器暴露的端口列表- name: nginx-portcontainerPort: 80protocol: TCP2.6.资源配额 容器中的程序要运行肯定是要占用一定资源的比如cpu和内存等如果不对某个容器的资源做限制那么它就可能吃掉大量资源导致其它容器无法运行。针对这种情况kubernetes提供了对内存和cpu的资源进行配额的机制这种机制主要通过resources选项实现他有两个子选项 1limits用于限制运行时容器的最大占用资源当容器占用资源超过limits会被终止并重启 2requests 用于设置容器需要的最小资源如果环境资源不够容器将无法启动 apiVersion: v1 kind: Pod metadata:name: pod-resourcesnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1resources: # 资源配额limits: # 限制资源上限cpu: 2 # CPU限制单位是core数memory: 10Gi # 内存限制requests: # 请求资源下限cpu: 1 # CPU限制单位是core数memory: 10Mi # 内存限制三、深入Pod 了解探针 2.1.Pod中的三种探针简要介绍 在容器的containers中存在三个属性: startupProbe启动探针, livenessProbe存活探针, readinessProbe就绪探针 1startupProbe启动探针: 用来探测当前容器是否启动成功 2livenessProbe存活探针: 用来判断当前容器是否存活,例如当探测到容器不存活时,会重新拉起 3readinessProbe就绪探针: 用来探测当前容器是否就绪,能否能够对外提供服务,以调用服务负载均衡为例,当接收到请求后如果通过该探针探测到某个服务节点不可用,则不会将该节点加入负载均衡。 2.2.Pod 中探针详细介绍 2.2.1. livenessProbe存活探针 1livenessProbe存活探针用于判断容器是不是健康如果不满足健康条件Kubelet 将根据 Pod 中设置的 restartPolicy 重启策略来判断Pod 是否要进行重启。 2LivenessProbe按照配置去探测 ( 进程、或者端口、或者命令执行后是否成功等等)来判断容器是不是正常。如果探测不到代表容器不健康可以配置连续多少次失败才记为不健康则 kubelet 会杀掉该容器并根据容器的重启策略做相应的处理。 3如果未配置存活探针则默认容器启动为Success通过状态。即Success后pod状态是RUNING 2. 2.2.readinessProbe就绪探针 1readinessProbe就绪探针用于判断容器内的程序是否存活或者说是否健康是否启动完成并就绪,正常对外提供服务。 2容器启动后会按照readinessProbe的配置进行探测, 探测成功返回 Success。pod的READY状态变为 true更新pod成功数量比如1/1否则还是0/1。 3若未配置就绪探针则默认容器启动后状态Success。此时pod、pod关联的Service、EndPoint 等资源都会进入Ready 状态,进行相关设置 后续程序运行中还可以通过readinessProbe继续监测, 如果探测失败,更新Pod 的 Ready 状态变为 false系统则会在对应的Service关联的 EndPoint 列表中去除此pod地址实现服务的异常踢除。如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。kube-proxy也将有概率通过负载机制会引入流量到此pod中 2.2.3. startupProbe启动探针 1启动探针时 k8s 在1.16版本后增加startupProbe探针主要解决在复杂的程序中readinessProbe、livenessProbe探针无法更好的判断程序是否启动、是否存活。进而引入startupProbe探针为readinessProbe、livenessProbe探针服务, 2startupProbe探针与另两种区别: 如果三个探针同时存在先执行startupProbe探针其他两个探针将会被暂时禁用直到pod满足startupProbe探针配置的条件其他2个探针启动如果不满足按照规则重启容器, 另外两种探针在容器启动后会按照配置直到容器消亡才停止探测而startupProbe探针只是在容器启动后按照配置满足一次后不在进行后续的探测 2.2.Pod探针相关配置 1initialDelaySeconds容器启动后要等待多少秒后存活和就绪探测器才被初始化默认是 0 秒最小值是 0。 2periodSeconds执行探测的时间间隔单位是秒。默认是 10 秒。最小值是 1。 3timeoutSeconds探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。 4successThreshold探测器在失败后被视为成功的最小连续成功数。默认值是 1。存活探测的这个值必须是 1。最小值是 1。 5failureThreshold当 Pod 启动了并且探测到失败Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。优先级低于pod默认重启策略更改后也不会按照该参数执行。   2.3.Pod探针检测的三种方式 1exec: 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。 livenessProbe:exec:command: [cat /tmp/health]initialDelaySeconds: 5periodSeconds: 5 2httpGet: 对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400则诊断被认为是成功的。path字段必须有。 livenessProbe:httpGet:path: /doc.htmlport: 40017failureThreshold: 1periodSeconds: 10 3tcpSocket: 对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开则诊断被认为是成功的。 livenessProbe:tcpSocket:port: 80initialDelaySeconds: 15periodSeconds: 20