什么是 Kubernetes

‍

Kubernetes（通常简称 K8s）是一个开源的容器编排平台，主要用于自动化容器化应用的部署、扩展、管理和运维。它由 Google 基于内部的 Borg 系统经验开发，后捐赠给 CNCF（云原生计算基金会）并成为其核心项目。

k8s 是一个开源的容器编排平台。它的主要目标是自动化部署、扩展和管理容器化应用程序。

k8s 也是一个全新的基于容器技术的分布式架构领先方案，确切地说，Kubernetes是谷歌严格保密十几年的秘密武器Borg的一个开源版本。

Borg 是谷歌内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。

‍

Kubernetes 可以做什么？

1. 容器编排与调度自动管理容器的生命周期，根据应用需求和资源状况（如 CPU、内存），智能地在集群节点上分配和调度容器，确保负载均衡。
2. 自动扩缩容基于设定的规则（如 CPU 使用率、请求量）自动增加或减少容器实例数量，应对流量波动（例如电商促销时自动扩容，低峰时缩容节省资源）。
3. 自愈能力监控容器和节点健康状态，当容器崩溃、节点故障或资源不足时，自动重启容器、替换故障节点上的实例，保证应用持续可用。
4. 服务发现与负载均衡内置 DNS 服务，自动为容器分配网络标识（服务名），并通过负载均衡将请求分发到多个容器实例，无需手动配置网络规则。
5. 滚动更新与回滚支持应用的无缝更新（逐步替换旧版本容器，确保零 downtime），若更新出现问题，可快速回滚到之前的稳定版本。
6. 存储编排自动挂载不同类型的存储系统（本地存储、云存储如 AWS EBS、分布式存储如 Ceph 等），并根据应用需求动态分配存储资源。
7. 配置与密钥管理集中管理应用配置（如环境变量）和敏感信息（如密码、API 密钥），无需硬编码到容器镜像，便于配置更新和安全管控。
8. 集群管理与监控支持多节点集群的统一管理，集成监控（如 Prometheus）和日志收集（如 ELK Stack）工具，提供集群和应用的运行状态视图。

‍

Kubernetes架构图

Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。Borg是谷歌内部的大规模集群管理系统，负责对谷歌内部很多核心服务的调度和管理。Borg的目的是让用户不必操心资源管理的问题，让他们专注于自己的核心业务，并且做到跨多个数据中心的资源利用率最大化。

Kubernetes 架构采用​主从（Master-Worker）分布式模式，核心是 “控制平面” 管理集群状态，“工作节点” 运行实际应用，两者通过网络通信协同工作。

一、Kubernetes 核心架构图（文字简化版）

plaintext

[控制平面（Control Plane）- 管理集群决策]
        ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
        │ kube-apiserver│    │ etcd      │    │ kube-scheduler│  │ kube-controller-manager│
        └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
                │               │               │               │
                └───────────────┼───────────────┼───────────────┘
                                │
                                ▼ （网络通信）
[工作节点（Worker Node）- 运行应用负载]
        ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
        │ kubelet     │    │ kube-proxy  │    │ 容器运行时  │
        └─────────────┘    └─────────────┘    └─────────────┘
                │               │               │
                └───────────────┼───────────────┘
                                │
                                ▼
                        ┌─────────────┐
                        │ 容器化应用  │（如Nginx、Java服务）
                        └─────────────┘

‍

二、核心组件详解

1. 控制平面（Control Plane）：集群的 “大脑”

控制平面负责管理集群的整体状态，决定 “做什么”（如部署 Pod、扩缩容），不直接运行应用。所有组件通常部署在 Master 节点（生产环境建议多 Master 高可用）。

• kube-API-server：集群的 “统一入口”

  • 所有操作（如kubectl命令、组件通信）都通过它进行，提供 RESTful API。
  • 负责身份认证、授权和请求验证，是控制平面组件间的 “通信枢纽”。

• ​etcd：集群的 “数据库”

  • 存储集群的所有核心数据（如 Pod 配置、服务规则、节点信息），是分布式键值存储。
  • 生产环境需单独部署高可用集群（至少 3 节点），确保数据不丢失。

• ​kube-scheduler：集群的 “调度员”

  • 监听未分配节点的 Pod，根据 “调度策略”（如资源需求、亲和性规则、污点容忍）选择最合适的 Worker 节点。
  • 仅负责 “选节点”，不负责 Pod 的实际创建（由 kubelet 执行）。

