文档/教程【免费下载链接】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 学习路线中第 49 天2022/vi/Days/day49.md的内容系统讲解 Kubernetes 的全景图为什么单靠容器不足以支撑规模化容器编排Container Orchestration解决了什么问题Kubernetes 六大核心能力是什么以及一个集群由哪些节点、组件和对象构成。读完本文你将掌握 Kubernetes 从概念到架构的完整认知框架并能结合仓库内附的 Vagrant 多节点集群脚本与实际 YAML 清单理解控制平面、工作节点、Pod、Deployment、StatefulSet、Service 之间的协作关系为后续深入学习 kubectl、YAML、Ingress 与持久化存储打下基础。为什么容器之后还需要 Kubernetes上一阶段我们学习了容器Containers。容器的确改变了云原生系统的构建与分发方式但当谈到**规模化scaling与编排orchestration**时仅靠容器本身是不够的——最乐观的情况下我们只能用 docker-compose 把多个容器一起拉起。docker-compose 适合单机多容器的开发编排却无法自动应对流量变化、节点故障、跨主机的服务发现等问题。Kubernetes 正是一个Container Orchestrator容器编排器它带来的是以自动化方式、或依据应用与服务的负载动态进行扩缩容scale up/down的能力。原文档特别强调了一个 DevOps 视角的重要观点Kubernetes 只是运行应用的另一个选项与裸金属bare metal、虚拟化virtualisation以及云服务并列是工程师需要具备基础认知的一类平台而非唯一答案。容器编排是什么需要区分两个概念Kubernetes一项具体的开源技术容器编排Container Orchestration技术背后的概念与流程。容器编排并非 Kubernetes 独占生态中还有 Docker Swarm、HashiCorp Nomad 等平台。原文档指出Kubernetes 正从强到更强going from strength to strength因此本系列选择它作为主线索但同时提醒读者它并非唯一选择。容器编排负责管理容器的部署、放置与生命周期具体职责包括集群管理Cluster management将多台主机融合为一个统一的管理目标调度管理Schedule management通过调度器scheduler把容器分布到各节点nodes服务发现Service discovery知道容器位于哪些节点并把客户端请求分发给它们复制Replication确保为请求的工作负载保留足够数量的节点与容器健康管理Health management检测并替换不健康的容器与节点。Kubernetes 是什么六大核心能力官方定义这样描述 KubernetesKubernetes 是一个可移植、可扩展的开源平台用于管理容器化的工作负载与服务支持声明式配置与自动化。它拥有庞大且快速增长的生态系统其服务、支持与工具广泛可用。值得注意的历史背景Kubernetes 起源于 Google被捐赠给Cloud Native Computing FoundationCNCF此后由开源社区与大型企业厂商共同推动演进。容器本身并不能直接给你生产环境所需的体验Kubernetes 则提供了以下六项能力能力说明服务发现与负载均衡Service discovery and load balancing可以用 DNS 名称或 IP 地址暴露容器当容器流量较高时Kubernetes 自动负载均衡并分发网络流量保证部署稳定。存储编排Storage orchestration自动挂载你选择的存储系统如本地存储、公有云存储等。自动化上线与回滚Automated rollouts and rollbacks声明期望状态Kubernetes 以受控速率把实际状态收敛到期望状态例如自动创建新容器、移除旧容器并回收其资源。自动装箱Automatic bin packing提供节点集群后你只需告诉 Kubernetes 每个容器所需的 CPU 与内存RAM它会自动把容器塞进合适的节点最大化资源利用率。自愈Self-healing重启失败的容器、替换容器、杀掉不响应自定义健康检查的容器并且在这些容器未就绪前不把流量导向它们。密钥与配置管理Secret and configuration management存储并管理密码、OAuth token、SSH key 等敏感信息可在不重建镜像、不把密钥暴露在堆栈配置中的前提下完成部署与更新。仓库中的 pacman-stateful-demo.yaml 就是对上述能力的落地印证其中定义了mongodb-users-secretSecret 管理、readinessProbe与livenessProbe自愈所依赖的健康检查、PersistentVolumeClaim存储编排等资源后面我们会展开分析。声明式模型Kubernetes 的关键范式Kubernetes 的关键范式key paradigm是声明式模型declarative model你只需提供想要的最终状态Kubernetes 负责把现实收敛到该状态。如果你需要五个实例你不需要自己逐个启动五个实例只需告诉 Kubernetes我需要五个实例它会自动**对账reconcile**状态当其中一个实例故障Kubernetes 仍记得你的期望状态会在可用节点上重新创建实例。这也解释了为何 Kubernetes 常被称为操作系统级的控制循环它不是一次性命令式执行而是持续比较期望状态与实际状态并不断纠正。节点Node与集群Cluster的基本单元一个 Kubernetes集群Cluster是节点的集合每个节点可以是物理机bare metal或虚拟机VM。每个节点上都运行着容器运行时与 kubelet 服务并通过 kube-proxy 把 Pod 与外部组件如 Service连接起来。控制平面Control Plane节点每个 Kubernetes 集群都需要一个Control Plane 节点。控制平面的组件负责对集群做出全局决策例如调度并检测与响应集群事件。在生产环境中控制平面可以做成**高可用HA**部署与工作节点承担不同的角色。工作节点Worker Node工作节点是运行 Kubernetes 工作负载的机器可以是物理机或 VM。每个节点可以承载一个或多个 Pod节点由控制平面管理。kubeletkubelet是运行在每个节点上的代理agent确保容器运行在 Pod 中。它通过多种机制接收一组 PodSpec并确保这些 PodSpec 描述的容器处于运行且健康的状态。kubelet 不管理非 Kubernetes 创建的容器。kube-proxykube-proxy是运行在每个节点上的网络代理实现 Kubernetes Service 概念的一部分。它维护节点上的网络规则允许集群内外的网络会话与你的 Pod 通信如果操作系统提供可用的包过滤层packet filtering layerkube-proxy 会优先使用它否则由 kube-proxy 自行转发流量。容器运行时Container runtime容器运行时是负责真正运行容器的软件。Kubernetes 支持多种运行时Docker、containerd、CRI-O以及任何符合 Kubernetes CRIContainer Runtime Interface的实现。仓库中的部署脚本与这一节直接呼应2022/Days/Kubernetes/scripts/common.sh 先卸载旧版运行时再安装docker-ce docker-ce-cli containerd.io随后执行containerd config default生成/etc/containerd/config.toml并重启 containerd最终输出ContainerD Runtime Configured Successfully——即该脚本以containerd 作为实际容器运行时来满足 CRI 要求。控制平面的四个核心组件原文档详细介绍了控制平面内四个关键组件它们通过 API Server 共享集群状态并协作kube API Serverkube API Server对包括 Pods、Services、Replication Controllers 等 API 对象的数据进行验证与配置。它提供 REST 操作是整个集群共享状态的前端所有其他组件都通过它交互。从仓库脚本看kubeadm 初始化时正是通过--apiserver-advertise-address与--apiserver-cert-extra-sans指定 API Server 的对外地址与证书 SAN见 2022/Days/Kubernetes/scripts/master.sh。Scheduler调度器Scheduler是控制平面进程负责把 Pod 分配到 Node。它依据约束条件与可用资源判断调度队列中的每个 Pod 哪些节点是合法放置位置再对每个合法节点排序最终把 Pod 绑定到合适的节点。Controller Manager控制器管理器Controller Manager是一个守护进程内嵌 Kubernetes 自带的核心控制循环core control loops。在机器人或自动化领域控制循环是一个永不停歇、持续调节系统状态的循环在 Kubernetes 中控制器通过 API Server 监视集群共享状态并做出变更把当前状态推向期望状态。etcdetcd是一致且高可用consistent and highly-available的键值存储作为 Kubernetes 全部集群数据的后端存储保存整个集群的配置与状态。它是集群状态的事实来源也是理解共享状态 控制循环这一架构的关键。kubectl与集群对话的 CLIkubectl是 Kubernetes 的命令行工具它直接与 API Server 交互。你可以用它部署应用、检查与管理集群资源、查看日志。在仓库脚本中kubectl 的典型使用方式包括kubectl apply -f calico.yaml安装 Calico 网络插件kubectl apply -f ...components.yaml安装 Metrics Server并用kubectl patch deployment为其增加--kubelet-insecure-tls参数通过kubectl -n kubernetes-dashboard get secret ...提取 Dashboard 管理员 token见 2022/Days/Kubernetes/scripts/master.sh。这些命令展示了 kubectl 在真实集群初始化中的三个典型职责应用清单、修补运行中的资源、查询集群状态。核心工作负载对象从 Pod 到 Service理解了节点与组件之后接下来是 Kubernetes 的积木块——工作负载对象。原文档用一套简洁笔记勾勒出它们的分工。Pods最小的部署单元Pod是一组容器构成的逻辑应用。例如一个 Web 应用同时运行 NodeJS 容器与 MySQL 容器两者可以放在同一个 Pod 中。Pod 可以共享数据卷volumes并共享同一个网络命名空间networking namespace。关键特性Pod 为容器处理 Volumes、Secrets 与配置Pod 是**临时性ephemeral**的故障后会被自动重启应用横向扩缩容时Pod 由 ReplicaSet 复制每个 Pod 运行相同容器代码Pod 运行在工作节点上Kubernetes 通过Labels键值对标签这种简单而高效的方式标识 Pod。Deployments让 Pod 持续运行直接运行 Pod 的话Pod 死了就是死了Deployment让 Pod 持续运行Deployment 允许无停机without downtime更新正在运行的应用Deployment 还定义了 Pod 死亡时的重启策略restart strategy。仓库中的 nginx-stateless-demo.yaml 给出了一个完整的 Deployment 示例声明replicas: 1、selector.matchLabels.app: nginx、容器镜像nginx并暴露containerPort: 80配合同文件中的 Service 形成Deployment Service的无状态应用范式。ReplicaSets保证期望副本数Deployment 可以创建 ReplicaSetReplicaSet确保你的应用拥有期望数量的 PodReplicaSet 基于 Deployment 创建并扩缩容 Pod 组Deployment、ReplicaSet、Pod 之间并非互斥关系而是层层管理的关系Deployment 管理 ReplicaSetReplicaSet 管理 Pod。StatefulSets有状态应用的唯一身份你的应用是否需要保存状态信息数据库就需要状态StatefulSet的 Pod不可互换not interchangeable每个 Pod 拥有唯一、持久的标识符unique, persistent identifier控制器会在任何重新调度rescheduling中维持该标识。仓库中的 pacman-stateful-demo.yaml 是 StatefulSet 的完整实战kind: StatefulSet、serviceName: mongo、通过persistentVolumeClaim: mongo-storage挂载持久卷、初始化容器修正/bitnami/mongodb目录权限fsGroup: 1001并使用bitnami/mongodb:4.4.8镜像。它还示范了 Secret 的消费方式——通过secretKeyRef从mongodb-users-secret注入MONGODB_ROOT_PASSWORD、MONGODB_DATABASE等环境变量正是前文密钥与配置管理能力的直接体现。DaemonSets每个节点一个 PodDaemonSet面向持续进程continuous process它在每个节点上运行一个 Pod集群每新增一个节点DaemonSet 就会在该节点启动一个新 Pod非常适合监控、日志采集等后台任务每个 Pod 拥有唯一、持久的标识符由控制器在重新调度中维持。Services访问 Pod 的统一入口Service是访问 Pod 的单一端点single endpoint它提供统一的方式把流量路由到集群、最终路由到一组 Pod借助 ServicePod 可以被拉起或销毁而不影响任何调用方。在 nginx-stateless-demo.yaml 中nginx-service通过selector.app选择后端 Pod并将port: 80映射到容器的targetPort: 80而在 pacman-stateful-demo.yaml 中mongoService 采用ClusterIP供集群内部访问pacman 前端通过MONGO_SERVICE_HOST: mongo连接pacman Service 则采用LoadBalancer对外暴露。两者恰好对应原文档所述Service 统一路由流量的两种典型场景。仓库实战一条龙搭建多节点集群原文档是概念性全景图而仓库的 Kubernetes 目录提供了与之配套的可运行的多节点集群搭建资源可作为理解上述架构的直接佐证Vagrantfile定义 1 个 master 节点 2 个 worker 节点的拓扑使用bento/ubuntu-21.10镜像master 分配 4GB 内存/2 核worker 各 2GB/1 核并写入/etc/hosts主机名映射master-node、worker-node01、worker-node02。scripts/common.sh所有节点共用的初始化——关闭 swap、加载br_netfilter与overlay内核模块、配置 sysctlnet.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward等、安装 Docker Engine 与 containerd 并生成 containerd 默认配置、最后安装并apt-mark hold固定kubelet kubeadm kubectl版本1.23.3-00。scripts/master.sh在 master 上执行kubeadm init参数--apiserver-advertise-address10.0.0.10、--pod-network-cidr192.168.0.0/16、--ignore-preflight-errors Swap复制 kubeconfig把 join 命令写入/vagrant/configs/join.sh随后部署 Calico 网络插件、Metrics Server 与 Kubernetes Dashboard并创建admin-user的ServiceAccountClusterRoleBinding。scripts/node.shworker 节点执行/vagrant/configs/join.sh -v加入集群并打上node-role.kubernetes.io/worker标签。configs/join.sh由 master 脚本生成的真实 join 命令示例格式为kubeadm join API地址:6443 --token ... --discovery-token-ca-cert-hash sha256:...直观展示工作节点如何通过 API Server 令牌与证书哈希加入集群。这套脚本与本文的架构描述一一对应master-node对应控制平面节点承载 API Server、Scheduler、Controller Manager、etcdworker-node01/02对应工作节点承载 kubelet、kube-proxy、容器运行时与 Pod。需要说明的是原文档写作时以 Docker 作为运行时示例而仓库脚本实际落地为 containerd 运行时 Docker 工具链这恰好印证了Kubernetes 支持多种 CRI 运行时的论断。本系列后续将覆盖的主题原文档在结尾给出了 Kubernetes 系列的路线图本文只是全景开篇后续将继续深入Kubernetes 架构Architecturekubectl 命令Kubectl CommandsKubernetes YAMLKubernetes IngressKubernetes ServicesHelm 包管理器Helm Package Manager持久化存储Persistent Storage有状态应用Stateful Apps下一站是 Day 50在哪里运行 Kubernetes 集群将聚焦集群部署位置的选择与存储细节。参考资料官方 Kubernetes 文档概念总览什么是 Kubernetes一节原文档推荐的新手首选TechWorld with Nana 的 Kubernetes 入门教程4 小时完整课程TechWorld with Nana 的 Kubernetes 零基础速成课Kunal Kushwaha 的 Kubernetes 入门与架构简化讲解说明以上外部学习资源来自原文档的参考文献列表本文仅作指引性描述正文的全部技术结论均以本仓库文档与源码为准。赞分享文档/教程【免费下载链接】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 第49天Kubernetes 全景图——从容器编排概念到集群核心组件90DaysOfDevOps 第49天Kubernetes 全景图——从容器编排概念到集群核心组件 导读 本文是 90DaysOfDevOps 学习系列中 K文档/教程90DaysOfDevOps 之 Kubernetes 全景入门从容器编排到核心组件架构90DaysOfDevOps 之 Kubernetes 全景入门从容器编排到核心组件架构 导读 本文源自 90DaysOfDevOps https://lin文档/教程90DaysOfDevOps Day 49Kubernetes 全景入门——从容器编排概念到核心组件与工作负载原语90DaysOfDevOps Day 49Kubernetes 全景入门——从容器编排概念到核心组件与工作负载原语 Kubernetes 是当前云原生基础设施文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 之 Kubernetes 全景：从容器编排概念到集群核心组件实战
文档/教程【免费下载链接】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 学习路线中第 49 天2022/vi/Days/day49.md的内容系统讲解 Kubernetes 的全景图为什么单靠容器不足以支撑规模化容器编排Container Orchestration解决了什么问题Kubernetes 六大核心能力是什么以及一个集群由哪些节点、组件和对象构成。读完本文你将掌握 Kubernetes 从概念到架构的完整认知框架并能结合仓库内附的 Vagrant 多节点集群脚本与实际 YAML 清单理解控制平面、工作节点、Pod、Deployment、StatefulSet、Service 之间的协作关系为后续深入学习 kubectl、YAML、Ingress 与持久化存储打下基础。为什么容器之后还需要 Kubernetes上一阶段我们学习了容器Containers。容器的确改变了云原生系统的构建与分发方式但当谈到**规模化scaling与编排orchestration**时仅靠容器本身是不够的——最乐观的情况下我们只能用 docker-compose 把多个容器一起拉起。docker-compose 适合单机多容器的开发编排却无法自动应对流量变化、节点故障、跨主机的服务发现等问题。Kubernetes 正是一个Container Orchestrator容器编排器它带来的是以自动化方式、或依据应用与服务的负载动态进行扩缩容scale up/down的能力。原文档特别强调了一个 DevOps 视角的重要观点Kubernetes 只是运行应用的另一个选项与裸金属bare metal、虚拟化virtualisation以及云服务并列是工程师需要具备基础认知的一类平台而非唯一答案。容器编排是什么需要区分两个概念Kubernetes一项具体的开源技术容器编排Container Orchestration技术背后的概念与流程。容器编排并非 Kubernetes 独占生态中还有 Docker Swarm、HashiCorp Nomad 等平台。原文档指出Kubernetes 正从强到更强going from strength to strength因此本系列选择它作为主线索但同时提醒读者它并非唯一选择。容器编排负责管理容器的部署、放置与生命周期具体职责包括集群管理Cluster management将多台主机融合为一个统一的管理目标调度管理Schedule management通过调度器scheduler把容器分布到各节点nodes服务发现Service discovery知道容器位于哪些节点并把客户端请求分发给它们复制Replication确保为请求的工作负载保留足够数量的节点与容器健康管理Health management检测并替换不健康的容器与节点。Kubernetes 是什么六大核心能力官方定义这样描述 KubernetesKubernetes 是一个可移植、可扩展的开源平台用于管理容器化的工作负载与服务支持声明式配置与自动化。它拥有庞大且快速增长的生态系统其服务、支持与工具广泛可用。值得注意的历史背景Kubernetes 起源于 Google被捐赠给Cloud Native Computing FoundationCNCF此后由开源社区与大型企业厂商共同推动演进。容器本身并不能直接给你生产环境所需的体验Kubernetes 则提供了以下六项能力能力说明服务发现与负载均衡Service discovery and load balancing可以用 DNS 名称或 IP 地址暴露容器当容器流量较高时Kubernetes 自动负载均衡并分发网络流量保证部署稳定。存储编排Storage orchestration自动挂载你选择的存储系统如本地存储、公有云存储等。自动化上线与回滚Automated rollouts and rollbacks声明期望状态Kubernetes 以受控速率把实际状态收敛到期望状态例如自动创建新容器、移除旧容器并回收其资源。自动装箱Automatic bin packing提供节点集群后你只需告诉 Kubernetes 每个容器所需的 CPU 与内存RAM它会自动把容器塞进合适的节点最大化资源利用率。自愈Self-healing重启失败的容器、替换容器、杀掉不响应自定义健康检查的容器并且在这些容器未就绪前不把流量导向它们。密钥与配置管理Secret and configuration management存储并管理密码、OAuth token、SSH key 等敏感信息可在不重建镜像、不把密钥暴露在堆栈配置中的前提下完成部署与更新。仓库中的 pacman-stateful-demo.yaml 就是对上述能力的落地印证其中定义了mongodb-users-secretSecret 管理、readinessProbe与livenessProbe自愈所依赖的健康检查、PersistentVolumeClaim存储编排等资源后面我们会展开分析。声明式模型Kubernetes 的关键范式Kubernetes 的关键范式key paradigm是声明式模型declarative model你只需提供想要的最终状态Kubernetes 负责把现实收敛到该状态。如果你需要五个实例你不需要自己逐个启动五个实例只需告诉 Kubernetes我需要五个实例它会自动**对账reconcile**状态当其中一个实例故障Kubernetes 仍记得你的期望状态会在可用节点上重新创建实例。这也解释了为何 Kubernetes 常被称为操作系统级的控制循环它不是一次性命令式执行而是持续比较期望状态与实际状态并不断纠正。节点Node与集群Cluster的基本单元一个 Kubernetes集群Cluster是节点的集合每个节点可以是物理机bare metal或虚拟机VM。每个节点上都运行着容器运行时与 kubelet 服务并通过 kube-proxy 把 Pod 与外部组件如 Service连接起来。控制平面Control Plane节点每个 Kubernetes 集群都需要一个Control Plane 节点。控制平面的组件负责对集群做出全局决策例如调度并检测与响应集群事件。在生产环境中控制平面可以做成**高可用HA**部署与工作节点承担不同的角色。工作节点Worker Node工作节点是运行 Kubernetes 工作负载的机器可以是物理机或 VM。每个节点可以承载一个或多个 Pod节点由控制平面管理。kubeletkubelet是运行在每个节点上的代理agent确保容器运行在 Pod 中。它通过多种机制接收一组 PodSpec并确保这些 PodSpec 描述的容器处于运行且健康的状态。kubelet 不管理非 Kubernetes 创建的容器。kube-proxykube-proxy是运行在每个节点上的网络代理实现 Kubernetes Service 概念的一部分。它维护节点上的网络规则允许集群内外的网络会话与你的 Pod 通信如果操作系统提供可用的包过滤层packet filtering layerkube-proxy 会优先使用它否则由 kube-proxy 自行转发流量。容器运行时Container runtime容器运行时是负责真正运行容器的软件。Kubernetes 支持多种运行时Docker、containerd、CRI-O以及任何符合 Kubernetes CRIContainer Runtime Interface的实现。仓库中的部署脚本与这一节直接呼应2022/Days/Kubernetes/scripts/common.sh 先卸载旧版运行时再安装docker-ce docker-ce-cli containerd.io随后执行containerd config default生成/etc/containerd/config.toml并重启 containerd最终输出ContainerD Runtime Configured Successfully——即该脚本以containerd 作为实际容器运行时来满足 CRI 要求。控制平面的四个核心组件原文档详细介绍了控制平面内四个关键组件它们通过 API Server 共享集群状态并协作kube API Serverkube API Server对包括 Pods、Services、Replication Controllers 等 API 对象的数据进行验证与配置。它提供 REST 操作是整个集群共享状态的前端所有其他组件都通过它交互。从仓库脚本看kubeadm 初始化时正是通过--apiserver-advertise-address与--apiserver-cert-extra-sans指定 API Server 的对外地址与证书 SAN见 2022/Days/Kubernetes/scripts/master.sh。Scheduler调度器Scheduler是控制平面进程负责把 Pod 分配到 Node。它依据约束条件与可用资源判断调度队列中的每个 Pod 哪些节点是合法放置位置再对每个合法节点排序最终把 Pod 绑定到合适的节点。Controller Manager控制器管理器Controller Manager是一个守护进程内嵌 Kubernetes 自带的核心控制循环core control loops。在机器人或自动化领域控制循环是一个永不停歇、持续调节系统状态的循环在 Kubernetes 中控制器通过 API Server 监视集群共享状态并做出变更把当前状态推向期望状态。etcdetcd是一致且高可用consistent and highly-available的键值存储作为 Kubernetes 全部集群数据的后端存储保存整个集群的配置与状态。它是集群状态的事实来源也是理解共享状态 控制循环这一架构的关键。kubectl与集群对话的 CLIkubectl是 Kubernetes 的命令行工具它直接与 API Server 交互。你可以用它部署应用、检查与管理集群资源、查看日志。在仓库脚本中kubectl 的典型使用方式包括kubectl apply -f calico.yaml安装 Calico 网络插件kubectl apply -f ...components.yaml安装 Metrics Server并用kubectl patch deployment为其增加--kubelet-insecure-tls参数通过kubectl -n kubernetes-dashboard get secret ...提取 Dashboard 管理员 token见 2022/Days/Kubernetes/scripts/master.sh。这些命令展示了 kubectl 在真实集群初始化中的三个典型职责应用清单、修补运行中的资源、查询集群状态。核心工作负载对象从 Pod 到 Service理解了节点与组件之后接下来是 Kubernetes 的积木块——工作负载对象。原文档用一套简洁笔记勾勒出它们的分工。Pods最小的部署单元Pod是一组容器构成的逻辑应用。例如一个 Web 应用同时运行 NodeJS 容器与 MySQL 容器两者可以放在同一个 Pod 中。Pod 可以共享数据卷volumes并共享同一个网络命名空间networking namespace。关键特性Pod 为容器处理 Volumes、Secrets 与配置Pod 是**临时性ephemeral**的故障后会被自动重启应用横向扩缩容时Pod 由 ReplicaSet 复制每个 Pod 运行相同容器代码Pod 运行在工作节点上Kubernetes 通过Labels键值对标签这种简单而高效的方式标识 Pod。Deployments让 Pod 持续运行直接运行 Pod 的话Pod 死了就是死了Deployment让 Pod 持续运行Deployment 允许无停机without downtime更新正在运行的应用Deployment 还定义了 Pod 死亡时的重启策略restart strategy。仓库中的 nginx-stateless-demo.yaml 给出了一个完整的 Deployment 示例声明replicas: 1、selector.matchLabels.app: nginx、容器镜像nginx并暴露containerPort: 80配合同文件中的 Service 形成Deployment Service的无状态应用范式。ReplicaSets保证期望副本数Deployment 可以创建 ReplicaSetReplicaSet确保你的应用拥有期望数量的 PodReplicaSet 基于 Deployment 创建并扩缩容 Pod 组Deployment、ReplicaSet、Pod 之间并非互斥关系而是层层管理的关系Deployment 管理 ReplicaSetReplicaSet 管理 Pod。StatefulSets有状态应用的唯一身份你的应用是否需要保存状态信息数据库就需要状态StatefulSet的 Pod不可互换not interchangeable每个 Pod 拥有唯一、持久的标识符unique, persistent identifier控制器会在任何重新调度rescheduling中维持该标识。仓库中的 pacman-stateful-demo.yaml 是 StatefulSet 的完整实战kind: StatefulSet、serviceName: mongo、通过persistentVolumeClaim: mongo-storage挂载持久卷、初始化容器修正/bitnami/mongodb目录权限fsGroup: 1001并使用bitnami/mongodb:4.4.8镜像。它还示范了 Secret 的消费方式——通过secretKeyRef从mongodb-users-secret注入MONGODB_ROOT_PASSWORD、MONGODB_DATABASE等环境变量正是前文密钥与配置管理能力的直接体现。DaemonSets每个节点一个 PodDaemonSet面向持续进程continuous process它在每个节点上运行一个 Pod集群每新增一个节点DaemonSet 就会在该节点启动一个新 Pod非常适合监控、日志采集等后台任务每个 Pod 拥有唯一、持久的标识符由控制器在重新调度中维持。Services访问 Pod 的统一入口Service是访问 Pod 的单一端点single endpoint它提供统一的方式把流量路由到集群、最终路由到一组 Pod借助 ServicePod 可以被拉起或销毁而不影响任何调用方。在 nginx-stateless-demo.yaml 中nginx-service通过selector.app选择后端 Pod并将port: 80映射到容器的targetPort: 80而在 pacman-stateful-demo.yaml 中mongoService 采用ClusterIP供集群内部访问pacman 前端通过MONGO_SERVICE_HOST: mongo连接pacman Service 则采用LoadBalancer对外暴露。两者恰好对应原文档所述Service 统一路由流量的两种典型场景。仓库实战一条龙搭建多节点集群原文档是概念性全景图而仓库的 Kubernetes 目录提供了与之配套的可运行的多节点集群搭建资源可作为理解上述架构的直接佐证Vagrantfile定义 1 个 master 节点 2 个 worker 节点的拓扑使用bento/ubuntu-21.10镜像master 分配 4GB 内存/2 核worker 各 2GB/1 核并写入/etc/hosts主机名映射master-node、worker-node01、worker-node02。scripts/common.sh所有节点共用的初始化——关闭 swap、加载br_netfilter与overlay内核模块、配置 sysctlnet.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward等、安装 Docker Engine 与 containerd 并生成 containerd 默认配置、最后安装并apt-mark hold固定kubelet kubeadm kubectl版本1.23.3-00。scripts/master.sh在 master 上执行kubeadm init参数--apiserver-advertise-address10.0.0.10、--pod-network-cidr192.168.0.0/16、--ignore-preflight-errors Swap复制 kubeconfig把 join 命令写入/vagrant/configs/join.sh随后部署 Calico 网络插件、Metrics Server 与 Kubernetes Dashboard并创建admin-user的ServiceAccountClusterRoleBinding。scripts/node.shworker 节点执行/vagrant/configs/join.sh -v加入集群并打上node-role.kubernetes.io/worker标签。configs/join.sh由 master 脚本生成的真实 join 命令示例格式为kubeadm join API地址:6443 --token ... --discovery-token-ca-cert-hash sha256:...直观展示工作节点如何通过 API Server 令牌与证书哈希加入集群。这套脚本与本文的架构描述一一对应master-node对应控制平面节点承载 API Server、Scheduler、Controller Manager、etcdworker-node01/02对应工作节点承载 kubelet、kube-proxy、容器运行时与 Pod。需要说明的是原文档写作时以 Docker 作为运行时示例而仓库脚本实际落地为 containerd 运行时 Docker 工具链这恰好印证了Kubernetes 支持多种 CRI 运行时的论断。本系列后续将覆盖的主题原文档在结尾给出了 Kubernetes 系列的路线图本文只是全景开篇后续将继续深入Kubernetes 架构Architecturekubectl 命令Kubectl CommandsKubernetes YAMLKubernetes IngressKubernetes ServicesHelm 包管理器Helm Package Manager持久化存储Persistent Storage有状态应用Stateful Apps下一站是 Day 50在哪里运行 Kubernetes 集群将聚焦集群部署位置的选择与存储细节。参考资料官方 Kubernetes 文档概念总览什么是 Kubernetes一节原文档推荐的新手首选TechWorld with Nana 的 Kubernetes 入门教程4 小时完整课程TechWorld with Nana 的 Kubernetes 零基础速成课Kunal Kushwaha 的 Kubernetes 入门与架构简化讲解说明以上外部学习资源来自原文档的参考文献列表本文仅作指引性描述正文的全部技术结论均以本仓库文档与源码为准。赞分享文档/教程【免费下载链接】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 第49天Kubernetes 全景图——从容器编排概念到集群核心组件90DaysOfDevOps 第49天Kubernetes 全景图——从容器编排概念到集群核心组件 导读 本文是 90DaysOfDevOps 学习系列中 K文档/教程90DaysOfDevOps 之 Kubernetes 全景入门从容器编排到核心组件架构90DaysOfDevOps 之 Kubernetes 全景入门从容器编排到核心组件架构 导读 本文源自 90DaysOfDevOps https://lin文档/教程90DaysOfDevOps Day 49Kubernetes 全景入门——从容器编排概念到核心组件与工作负载原语90DaysOfDevOps Day 49Kubernetes 全景入门——从容器编排概念到核心组件与工作负载原语 Kubernetes 是当前云原生基础设施文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考