Kubernetes基本概念

一.认识 Kubernetes

1.1.什么是 Kubernetes

Kubernetes（简称K8s）是一个开源的容器编排平台，旨在自动化应用程序的部署、扩展和管理。该平台由Google基于其在大规模生产环境中运行工作负载超过十年的经验设计，并于2014年捐赠给了云原生计算基金会（CNCF）。Kubernetes的名字源自希腊语，意为“舵手”，而“k8s”这个缩写是因为字母“k”和“s”之间有八个字符的关系。它提供了一整套机制来简化部署容器化应用的过程，使其既简单又高效。

1.2.为什么需要 Kubernetes

• 传统方法的问题：过去，程序员或运维工程师手动操作来部署应用，直接将应用部署在目标机器上，这种方式由于资源不隔离，容易出现资源争抢、依赖冲突等问题。
• 虚拟化技术的局限性：随后，OpenStack/VMware等虚拟化技术实现了资源隔离和一定程度上的自动化管理，但每个虚拟机都需要自己的操作系统副本，导致效率不高且耗费更多资源。
• 容器化解决方案的优势：相比之下，容器化技术通过命名空间和控制组等技术实现资源隔离，损耗更小、效率更高。Kubernetes不仅解决了容器的部署难题，还提供了强大的自动化工具来简化复杂的工作流程。

1.3.Kubernetes的特点

• 自我修复

• 自动重启失败的容器。
• 替换和重新调度容器。
• 处理不可用的容器。

• 弹性伸缩

• 根据CPU使用率或其他自定义度量标准进行手动或自动扩展。
• 快速响应流量变化，确保服务稳定性和资源的有效利用。

• 自动部署和回滚

• 支持滚动更新模式，在不影响现有服务的情况下逐步部署新版本的应用程序。
• 若新版本出现问题，可以轻松回滚到之前的稳定版本，减少对业务的影响。

• 服务发现和负载均衡

• 内置的服务发现机制无需额外配置即可让服务之间互相找到对方。
• 集成的负载均衡器为每个服务提供一个唯一的DNS名称，并在多个实例间分配网络流量。

• 机密和配置管理

• 安全地存储敏感信息，如密码、OAuth令牌等，避免硬编码到镜像中。
• 提供灵活的配置选项，允许管理员定义环境变量或配置文件，便于动态调整应用的行为。

• 存储编排

• 自动挂载各种存储系统，包括本地存储、公有云提供商提供的存储以及网络存储。
• 即使容器停止运行，数据也不会丢失，因为数据被保存在持久化的存储卷中。

• 批处理

• 支持一次性或周期性的批处理作业。
• 根据集群资源情况智能地安排批处理任务的执行顺序和位置，最大化资源利用率。

1.4.企业级容器调度平台比较

• Apache Mesos

• 基本概念：分布式资源管理系统，早于Docker出现，作为数据中心操作系统的一部分提供资源管理。
• 优势：

• 成熟稳定，支持多种工作负载。
• 健康检查与开放架构。
• 能够支持超大型集群环境。

• 缺点：

• 学习曲线较陡峭。
• 社区活跃度较低。
• 用户界面不够友好。

• Docker Swarm

• 基本概念：Docker开发的原生集群管理和容器编排工具，默认包含于Docker引擎中。
• 优势：

• 无缝集成，配置简便。
• 易于上手，适合熟悉Docker CLI的用户。
• 提供内置功能，适合中小型系统的快速部署和管理。

• 缺点：

• 扩展性和灵活性有限。
• 生态系统较小。
• 缺乏一些高级功能。

• Google Kubernetes

• 基本概念：源于Google多年在生产环境中运行大规模工作负载的经验，使用Label和Pod的概念来将容器划分为逻辑单元。
• 优势：

• 最流行的容器编排解决方案，广泛应用于各种规模的企业。
• 解决复杂问题能力强，提供灵活的服务定义方式。
• 功能性和灵活性使其成为大多数应用场景的理想选择。

• 缺点：

• 学习成本较高。
• 对小型项目来说可能显得过于重量级。
• 设置和维护复杂。

二.组件

2.1.控制平面组件（Master）

控制平面负责集群的全局决策和状态管理，需部署在高可用环境中以保障稳定性。

• kube-apiserver

• 核心作用：Kubernetes 集群的“中央枢纽”，暴露 RESTful API 供用户、命令行工具及其他组件交互。
• 关键特性：