• ​kube-controller-manager：集群的 “控制器集合”

  • 运行多个控制器进程，确保集群状态与 “期望状态” 一致（如 Pod 崩溃后重启、副本数维持）。
  • 核心控制器包括：Node 控制器（监控节点健康）、ReplicaSet 控制器（维持副本数）、Deployment 控制器（管理滚动更新）等。

• Scheduler： " 调度器"

• • 将容器调度到相应调度节点上运行

2. 工作节点（Worker Node）：集群的 “手脚”

Worker 节点是实际运行容器化应用的服务器，每个节点都运行以下组件，接收控制平面的指令并执行。

• ​kubelet：节点的 “管理员”

  • 监听 kube-apiserver 的指令，在节点上创建 / 删除 Pod、启动 / 停止容器。
  • 检查容器健康状态，定期向控制平面汇报节点和 Pod 状态（如 CPU / 内存使用、容器运行状态）。

• ​kube-proxy：节点的 “网络代理”

  • 维护节点的网络规则（如 iptables/ipvs），实现 K8s 的 “服务（Service）” 功能。
  • 负责 Pod 间通信、外部请求转发到 Pod（负载均衡），确保服务访问的稳定性。

• ​容器运行时（Container Runtime） ：节点的 “容器引擎”

  • 负责容器的实际创建和运行，是 K8s 与容器的 “接口”。
  • 支持的运行时包括：Docker、containerd、CRI-O 等（早期依赖 Docker，现在更推荐 containerd）。

‍

其他核心概念（支撑应用运行）

• ​Pod：K8s 的 “最小部署单元”

  • 一个 Pod 包含 1 个或多个紧密关联的容器，共享网络和存储（如一个应用容器 + 一个日志收集容器）。
  • Pod 是临时的，崩溃后会被重新创建，IP 会变化（需通过 Service 访问）。

• ​Service：Pod 的 “稳定访问入口”

  • 为一组相同功能的 Pod 分配固定 IP 和服务名（如my-service），实现 “Pod 动态变化但访问地址不变”。
  • 支持 ClusterIP（集群内访问）、NodePort（节点端口暴露）、LoadBalancer（云厂商负载均衡）等类型。

• ​Namespace：集群的 “资源隔离工具”

  • 将集群划分为多个独立的 “虚拟空间”（如default、kube-system），实现资源（CPU / 内存）和权限的隔离。
  • 常用于多团队共享集群时，避免资源冲突和配置干扰。

‍

1. 用户执行命令 kubectl create deployment nginx --image=nginx，请求发送到 kube-apiserver。
2. kube-apiserver 验证请求后，将 Deployment 配置存入 etcd。
3. kube-controller-manager（Deployment 控制器）发现 “期望状态”（1 个 Nginx 副本）与 “当前状态”（0 个）不一致，创建 ReplicaSet。
4. kube-scheduler 发现 ReplicaSet 对应的 Pod 未分配节点，根据调度策略选择一个 Worker 节点。
5. kube-apiserver 将 Pod 的 “节点分配信息” 存入 etcd，同时通知目标节点的 kubelet。
6. 目标节点的 kubelet 接收指令，调用容器运行时（如 containerd）拉取 Nginx 镜像、创建容器。
7. kubelet 定期向 kube-apiserver 汇报 Pod 状态，最终 etcd 更新 Pod 的 “运行状态”，整个部署完成

‍

Kubernetes特点

Kubernetes是一个开放的开发平台，它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以被映射为Kubernetes的Service（服务），并通过标准的TCP通信协议进行交互。此外，Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。

‍

Kubernetes作用

Kubernetes提供了完善的管理工具（开发、部署、测试、运维、监控）因此，Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式完备的分布式系统开发和支撑平台。

Kubernetes同时具有完备的集群管理能力：

1、故障自愈

2、服务发现与负载均衡

3、自动部署与回滚

4、自动伸缩（扩容与缩容）

‍

Kubernetes 的一些关键特性和用途：

1.容器编排

• 自动化部署：Kubernetes 可以自动化地部署应用程序容器，并通过滚动更新或回滚来管理应用的升级过程。
• 负载均衡：Kubernetes 可以自动将流量分配到多个容器实例，确保服务的高可用性和负载均衡。

2.扩展和管理

