文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载导读本文是 90DaysOfDevOps 学习系列中 Kubernetes 篇章的开篇第49天承接前一日关于容器Containers的内容系统讲解容器编排Container Orchestration的概念、Kubernetes 平台的核心价值与六大能力、集群Cluster的组件构成控制平面与工作节点以及 Pod、Deployment、ReplicaSet、StatefulSet、DaemonSet、Service 等 Kubernetes 基础对象。读完本文你将能够完整理解 Kubernetes 的架构骨架与声明式工作模型掌握集群中每个组件的职责并为后续动手实践YAML 编排、Ingress、Helm、持久化存储打下基础。仓库中配套的 Kubernetes 目录 提供了完整的 kubeadm 集群搭建脚本与示例清单文件可配合本文边学边练。从容器到容器编排为什么需要 Kubernetes在前一节容器中我们讨论了容器与容器镜像如何改变并加速了云原生系统的采用。但容器单独存在时无法解决规模化与编排问题一台宿主机上通过 docker-compose 可以把多个容器一起拉起来但这仍是单机、手工定义的层面缺少自动化扩缩容、故障自愈、跨节点调度等能力。Kubernetes 正是为解决这一问题而生的容器编排器Container Orchestrator它让我们能够以自动化方式、或基于应用与服务的负载对容器进行上下伸缩scale up/down。从 DevOps 视角来看Kubernetes 只是需要具备基础认知的众多平台之一——你同样需要理解裸金属bare metal、虚拟化virtualisation以及大概率还有云服务。Kubernetes 只是运行应用的一种选择它可以同时应用于上述这些环境。什么是容器编排需要先厘清两个概念Kubernetes是具体的技术technology容器编排是技术背后的概念或流程concept / process。Kubernetes 并非唯一的容器编排平台同领域的竞争者还包括 Docker Swarm、HashiCorp Nomad 等。但 Kubernetes 是目前采用最广、发展势头最强的编排平台因此本系列聚焦于它。容器编排负责管理容器的部署deployment、放置placement与生命周期lifecycle并承担以下职责集群管理把多台主机联邦federate成一个统一目标调度管理通过调度器scheduler把容器分布到各个节点服务发现知道容器在哪里并在它们之间分发客户端请求复制Replication为请求的工作负载保证有正确数量的节点与容器可用健康管理检测并替换不健康的容器与节点。Kubernetes 是什么定义、历史与六大核心能力Kubernetes 的官方定义是一个可移植portable、可扩展extensible、开源open-source的容器化工作负载与服务管理平台同时支持声明式配置与自动化并且拥有庞大且快速成长的生态系统其服务、支持与工具广泛可得。值得注意的是Kubernetes 是开源的其历史可以追溯到 Google 将项目捐赠给云原生计算基金会CNCF此后由开源社区以及大型企业厂商共同推动其演进到今天。容器虽好但容器本身无法提供生产级应用所需的体验。Kubernetes 为我们提供以下解决方案服务发现与负载均衡Service discovery and load balancingKubernetes 可以使用 DNS 名称或 IP 地址暴露容器当流向某容器的流量过高时Kubernetes 可以负载均衡并分发网络流量保证部署稳定。存储编排Storage orchestrationKubernetes 允许自动挂载你选择的存储系统如本地存储、公有云提供商的存储等。自动化上线与回滚Automated rollouts and rollbacks你可以用 Kubernetes 描述已部署容器的期望状态并以受控速率把实际状态调整为期望状态。例如自动为新部署创建容器、删除现有容器并将其全部资源迁移到新容器。自动装箱Automatic bin packing你向 Kubernetes 提供一个节点集群并告知每个容器所需的 CPU 与内存RAMKubernetes 会把容器合理地装到各节点上最大化资源利用。自愈Self-healingKubernetes 会重启失败的容器、替换容器、杀掉未通过用户定义健康检查的容器并且在容器准备好对外服务之前不向客户端通告它。密钥与配置管理Secret and configuration managementKubernetes 可以存储和管理密码、OAuth token、SSH key 等敏感信息可以在不重建容器镜像、不把密钥暴露在栈配置中的前提下部署和更新密钥与应用配置。综上Kubernetes 提供了一个让分布式系统具备弹性resiliently运行的框架。它的关键范式是声明式模型declarative model你提供期望状态desired stateKubernetes 负责实现它。比如你需要 5 个实例不必自己手动启动 5 个独立实例只需告诉 Kubernetes 需要 5 个实例它会自动调和reconcile状态即使某个实例出故障Kubernetes 依然知道你的期望状态并会在可用节点上重新创建实例。Kubernetes 集群的两大角色控制平面与工作节点Kubernetes 是一个用于供给provision、管理manage与扩缩scale应用的容器编排器用来管理**节点集群cluster of nodes**中容器化应用的生命周期——节点是工作机器的集合可以是 VM 或物理机。应用运行可能还需要卷volumes、网络networks、密钥secrets等资源来连接数据库、与有防火墙的后端通信、保护密钥Kubernetes 允许你把这些基础设施资源以声明式方式纳入应用管理。控制平面Control Plane每个 Kubernetes 集群都需要一个控制平面节点。控制平面组件负责对整个集群做出全局决策例如调度 scheduling以及检测并响应集群事件。工作节点Worker Node工作节点是运行 Kubernetes 工作负载的机器可以是物理机裸金属或虚拟机VM。每个节点可以承载一个或多个 Pod节点由控制平面统一管理。还存在其他类型的节点本文不做展开。kubeletkubelet 是运行在集群每个节点上的代理确保容器在 Pod 中运行。它接收通过多种机制提供的 PodSpec 集合确保这些 PodSpec 描述的容器正在运行且健康。需要注意的是kubelet 不管理并非由 Kubernetes 创建的容器。kube-proxykube-proxy 是运行在每个节点上的网络代理实现了 Kubernetes Service 概念的一部分。它维护节点上的网络规则这些规则允许来自集群内部或外部的网络会话与 Pod 通信。kube-proxy 会优先使用操作系统自带的数据包过滤层packet filtering layer如果不存在或不可用则自己转发流量。容器运行时Container runtime容器运行时是负责运行容器的软件。Kubernetes 支持多种容器运行时Docker、containerd、CRI-O以及任何实现了 Kubernetes **CRIContainer Runtime Interface容器运行时接口**的实现。CRI 是 Kubernetes 与运行时解耦的关键抽象——只要实现了 CRI运行时就可以被 Kubernetes 调度与管理。集群内的控制平面组件API Server、Scheduler、Controller Manager 与 etcd一个集群是一组节点的集合节点可以是物理机或虚拟机。每个节点都装有容器运行时如 Docker运行一个 kubelet 服务接收来自 Master 控制器的命令和一个 Proxy用于把来自其他组件——如后续将讲的 Service——的连接代理到 Pod。控制平面可以做**高可用highly available**部署它与工作节点相比包含一些独特角色其中最重要的是kube API Server——所有与集群取信息、推信息的通信都发生在这里。kube-apiserverAPI Server 校验并配置 API 对象的数据这些对象包括 Pod、Service、ReplicationController 等。它对外提供 REST 操作是整个集群共享状态的前端frontend所有其他组件都通过它进行交互。kubectl、Scheduler、Controller Manager 与各节点上的 kubelet本质上都在与 API Server 对话。Scheduler调度器调度器是控制平面中的一个进程负责把 Pod 分配到节点Node。它根据约束constraints与可用资源判断调度队列中每个 Pod 有哪些节点是合法放置位置然后对每个合法节点打分排序最后把 Pod 绑定bind到合适的节点上。Controller Manager控制器管理器控制器管理器是一个守护进程daemon内嵌了 Kubernetes 自带的核心控制循环control loops。在机器人学与自动化应用中控制循环是一个永不终止的、调节系统状态的循环。在 Kubernetes 中控制器就是这样一个控制循环它通过 apiserver观察集群的共享状态并做出改变试图把当前状态推向期望状态。etcdetcd 是一个一致consistent且高可用highly-available的键值存储key-value store用作 Kubernetes 存储所有集群数据的后端存储backing store。它是集群状态的单一事实来源。kubectl与 API Server 交互的命令行工具从 CLI 视角看我们通过kubectl管理这一切——kubectl 与 API Server 交互。它是 Kubernetes 的命令行工具允许你对集群执行命令部署应用、检查与管理集群资源、查看日志。# 查看集群节点 kubectl get nodes # 查看集群中的 Pod kubectl get pods -A # 部署一个清单文件定义的应用 kubectl apply -f nginx-stateless-demo.yaml # 查看 Deployment 与 Service kubectl get deploy,svc -n nginx仓库 2022/Days/Kubernetes/scripts/master.sh 中的集群引导脚本演示了 kubectl 的典型用法kubectl apply -f calico.yaml安装 Calico 网络插件、kubectl apply -f .../metrics-server/...components.yaml安装 Metrics Server、kubectl -n kubernetes-dashboard get secret ...获取 Dashboard 的登录 token 等。该脚本配合 Vagrantfile 与 node.sh 即可拉起一个多节点 kubeadm 集群含主节点 10.0.0.10、Pod 网段 192.168.0.0/16是体验上述全部组件的最佳方式。工作负载对象Pod、Deployment、ReplicaSet、StatefulSet、DaemonSetPodKubernetes 的最小单元Pod 是组成一个逻辑应用的容器组。例如一个 Web 应用运行 NodeJS 容器 MySQL 容器那么这两个容器可以放在同一个 Pod 中虽然并不推荐把数据库与 Web 放一起。Pod 可以共享公共数据卷data volumes并共享同一个网络命名空间。Pod 是短暂的ephemeral可被 Master 控制器随时拉起或销毁。Kubernetes 通过Label键值对name – value这种简单而有效的方式来标识 Pod。Pod 的重要特征Pod 是 Kubernetes 中最小的部署单元Pod 为容器处理Volumes、Secrets 与配置Pod 是短暂的设计上死亡后会被自动重启应用被 ReplicaSet 横向扩缩时Pod 会被复制每个 Pod 运行相同的容器代码Pod 存活在**工作节点Worker Nodes**上同一 Pod 内的容器可以通过 localhost 相互通信。Deployment持续运行与滚动更新的方式你可以直接运行 Pod但Pod 一旦死亡就真的死了。Deployment 是让 Pod持续运行的方式它解决了重启与更新两大问题Deployment 让 Pod 持续运行Deployment 允许你在**不宕机without downtime**的情况下更新运行中的应用Deployment 指定重启策略在 Pod 死亡时按策略重启Deployment 是生产环境中管理 Pod 的推荐方式Deployment 是处理 Pod 与 ReplicaSet 创建的高层抽象与 Kubernetes 中一切一样Deployment 是声明式的——你描述集群中的期望状态Kubernetes 负责把实际状态调整为期望状态。仓库中的 nginx-stateless-demo.yaml 是一个完整的无状态示例它定义了nginx命名空间、一个replicas: 1的 Deployment镜像nginxcontainerPort: 80以及一个通过selector选中该 Deployment Pod 的 Service。这个三段式清单Namespace Deployment Service正是 Kubernetes 声明式编排的入门模板。ReplicaSet保证期望副本数如前所述Deployment 会创建 ReplicaSet。ReplicaSet 是定义一组相同 Pod 的对象它保证指定数量的 Pod 副本始终在运行Pod 太多就删除多余的Pod 太少就创建新的。因此 ReplicaSet 是生产环境中管理 Pod 的推荐方式之一ReplicaSet 确保应用具有期望数量的 PodReplicaSet 基于 Deployment 创建并扩缩 PodDeployment、ReplicaSet 与 Pod 三者不是互斥的而是层层递进的关系Deployment → ReplicaSet → Pod。StatefulSet有状态应用如果你的应用需要保留关于状态的信息例如数据库需要状态那就需要 StatefulSet。StatefulSet 与 Deployment 类似但有以下关键差异StatefulSet 的 Pod不可互换not interchangeable每个 Pod 有唯一且持久unique, persistent的标识符控制器在任何重新调度rescheduling后都会维护它StatefulSet 的 Pod按顺序逐个创建StatefulSet 的 Pod 拥有稳定且可预测的 DNS 名称在重新调度后保持不变卷可以是持久化的persistent。仓库中的 statefulset.yaml 展示了 MongoDB 的有状态部署通过serviceName: mongo提供稳定网络标识通过persistentVolumeClaim: mongo-storage挂载持久卷并通过secretKeyRef从 Secret 注入MONGODB_ROOT_PASSWORD等环境变量还配置了readinessProbe执行mongo ... --evalquit()做就绪探针。而 pacman-stateful-demo.yaml 则是一个更完整的端到端示例PVCmongo-storage1GiReadWriteOnce StatefulSetMongoDB 4.4.8 Deploymentpacman Node.js 应用quay.io/ifont/pacman-nodejs-app:latest带 liveness/readiness 探针 两个 ServiceClusterIP类型连接 MongoDB、LoadBalancer类型暴露 pacman Web 应用 配套的 RBAC 与 PodSecurityPolicy。把有状态与无状态工作负载放在同一清单中对照阅读可以直观理解 StatefulSet 与 Deployment 的区别。DaemonSet每个节点一个 PodDaemonSet 面向持续运行的进程每个节点运行一个 Pod每个新加入集群的节点都会自动启动一个 Pod适用于**监控monitoring与日志采集log collection**等后台任务每个 Pod 具有唯一且持久的标识符控制器在任何重新调度后都会维护它。Service访问 Pod 的统一入口Service 的特征是访问 Pod 的单一端点single endpoint提供统一的方式把流量路由到集群、并最终路由到一组 Pod借助 ServicePod 可以随意上下线而不影响任何访问Service 可以内部或外部暴露也可以暴露在不同端口。以上只是对 Kubernetes 基础构建块fundamental building blocks的快速概览。基于这些知识后续我们还可以加入**存储Storage与入口Ingress**来增强应用同时我们还有很多关于Kubernetes 集群跑在哪里的选择。下一节将聚焦这些可选的集群运行位置并探索存储细节。本 Kubernetes 系列后续将覆盖的内容Kubernetes 架构Kubernetes ArchitectureKubectl 命令Kubectl CommandsKubernetes YAMLKubernetes IngressKubernetes ServicesHelm 包管理器Helm Package Manager持久化存储Persistent Storage有状态应用Stateful Apps仓库中的 pacman-ingress.yamlhost: pacman.com、pathType: Prefix、后端指向pacmanService 的 80 端口与 Rancher 目录下的多集群部署脚本正是后续 Ingress、Services 与集群管理章节的配套素材。小结容器本身无法解决规模化与编排问题Kubernetes 是容器编排器提供自动化扩缩容与声明式状态管理Kubernetes 的六大核心能力是服务发现与负载均衡、存储编排、自动化上线与回滚、自动装箱、自愈、密钥与配置管理集群由**控制平面kube-apiserver、Scheduler、Controller Manager、etcd与工作节点kubelet、kube-proxy、容器运行时**构成工作负载对象按职责分层Pod最小单元→ Deployment/ReplicaSet无状态持续运行→ StatefulSet有状态→ DaemonSet每节点一个并由Service提供统一访问入口全部模型遵循声明式范式你描述期望状态Kubernetes 通过控制器循环不断调和实际状态。下一节我们将探讨可以在哪里运行 Kubernetes 集群并深入存储相关的细节。在动手之前可以先对照 2022/Days/Kubernetes 目录中的 Vagrantfile、kubeadm 脚本与示例 YAML把本文的每个概念落到真实集群上验证一遍。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 之 Kubernetes 全景入门从容器编排到核心组件架构90DaysOfDevOps 之 Kubernetes 全景入门从容器编排到核心组件架构 导读 本文源自 90DaysOfDevOps https://lin文档/教程Kubernetes核心概念Pod与容器编排机制详解Kubernetes核心概念Pod与容器编排机制详解 本文深入解析Kubernetes最核心的调度单元Pod的设计理念与架构详细剖析容器运行时接口 CRI教程云原生容器编排90DaysOfDevOps 第 75 天GitHub Actions 工作流核心概念与 Super-Linter 实战入门90DaysOfDevOps 第 75 天GitHub Actions 工作流核心概念与 Super Linter 实战入门 本指南围绕 90DaysOfDe文档/教程上一篇3 步跑通 CyberStrikeAIAI 驱动的渗透测试平台下一篇QQ空间说说导出免费完整搞定GetQzonehistory 三分钟本地备份创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考