• 唯一直接与 etcd 通信的组件，确保状态一致性。
• 支持水平扩展，可通过部署多个实例分散请求负载（如 API 请求量大的场景）。

• 生产建议：启用 HTTPS 认证与 RBAC 权限控制保障安全性。

• kube-controller-manager

• 核心作用：运行所有内置控制器，持续监控集群状态并驱动其向期望状态收敛。
• 主要控制器类型：

• cloud-controller-manager

• 核心作用：对接云厂商 API，实现与云平台基础设施的交互（如负载均衡器、存储卷）。
• 适用场景：仅在公有云（AWS/Azure/GCP）或混合云环境中部署，本地集群无需此组件。
• 典型功能：

• 自动创建云负载均衡器（对应 Kubernetes Service 类型为 LoadBalancer）。
• 管理云存储卷的动态供给（如 AWS EBS、Azure Disk）。

• kube-scheduler

• 核心作用：为新建的 Pod 分配最佳运行节点，决策基于资源需求、亲和性策略等。
• 调度策略维度：

• 资源维度：节点 CPU/内存剩余量是否满足 Pod 请求。
• 拓扑维度：Pod 亲和性（如将同类服务分散在不同可用区）或反亲和性规则。
• 自定义规则：通过调度器扩展（Scheduler Framework）实现业务特定需求。

• etcd

• 核心作用：分布式键值数据库，存储集群所有配置数据（如 Pod、Service、Secret）。
• 关键特性：

• 基于 Raft 协议实现强一致性，需部署奇数个节点（如 3/5）以容忍故障。
• 数据持久化存储，需定期备份并监控磁盘 I/O 性能（高写入负载可能成为瓶颈）。

• 生产建议：与 APIServer 分离部署，避免资源竞争。

2.2.节点组件（Node）

工作节点负责运行容器化应用，每个节点需安装以下核心组件：

• kubelet

• 核心作用：节点上的“代理”，接收来自 APIServer 的指令并管理 Pod 生命周期。
• 关键职责：

• 挂载存储卷（Volume）到 Pod 容器内。
• 调用容器运行时（如 containerd）创建/销毁容器。
• 定期向 APIServer 报告节点状态（心跳机制）。

• kube-proxy

• 核心作用：实现 Service 的虚拟 IP（ClusterIP）和负载均衡。
• 底层技术：

• iptables 模式：通过规则链转发流量（默认方式，适合小规模集群）。
• IPVS 模式：基于内核级负载均衡，性能更高（推荐用于大规模集群）。

• 容器运行时（Container Runtime）

• 核心作用：执行容器镜像的拉取、解压及进程隔离（依赖 Linux 内核特性如 cgroups/namespace）。
• 常见实现：

• containerd：Docker 剥离后的轻量级运行时，Kubernetes 默认选择。
• CRI-O：专为 Kubernetes 设计的 OCI 兼容运行时，资源占用更低。

2.3.附加组件（Addons）

扩展 Kubernetes 功能的非核心组件，按需部署以增强集群能力。

• kube-dns/CoreDNS

• 功能：为 Service 和 Pod 提供集群内 DNS 解析（如 my-svc.default.svc.cluster.local）。
• 演进：Kubernetes 1.12+ 默认使用 CoreDNS 替代 kube-dns，支持更灵活的插件配置。

• Ingress Controller

• 功能：通过 Ingress 资源定义 HTTP/HTTPS 路由规则，暴露服务至集群外部。
• 常见实现：Nginx Ingress、Traefik、AWS ALB Ingress Controller。

• Prometheus + Grafana

• 功能：监控集群资源（CPU/内存/磁盘）及应用指标，可视化展示实时状态。
• 数据采集：通过 kube-state-metrics 获取 Kubernetes 对象状态，node-exporter 采集节点指标。

• Dashboard

• 功能：Web 管理界面，可视化操作 Pod、Deployment 等资源（生产环境建议限制访问权限）。

• Fluentd + Elasticsearch + Kibana（EFK）

• 功能：采集容器日志，集中存储至 Elasticsearch 并通过 Kibana 进行查询分析。

• Federation

• 功能：管理跨多个 Kubernetes 集群的联邦服务（如跨可用区部署全局服务）。
• 典型场景：混合云环境中统一调度多地资源。

三.分层架构

Kubernetes 采用分层设计理念，各层级通过标准接口解耦，形成高度可扩展的云原生操作系统架构。