• 自动扩展：Kubernetes 可以根据资源使用情况自动扩展或缩减应用程序的实例数量，以适应流量或资源需求的变化。
• 自愈能力：如果某个容器或节点发生故障，Kubernetes 可以自动重启或重新调度容器，确保应用程序的持续运行。

3.存储管理

• 持久化存储：Kubernetes 支持多种存储解决方案，可以为应用程序提供持久化存储。
• 存储编排：Kubernetes 可以动态地为应用程序分配存储资源，并管理存储的生命周期。

4.服务发现和负载均衡

• 服务发现：Kubernetes 提供了内置的服务发现机制，使得不同的服务可以相互发现和通信。
• 负载均衡：Kubernetes 支持多种负载均衡策略，确保流量在多个容器实例之间均匀分布。

5.配置和密钥管理

• 配置管理：Kubernetes 允许用户通过配置文件或环境变量来管理应用程序的配置。
• 密钥管理：Kubernetes 提供了安全的密钥管理机制，用于存储和管理敏感信息， 如数据库密码或 API 密钥。

6.多环境支持

• 混合云和多云：Kubernetes 可以在不同的云环境（如 AWS、Azure、Google Cloud）和本地数据中心中运行，实现混合云和多云部署。
• 集群管理：Kubernetes 可以管理多个集群，允许用户跨多个集群部署和管理应用程序。

7.社区和生态系统

• 丰富的插件和扩展：Kubernetes 拥有一个庞大的社区和生态系统，提供了大量的插件和扩展，用于增强 Kubernetes 的功能。
• 持续演进：Kubernetes 是一个活跃的开源项目，不断引入新的特性和改进，以满足不断变化的容器化需求。

五、谁在用k8s

Kubernetes（K8s）已经成为容器编排领域的行业标准，许多大型企业和中小型公司都在使用它。以下是一些广泛使用 Kubernetes 的知名公司：

1.Google Google Kubernetes Engine (GKE)：Google 是 Kubernetes 的创始者之一，它的 GKE 是托管的 Kubernetes 服务，广泛用于管理和部署容器化应用。

2.Amazon Amazon Elastic Kubernetes Service (EKS)：Amazon 提供了一个托管的 Kubernetes 服务，EKS，帮助用户在 AWS 上轻松运行和管理 Kubernetes 集群。

3.Microsoft Azure Kubernetes Service (AKS)：Microsoft Azure 提供了 AKS，一个托管的 Kubernetes 服务，帮助用户在 Azure 云上部署、管理和扩展容器化应用。

4.IBM IBM Cloud Kubernetes Service：IBM 提供了一个托管的 Kubernetes 服务，帮助用户在 IBM Cloud 上运行和管理容器化应用。

5.Red Hat OpenShift：Red Hat 的 OpenShift 是一个企业级的 Kubernetes 平台，提供了额外的功能和集成，如 CI/CD、存储管理等。

6.阿里巴巴 Alibaba Cloud Container Service for Kubernetes (ACK)：阿里巴巴提供了 ACK，一个托管的 Kubernetes 服务，帮助用户在阿里云上管理容器化应用。

7.腾讯 Tencent Kubernetes Engine (TKE)：腾讯云提供了 TKE，一个托管的 Kubernetes 服务，帮助用户在腾讯云上部署和管理容器化应用。

8.Uber Uber 使用 Kubernetes 来管理其大规模的微服务架构，确保应用的高可用性和可扩展性。

9.eBay eBay 使用 Kubernetes 来管理和扩展其电子商务平台，提高应用的可靠性和性能。

10.GitHub GitHub 使用 Kubernetes 来管理其代码托管平台，确保应用的高性能和可扩展性。

K8s 与 Docker 的关系：

1. K8s 与 Docker 的关系：曾深度绑定，现松耦合

• ​早期依赖：Kubernetes 最初默认使用 Docker 作为容器运行时（因为 Docker 是当时最流行的容器引擎），但两者本质上是 “管理平台” 与 “底层工具” 的关系 ——K8s 负责编排，Docker 负责实际运行容器。
• ​现在的变化：2021 年后，Kubernetes 逐渐移除了对 Docker 的直接依赖（原因是 Docker 不符合 K8s 的容器运行时接口 CRI），转而通过​containerd（Docker 底层的容器运行时组件，后来被独立出来）与容器交互。
  简单说：现在用 K8s 时，即使你看到docker build构建镜像，实际在 K8s 集群中运行容器的可能是 containerd，而非完整的 Docker 引擎。

2. K8s 对容器技术的兼容性：标准化接口（CRI）

