ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

云原生笔记10

云原生笔记10 一、Pod一kubernetes 中的资源1.资源管理介绍在 Kubernetes 中所有的内容都抽象为资源用户需要通过操作资源来管理 Kubernetes。 Kubernetes 本质上就是一个集群系统用户可以在集群中部署各种服务。所谓的部署服务其实就是在 Kubernetes 集群中运行一个个的容器并将指定的程序跑在容器中。Kubernetes 的最小管理单元是 Pod 而不是容器只能将容器放在 Pod 中。Kubernetes 一般也不会直接管理 Pod而是通过 Pod 控制器来管理 Pod 的常见的 Pod 控制器有 Deployment无状态应用、StatefulSet有状态应用、DaemonSet节点守护进程、Job一次性任务等它们负责 Pod 的编排、扩缩容和故障自愈。Pod 中服务的访问是由 Kubernetes 提供的 Service 资源来实现的Service 为一组 Pod 提供固定的访问入口和负载均衡解决了 Pod IP 不固定的问题。Pod 中程序的数据需要持久化则是由Kubernetes 提供的各种存储系统来实现的通过 PV 和 PVC 将底层存储资源与 Pod 解耦使数据可以独立于 Pod 生命周期而存在。2.资源管理方式命令式对象管理直接使用命令去操作 kubernetes 资源kubectl run nginx-pod --imagenginx:latest --80port80命令式对象配置通过命令配置和配置文件去操作 kubernetes 资源kubectl create/patch -f nginx-pod.yaml声明式对象配置通过apply命令和配置文件去操作 kubernetes 资源kubectl apply -f nginx-pod.yaml类型适用环境优点缺点命令式对象管理测试简单只能操作活动对象无法审计、跟踪命令式对象配置开发可以审计、跟踪项目大时配置文件多操作麻烦声明式对象配置开发支持目录操作意外情况下难以调试1命令式对象管理kubectl 是 kubernetes 集群的命令行工具通过它能够对集群本身进行管理并能够在集群上进行容器化应用的安装部署。语法kubectl [command] [type] [name] [flags]command指定要对资源执行的操作例如 create、get、deletetype指定资源类型比如 deployment、pod、servicename指定资源的名称名称大小写敏感flags指定额外的可选参数kubectl get pod查看所有 podkubectl get pod pod_name查看某个podkubectl get pod pod_name -o yaml查看某个pod,以yaml格式展示结果2资源类型kubernetes 中所有的内容都抽象为资源常用资源类型Pod最小管理单元、Deployment无状态应用部署、StatefulSet有状态应用、DaemonSet节点守护进程、Job一次性任务、CronJob定时任务、Service服务访问入口、Ingress七层路由、ConfigMap明文配置、Secret敏感信息、PV存储资源、PVC存储申请、Namespace资源隔离、Node工作节点。kubectl常见命令操作get查看资源、describe查看详情、logs查看日志、exec进入容器、apply创建/更新资源、delete删除资源、scale扩缩容、set image更新镜像、rollout status查看更新进度、rollout undo回滚、explain查看字段说明、api-resources列出所有资源类型。二Pod 简介Pod 是 Kubernetes 中可以创建和管理的最小计算单元也是集群中最小的可部署对象。一个 Pod 代表着集群中运行的一个进程每个 Pod 在集群中都会被分配一个唯一的 IP 地址。Pod 就像一个豌豆荚内部可以包含一个或多个容器通常是 Docker 容器这些容器之间共享 IPC进程间通信、Network网络命名空间包括 IP 和端口以及 UTC主机名和时区等命名空间使得它们可以像在同一个主机上一样通过 localhost 互相通信协同完成业务功能。1.创建自主式 pod优点灵活性高可以精确控制 Pod 的各种配置参数包括容器的镜像、资源限制、环境变量、命令和参数等满足特定的应用需求。学习和调试方便对于学习 Kubernetes 的原理和机制非常有帮助通过手动创建 Pod 可以深入了解 Pod 的结构和配置方式在调试问题时也能更直接地观察和调整 Pod 的设置。适用于特殊场景在一些特殊情况下如进行一次性任务、快速验证概念或在资源受限的环境中进行特定配置时手动创建 Pod 可能是一种有效的方式。缺点管理复杂如果需要管理大量的 Pod手动创建和维护会变得非常繁琐和耗时难以实现自动化的扩缩容、故障恢复等操作。缺乏高级功能无法自动享受 Kubernetes 提供的高级功能如自动部署、滚动更新、服务发现等可能导致应用的部署和管理效率低下。可维护性差手动创建的 Pod 在更新应用版本或修改配置时需要手动干预容易出现错误并且难以保证一致性相比之下通过声明式配置或使用控制器来管理 Pod 可以更方便地进行应用的维护和更新。2.利用控制器管理 pod使用 Pod 控制器如Deployment、StatefulSet等来管理 Pod相比直接管理 Pod具有以下显著优势高可用性和可靠性控制器具备自动故障恢复能力如果一个 Pod 失败或被删除控制器会自动创建新的 Pod 来维持期望的副本数量确保应用始终处于可用状态减少因单个 Pod 故障导致的服务中断。同时控制器支持配置健康检查如存活探针和就绪探针当 Pod 不健康时控制器会采取重启或重新创建等适当行动保证应用的正常运行。可扩展性控制器支持轻松扩缩容可以通过简单的命令或配置更改来增加或减少 Pod 的数量以满足不同的工作负载需求例如在高流量期间快速扩展以处理更多请求在低流量期间缩容以节省资源。此外结合水平自动扩缩容HPA还可以基于自定义指标如CPU利用率、内存使用情况或应用特定的指标自动调整 Pod 数量实现动态的资源分配和成本优化。版本管理和更新对于 Deployment 等控制器可以执行滚动更新来逐步替换旧版本的 Pod 为新版本确保应用在更新过程中始终保持可用同时可以控制更新的速率和策略以减少对用户的影响。如果更新出现问题还可以轻松回滚到上一个稳定版本保证应用的稳定性和可靠性。声明式配置控制器使用YAML或JSON格式的声明式配置文件来定义应用的部署需求这种方式使得配置易于理解、维护和版本控制也方便团队协作。只需要定义应用的期望状态如副本数量、容器镜像等控制器就会自动调整实际状态与期望状态保持一致无需手动管理每个Pod的创建和删除大大提高了管理效率。服务发现和负载均衡Kubernetes中的Service可以自动发现由控制器管理的Pod并将流量路由到它们使得应用的服务发现和负载均衡变得简单和可靠无需手动配置负载均衡器。同时Service可以根据不同的策略如轮询、随机等将请求分发到不同的Pod提高应用的性能和可用性。多环境一致性在不同的环境如开发、测试、生产中可以使用相同的控制器和配置来部署应用确保应用在不同环境中的行为一致有助于减少部署差异和错误提高开发和运维效率。3.利用 yaml 文件部署应用优点声明式配置清晰表达期望状态以声明式的方式描述应用的部署需求包括副本数量、容器配置、网络设置等使得配置易于理解和维护并且可以方便地查看应用的预期状态。配置文件可以被版本控制确保在不同环境中的部署一致性可以轻松回滚到以前的版本或在不同环境中重复使用相同的配置。同时便于团队成员之间共享和协作大家可以对配置文件进行审查和修改提高部署的可靠性和稳定性。灵活性和可扩展性提供丰富的配置选项可以通过 YAML 文件详细地配置各种 Kubernetes 资源如 Deployment、Service、ConfigMap、Secret 等根据应用的特定需求进行高度定制化。同时支持组合和扩展可以将多个资源的配置组合在一个或多个 YAML 文件中实现复杂的应用部署架构也可以轻松地添加新的资源或修改现有资源以满足不断变化的需求。与工具集成可以将 YAML 配置文件与 CI/CD 流程集成实现自动化的应用部署例如在代码提交后自动触发部署流程使用配置文件来部署应用到不同的环境。Kubernetes 的命令行工具kubectl 对 YAML 配置文件有很好的支持可以方便地应用、更新和删除配置同时还可以使用其他工具来验证和分析 YAML 配置文件确保其正确性和安全性。4.资源清单参数参数名称类型说明versionString这里是指的是K8S API的版本目前基本上是v1可以用 kubectl api-versions 命令查询kindString这里指的是 yaml 文件定义的资源类型和角色比如:PodmetadataObject元数据对象固定值就写 metadatametadata.nameString元数据对象的名字这里由我们编写比如命名 Pod 的名字metadata.namespaceString元数据对象的命名空间由我们自身定义SpecObject详细定义对象固定值就写 Specspec.containers[]list这里是 Spec 对象的容器列表定义是个列表spec.containers[].nameString这里定义容器的名字spec.containers[].imageString这里定义要用到的镜像名称spec.containers[].imagePullPolicyString定义镜像拉取策略有三个值可选 (1) Always: 每次都尝试重新拉取镜像 (2) IfNotPresent:如果本地有镜像就使用本地镜像 (3) Never:表示仅使用本地镜像spec.containers[].command[]list指定容器运行时启动的命令若未指定则运行容器打包时指定的命令spec.containers[].args[]list指定容器运行参数可以指定多个spec.containers[].workingDirString指定容器工作目录spec.containers[].volumeMounts[]list指定容器内部的存储卷配置spec.containers[].volumeMounts[].nameString指定可以被容器挂载的存储卷的名称spec.containers[].volumeMounts[].mountPathString指定可以被容器挂载的存储卷的路径spec.containers[].volumeMounts[].readOnlyString设置存储卷路径的读写模式ture 或 false默认为读写模式spec.containers[].ports[]list指定容器需要用到的端口列表spec.containers[].ports[].nameString指定端口名称spec.containers[].ports[].containerPortString指定容器需要监听的端口号spec.containers[] ports[].hostPortString指定容器所在主机需要监听的端口号默认跟上面 containerPort 相同注意设置了 hostPort 同一台主机无法启动该容器的相同副本(因为主机的端口号不能相同这样会冲突)spec.containers[].ports[].protocolString指定端口协议支持TCP 和 UDP默认值为 TCPspec.containers[].env[]list指定容器运行前需设置的环境变量列表spec.containers[].env[].nameString指定环境变量名称spec.containers[].env[].valueString指定环境变量值spec.containers[].resourcesObject指定资源限制和资源请求的值(这里开始就是设置容器的资源上限)spec.containers[].resources.limitsObject指定设置容器运行时资源的运行上限spec.containers[].resources.limits.cpuString指定 CPU 的限制单位为核心数11000mspec.containers[].resources.limits.memoryString指定 MEM 内存的限制单位为 MIB、GiBspec.containers[].resources.requestsObject指定容器启动和调度时的限制设置spec.containers[].resources.requests.cpuStringCPU 请求单位为 core 数容器启动时初始化可用数量spec.containers[].resources.requests.memoryString内存请求单位为 MIB、GIB容器启动的初始化可用数量spec.restartPolicyString定义 Pod 的重启策略默认值为Always. (1)Always: Pod-旦终止运行无论容器是如何 终止的kubelet 服务都将重启它 (2)OnFailure: 只有Pod以非零退出码终止时kubelet 才会重启该容器。如果容器正常结束(退出码为0)则 kubelet将不会重启它 (3) Never: Pod终止后kubelet 将退出码报告给 Master不会重启该spec.nodeSelectorObject定义 Node 的 Label 过滤标签以 key:value 格式指定spec.imagePullSecretsObject定义 pull 镜像时使用 secret 名称以 name:secretkey 格式指定spec.hostNetworkBoolean定义是否使用主机网络模式默认值为 false。设置 true 表示使用宿主机网络不使用 docker 网桥同时设置了 true 将无法在同一台宿主机 上启动第二个副本三Pod 的生命周期1.INIT 容器Pod 可以包含多个容器应用运行在这些容器里面同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。Init 容器与普通的容器非常相似但有两点根本区别一是它们总是运行到完成即执行完既定任务后就会退出而不会像应用容器那样持续运行二是 Init 容器不支持Readiness 就绪探针因为它们必须在Pod就绪之前全部运行完成并且每个 Init 容器必须依次成功执行下一个 Init 容器才能启动。如果 Pod 的某个 Init 容器执行失败Kubernetes会根据Pod的restartPolicy策略来决定行为如果 restartPolicy 值为 Always 或 OnFailure默认情况Kubernetes 会不断地重启该 Pod直到Init 容器成功为止但如果 Pod 对应的 restartPolicy 值为 Never则 Pod 不会重新启动会被标记为失败状态。功能Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码并且可以安全地运行这些工具避免这些工具导致应用镜像的安全性降低。通过这种方式应用镜像的创建者和部署者可以各自独立工作没有必要联合构建一个单独的应用镜像从而解耦了应用构建与环境初始化的职责。此外Init 容器能以不同于 Pod 内应用容器的文件系统视图运行因此 Init 容器可以具有访问Secrets 的权限而应用容器不能够访问这为敏感数据的初始化操作提供了更细粒度的安全隔离。由于 Init 容器必须在应用容器启动之前依次运行完成因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动直到满足了一组先决条件如数据库就绪、依赖服务可用、配置文件准备完成等。一旦所有 Init 容器成功退出前置条件满足Pod 内的所有应用容器会并行启动从而实现有序的初始化和高效的应用启动流程。2.探针探针是由 kubelet 对容器执行的定期诊断支持三种检测方式。ExecAction 是在容器内执行指定命令如果命令退出时返回码为0则认为诊断成功。TCPSocketAction 是对指定端口上的容器的IP地址进行 TCP 检查如果端口打开则诊断成功。HTTPGetAction 是对指定端口和路径上的容器的IP 地址执行 HTTP Get 请求如果响应的状态码大于等于200且小于400则诊断成功。每次探测的结果有三种成功容器通过诊断、失败容器未通过诊断、未知诊断失败不采取任何行动。livenessProbe存活探针用于指示容器是否正在运行。如果存活探测失败kubelet 会杀死容器并且容器将受到其重启策略的影响。如果容器不提供存活探针则默认状态为 Success。readinessProbe就绪探针用于指示容器是否准备好服务请求。如果就绪探测失败端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针则默认状态为 Success。startupProbe启动探针用于指示容器中的应用是否已经启动。如果提供了启动探针则禁用所有其他探针直到它成功为止。如果启动探测失败kubelet 会杀死容器容器服从其重启策略进行重启。如果容器没有提供启动探针则默认状态为 Success。readinessProbe 与 livenessProbe 的区别readinessProbe 当检测失败后将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除只影响流量调度不会重启容器。livenessProbe 当检测失败后会杀死容器并根据 Pod 的重启策略来决定作出对应的措施。startupProbe 与 readinessProbe、livenessProbe 的区别如果三个探针同时存在先执行startupProbe 探针其他两个探针将会被暂时禁用直到 Pod 满足 startupProbe 探针配置的条件后其他2个探针才会启动如果不满足则按照规则重启容器。另外两种探针在容器启动后会按照配置持续探测直到容器消亡而 startupProbe 探针只是在容器启动后按照配置成功执行一次后续不再进行探测。四Pod 相关实验1.命令式对象管理1命名空间管理查看命名空间创建命名空间删除命名空间2pod 管理查看 pod 的运行情况和在哪运行创建 pod当 pod 创建出现问题时查看 pod 运行的详细信息删除 pod2.kubectl 命令实操1上传实验镜像到仓库 library 中2生成实验所需 yml 文件3kubectl 命令使用方法createeditpatchexposelogsattachexeccprolloutscalelabel3.利用控制器实现版本更替1建立控制器2更新业务版本3版本回退4.利用 yaml 文件声明资源1在 pod 中运行多容器2在 pod 运行主机中暴漏端口3在 pod 中指定变量4选择运行节点5共享宿主机网络6资源优先级BestEffort 没有做任何资源限制资源使用优先级最低Burstable 设定了资源限制但是期望值和限制值不同资源使用优先级次之Guaranteed 期望值和最大使用限制相同优先级最高7容器重启规则Always 无论什么原因都会重新运行 podOnFailure 非正常关闭会重启 podNever pod 关闭后不重启5.pod 的生命周期实验1init 容器2Livness 存活探针没有存活探针时有存活探针时3readness 就绪探针没有就绪探针时有就绪探针时6.Replicaset 控制器1建立控制器2测试功能7.deployment1监控2建立 deployment 控制器3升级和回滚8.版本更新管理及优化1查看更新策略信息2设定更新策略3更新暂停和恢复9.DaemonSet10.Job 控制器11.Cronjob 控制器
返回列表