3.1.架构全景图示意

[外部生态工具] ↔ [接口层(kubectl/SDK)]  
                      ↓  
[管理层(HPA/策略)] → [核心层(API引擎)] ← [插件环境(CRI/CNI)]  
                      ↓  
[应用层(Deployment/Service)] → [工作节点(Pod/容器)]  

3.2.生态系统层（Ecosystem）

Kubernetes 的开放性催生了丰富的工具链和解决方案，形成了两大生态圈：

• 外部扩展生态

• 典型组件/服务：

• 可观测性：Prometheus（监控）、EFK（日志）
• CI/CD：Jenkins、Argo Workflow
• Serverless：Knative、OpenFaaS

• 与 Kubernetes 的集成方式：通过 Operator 或 CRD 扩展 API 资源

• 内部核心生态

• 典型组件/服务：

• 容器运行时：containerd（CRI）
• 网络插件：Calico（CNI）
• 云厂商适配：AWS EBS CSI Driver（存储）

• 与 Kubernetes 的集成方式：实现 Kubernetes 标准接口（如 CRI/CNI/CSI）

• 设计哲学：

• 控制反转（IoC）：Kubernetes 定义接口规范（如 CRI、CSI），生态组件按需实现。
• 声明式 API 驱动：通过 Custom Resource Definition (CRD) 集成第三方能力（如 Istio 的 VirtualService）。

3.3.接口层（Interface Layer）

作为用户与集群的交互入口，提供多维度控制平面：

• 命令行工具（kubectl）

• 核心功能：通过 REST API 管理集群资源（增删改查、调试、端口转发）。
• 高级技巧：

• kubectl --dry-run=client -o yaml：生成资源配置模板。
• kubectl explain：查看资源字段的文档描述。

• 客户端 SDK

• 官方 SDK：client-go（Go 语言库，控制器开发基础）。
• 多语言支持：

• Java：Fabric8 Kubernetes Client
• Python：kubernetes-client

• 用途：用于开发自定义控制器或运维工具。

• 集群联邦（Federation）

• 场景：跨集群部署同一应用（如全球多区域服务）。
• 实现方案：

• KubeFed：统一管理多个集群的资源配置（如 Deployment 同步）。
• 多集群 Service：通过 Submariner 实现跨集群服务发现。

3.4.管理层（Control Layer）

通过自动化与策略引擎保障集群稳定运行：

3.5.应用层（Application Layer）

标准化应用部署模型与流量治理能力：

• 部署模式

• 服务路由

服务发现：

• ClusterIP Service 提供内部 DNS 名称（..svc.cluster.local）。
• Headless Service 用于 StatefulSet 的 Pod 直接访问（如 MongoDB 分片）。

流量治理：

• Ingress 定义 HTTP 路由规则（路径重写、TLS 终止）。
• Service Mesh（如 Istio）实现灰度发布、熔断等高级路由策略。

3.6.核心层（Core Layer）

Kubernetes 的引擎内核，提供两大核心能力：

• 声明式 API 引擎

• 资源模型：通过 APIServer 暴露 Pod、Service 等 API 对象。
• 控制器模式：

• 监听 API 对象变更事件（如 Deployment 扩缩容）。
• 协调实际状态与期望状态的一致性（Reconciliation Loop）。

• 插件式运行时环境

• 扩展机制：

• CRD：自定义资源类型（如定义 RedisCluster 对象）。
• Operator：将运维知识编码为控制器逻辑（如自动化 Redis 故障恢复）。

• 多运行时支持：

• 容器运行时（containerd）
• 沙箱容器（Kata Containers）
• 虚拟机（KubeVirt）

四.服务分类

在 Kubernetes 环境中，服务通常被分为两大类：无状态服务和有状态服务。理解这两种服务类型及其特性对于设计高效、可靠的系统至关重要。

4.1.无状态服务

• 定义：
  无状态服务指的是不依赖于任何特定的服务实例来存储客户端上下文或数据的服务。每次请求对于服务来说都是独立且相同的处理流程。
• 代表应用：
  Nginx、Apache等。
• 优点：

• 对客户端透明，服务实例之间没有依赖关系，易于实现水平扩展。
• 可以灵活地进行服务迁移和扩容，提高了系统的灵活性和可用性。

• 缺点：

• 由于不能直接存储数据，因此需要额外的数据服务（如数据库、缓存）来支持数据持久化需求。