Kubernetes 通过容器运行时接口（CRI） 实现了对多种容器技术的支持，只要符合 CRI 标准，都可以作为 K8s 的底层容器引擎。常见的选项包括：

• ​containerd：最主流的选择（Docker 的核心组件，被独立后更轻量、稳定）。
• ​CRI-O：专门为 K8s 设计的轻量级容器运行时，完全符合 CRI。
• ​Docker：需通过cri-dockerd适配器转换（因为 Docker 原生不支持 CRI），现在较少直接使用。
• 其他：如 kata-containers（安全隔离容器）、gVisor（沙箱容器）等，适用于特定场景（如强安全需求）。

3. 镜像：依赖 OCI 标准，而非 Docker

容器镜像的格式也遵循​OCI（开放容器倡议）标准，Docker 镜像只是 OCI 镜像的一种实现。K8s 只要能拉取符合 OCI 标准的镜像，就能运行容器，无论镜像是用哪种工具构建的：

• 可以用docker build构建镜像，也可以用buildah、podman、kaniko（K8s 内构建镜像的工具）等。
• 镜像仓库也不局限于 Docker Hub，还可以是 Harbor、AWS ECR、阿里云 ACR 等，只要支持 OCI 镜像标准即可。

总结

• ​K8s 的核心是 “容器编排” ，专注于集群级的管理（调度、扩缩容、自愈等），不直接处理容器的创建 / 运行细节。
• 容器运行和镜像依赖的是​标准化接口（CRI/OCI） ，Docker 只是其中一种实现，现在更推荐轻量、符合标准的 containerd 等工具。
  也就是说，Docker 是 “可选工具” 而非 “必须依赖”，K8s 的生态已经实现了对容器技术的标准化兼容。

补充表格

组件归属	组件名称	核心角色	核心功能	故障影响（单组件）
控制平面	kube-apiserver	统一入口、通信枢纽	提供 RESTful API；处理所有请求；负责认证、授权；组件间数据交互中转。	集群完全不可操作，kubectl 命令、组件通信全部中断，无法部署或管理资源。
	etcd	集群数据库	存储集群所有核心数据（配置、状态、规则）；保证数据一致性和高可用。	集群数据丢失或不可读，无法获取 / 更新资源状态，严重时集群崩溃且难以恢复。
	kube-scheduler	调度员	监听未调度 Pod；根据资源需求、亲和性等规则，为 Pod 选择合适的 Worker 节点。	新 Pod 无法分配节点，停留在 “Pending” 状态；已运行的 Pod 不受影响。
	kube-controller-manager	控制器集合、状态守护者	运行多种控制器（如 ReplicaSet、Node）；确保集群状态与期望状态一致（重启 Pod、维持副本数）。	无法自动修复故障（如 Pod 崩溃后不重启）；副本数无法维持；节点故障后无法自动处理。
工作节点	kubelet	节点管理员	接收控制平面指令；创建 / 删除 Pod、启动容器；监控容器健康；汇报节点 / Pod 状态。	节点无法执行部署指令，Pod 无法在该节点创建 / 更新；控制平面无法获取节点状态。
	kube-proxy	网络代理、负载均衡器	维护节点网络规则；实现 Service 功能；转发请求到 Pod，提供负载均衡。	该节点上的 Pod 无法通过 Service 被访问；Pod 间通信可能中断；外部请求无法转发到 Pod。
	容器运行时（如 containerd）	容器引擎	拉取容器镜像；创建、启动、停止容器；管理容器生命周期。	节点上无法创建或运行容器，已运行容器可能异常退出；Pod 全部处于 “Error” 或 “CrashLoopBackOff” 状态。
核心概念	Pod	最小部署单元	封装 1 个或多个紧密关联的容器；共享网络、存储；作为资源分配的基本单位。	单个 Pod 故障仅影响其内部容器；若无副本机制，对应应用功能中断。
	Service	稳定访问入口	为 Pod 组分配固定 IP / 服务名；提供负载均衡；实现 Pod 动态变化下的访问稳定性。	无法通过固定地址访问 Pod；外部请求无法路由到应用；Pod 间通信需依赖 IP（不稳定）。
	Namespace	资源隔离工具	划分虚拟集群空间；隔离资源（CPU / 内存）、权限、配置；避免多团队资源冲突。	Namespace 本身故障极少，若配置错误可能导致资源访问权限异常、资源配额失效。

‍