4.2.有状态服务

• 定义：
  有状态服务是指那些需要保存客户端状态或数据的服务，这类服务通常涉及到数据的持久化存储和管理。
• 代表应用：
  MySQL、Redis等。
• 优点：

• 能够直接存储和管理数据，为应用提供稳定的数据支撑。
• 提供了对数据的控制能力，比如备份、恢复等操作，有利于数据的安全性和完整性。

• 缺点：

• 在集群环境中，实现高可用性（如主从复制）、数据同步、以及数据备份和恢复等操作相对复杂。
• 水平扩展（如增加新的节点）时，需要特别考虑数据一致性和同步问题，增加了技术难度和维护成本。

五.资源分类

在 Kubernetes 中，资源可以根据其作用和范围分为多个类别。理解这些资源类型有助于更好地设计和管理Kubernetes集群。

5.1.元数据型资源

• Horizontal Pod Autoscaler (HPA)

• 功能：根据CPU使用率或自定义指标自动调整Pod的数量。
• 工作机制：控制管理器每隔30秒（可通过参数--horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况。
• 支持的度量类型：

• 预定义度量（如Pod的CPU），以利用率的方式计算。
• 自定义的Pod度量，以原始值方式计算。
• 自定义的对象度量。

• 度量获取方式：通过Metrics Server（Heapster已被弃用）或自定义REST API实现。
• 特点：支持基于多个度量进行扩展决策，提供更灵活的自动扩展能力。

• PodTemplate

• 描述：Pod模板是关于Pod的定义，但通常被包含在其他Kubernetes对象中（例如Deployment、StatefulSet）。控制器使用Pod Template信息来创建Pod实例。

• LimitRange

• 功能：可以对集群内Request和Limits配置做全局统一限制，适用于批量设置某个命名空间内的Pod资源使用限制。这有助于确保资源使用的合理性和一致性。

5.2.集群级资源

• Namespace

• 描述：Kubernetes支持通过命名空间实现多团队或多环境间的资源隔离。每个命名空间都是独立的工作区，默认情况下存在以下命名空间：

• kube-system: 主要用于运行系统组件。
• kube-public: 可供所有用户访问，主要用于集群级别的公开资源。
• default: 如果未指定命名空间，则默认使用此命名空间。

• Node

• 描述：Node不是由Kubernetes创建的，而是由它管理的物理或虚拟机器。虽然可以通过Manifest文件描述一个Node对象，但其实际的存在需由Kubernetes验证确认。

• ClusterRole & ClusterRoleBinding

• ClusterRole: 定义一组权限集合，适用于整个集群的所有命名空间及非命名空间资源。
• ClusterRoleBinding: 将主体绑定到特定的ClusterRole上，使规则在整个集群范围内生效。

5.3.命名空间级资源

• 服务发现与暴露

• Service: Service是将一组Pod抽象为网络服务的方法，提供了一个稳定的IP地址和DNS名称，使得这些Pod可以被外部或者内部的服务所访问。
• Ingress: Ingress提供了从集群外部访问集群内部服务的能力，通过HTTP/HTTPS路由规则将请求转发给相应的Service。需要配合Ingress Controller一起使用才能发挥作用。

• 存储

• Volume: 提供了跨Pod生命周期的数据持久化解决方案。
• CSI (Container Storage Interface): CSI是一个标准化接口，允许不同存储系统更容易地集成到Kubernetes中。

• 特殊配置类型

• ConfigMap: 存储非敏感配置信息，便于动态更新应用程序配置而不必重启容器。
• Secret: 安全地存储敏感信息，如密码、密钥等，避免直接暴露在镜像或Pod Spec中。
• DownwardAPI: 让Pod内的容器能够直接访问Pod自身的元数据，提供两种主要注入方式：环境变量和volume挂载。

• 其他

• Role: Role是一组权限的集合，例如它可以包含列出Pod、创建Deployment等权限。Role用于在特定命名空间内对资源进行鉴权。
• RoleBinding: RoleBinding将主体（Subject）绑定到Role上，使得该Role定义的规则在指定的命名空间内生效。主体可以是用户、组或其他Kubernetes服务账户。

5.4.资源清单

所有Kubernetes对象都通过YAML文件定义其配置，包括对象的期望状态（Spec）、标签选择器、副本数等关键信息。通过这种方式，可以方便地管理和部署应用及其依赖项。这种机制不仅增强了系统的灵活性，还简化了应用的维护和升级过程。

六.Pod

Pod（容器组）是Kubernetes中最小的可部署单元。一个Pod包含了一个或多个应用程序容器、存储资源、唯一的网络IP地址以及一些确定容器如何运行的选项。Pod代表了Kubernetes中的一个独立应用实例，可以由单个容器或者几个紧密耦合的容器组成。Docker是Kubernetes中最常用的容器引擎，但Kubernetes也支持其他类型的容器引擎。

Kubernetes集群中的Pod使用途径：

• 单容器Pod：最常见的使用方式是一个Pod中只运行一个容器。此时，Pod充当容器的“包装器”，Kubernetes通过管理Pod间接管理容器。
• 多容器Pod：在某些情况下，一个Pod可以包含多个需要紧密协作的容器。这些容器共享存储和网络资源，并且始终一起调度。

6.1.副本（Replicas）

副本概念是指一个Pod可以被复制成多份，每一份称为一个“副本”。除了描述信息（如Pod的名字、UID等）不同外，其余信息均相同，包括内部容器、容器数量及其运行的应用程序。这些副本提供相同的功能。

Pod的控制器通常包含一个名为replicas的属性，用于指定特定Pod应具有的副本数量。当集群中该Pod的实际数量与replicas值不一致时，Kubernetes会采取措施使实际状态符合配置要求。

6.2.适用于无状态服务

• ReplicationController (RC): RC是确保任意时间点上运行的Pod副本数量保持不变的核心概念之一。如果实际Pod数量超过设定值，则多余的会被终止；若少于设定值，则会启动新的Pod来补充。RC保证了Pod的高可用性。
• ReplicaSet (RS): RS取代了RC，其主要作用是维持容器应用的副本数。RS与RC相似，但它支持更灵活的选择器（selector），允许基于集合进行选择。

• Label 和 Selector: Label是附加到Kubernetes对象上的键值对，用于标识对象。Selector则用于根据label过滤对象，实现细粒度的资源管理和查找。

• Deployment: Deployment不仅创建ReplicaSet/Pod，还提供了滚动更新/回滚、平滑扩容和缩容、暂停与恢复等功能。

6.3.适用于有状态服务

StatefulSet为每个Pod分配一个稳定的DNS名称和持久化存储，适用于需要保持状态的服务。

特点:

• 稳定的持久化存储
• 稳定的网络标志
• 有序部署和扩展
• 有序收缩和删除

组成:

• Headless Service用于定义网络标志
• volumeClaimTemplate用于创建PersistentVolumes

6.4.守护进程

DaemonSet确保每个Node上都运行一个容器副本，常用于日志收集、系统监控等场景。

6.5.任务/定时任务

• Job: 一次性任务，完成后Pod销毁。
• CronJob: 在Job基础上增加了定时功能。

七.对象规约和状态

理解Kubernetes中的对象规约（Spec）和状态（Status）对于有效管理集群资源至关重要。这两个概念帮助定义和监控集群内各个组件的期望与实际状态。

7.1.规约（Spec）

• 定义：
  "spec"（规约）是Kubernetes对象的核心部分，它详细描述了对象的期望状态（Desired State）。这包括但不限于对象的功能特性、配置参数以及其预期的行为模式。
• 重要性：
  在创建任何Kubernetes对象时，必须提供该对象的规约。通过spec，您可以明确指定您希望对象具有的属性和行为。例如，对于一个Pod对象，spec可以定义容器镜像、环境变量、端口映射等信息。正确设置spec有助于确保您的应用程序按照预期运行，并能够根据需要进行扩展或更新。

7.2.状态（Status）

• 定义：
  "status"（状态）表示对象的实际状态，这个属性由Kubernetes系统自动维护，反映了对象当前在集群中的真实状况。
• 功能：
  Kubernetes控制器会持续监控对象的状态，并尝试根据对象的spec来调整其实际状态，以确保两者尽可能一致。这意味着，如果对象的实际状态偏离了其期望状态，Kubernetes将采取措施进行修正，比如重启失败的容器或重新调度Pod。
• 内容：
  Status通常包含有关对象健康状况的信息，如可用的副本数量、资源使用情况、错误消息等。这些信息对于诊断问题和理解集群运行状况非常重要。通过监控状态，运维人员可以快速识别并解决潜在的问题，确保应用的高可用性和性能。