云原生基础设施指南：精通 Kubernetes 核心与高级用法

1. 云原生的诞生

随着互联网规模的不断增长，以及企业对敏捷开发、快速交付和高可用性的需求日益增强，传统的单体架构逐渐暴露出局限性，难以满足现代业务对动态扩展和高效迭代的要求。为此，云原生应运而生。
云原生是为云计算时代量身打造的一种应用开发理念与技术体系，其目标是充分利用云计算的弹性、扩展性和自动化能力，帮助企业构建敏捷、高可用、弹性扩展的系统。传统架构在灵活性、扩展性和效率方面的不足，催生了云原生的诞生，而其核心技术——容器化、微服务架构、自动化部署等，彻底改变了软件开发和交付的方式。
值得注意的是，云原生并非简单地将传统应用“迁移到云上”，而是从设计之初就“为云而生”。它让开发流程更快、部署更敏捷、运维更高效，能够帮助企业充分发挥云计算的优势，如按需分配资源和动态扩展能力，从而快速响应市场变化。无论是科技巨头还是初创公司，都在通过云原生实现技术与业务的跨越式发展。
云原生不仅仅是一种技术，而是现代化应用开发的一种理念和方法论。它以容器化、微服务、DevOps 和自动化为核心，目的是充分利用云计算的弹性和高效性，帮助企业快速适应市场变化，提高开发效率和系统可靠性。

云原生的本质是：“为云而生”，拥抱云计算的动态性和分布式特性，以实现更敏捷、更可靠的软件交付。

学习云原生，让你掌握未来软件开发的核心技能，摆脱传统架构的束缚，成为技术浪潮中的先行者。这不仅是对技术的升级，更是对未来的投资。

2. 云原生概述

2.1 云原生核心要素

云原生主要由以下四个核心要素构成：

1. 微服务
   • 将单体应用拆分为多个小而独立的服务，支持独立开发和部署。
   • 提高了系统的灵活性和可扩展性。
2. 容器
   • 提供一致的运行环境，便于部署和迁移。
   • Docker 是容器化的代表工具。
3. DevOps
   • 通过文化、实践和工具，实现开发与运维的协作，缩短交付周期。
   • 强调自动化流程和持续监控。
4. 持续交付
   • 将软件的发布、部署等环节自动化，确保快速、安全的功能更新。
     

2.2 应用场景

云原生应用的实际应用场景有很多，以下是一些常见的例子：

微服务架构：云原生应用通常采用微服务架构，将应用程序划分为一组独立的服务，每个服务可以独立部署和扩展。这种架构使得应用程序更加灵活和可靠。

容器化：云原生应用通常使用容器技术进行部署，这使得应用程序可以轻松地在不同的环境中运行，无论是本地还是云环境。

持续集成和持续部署（CI/CD）：云原生应用通常采用CI/CD流程，可以实现自动化的代码构建、测试和部署，从而加快软件交付速度。

DevOps文化：云原生应用鼓励开发和运维团队密切合作，共同参与整个应用程序的生命周期。

自动化和可伸缩性：云原生应用通常具有高度的自动化和可伸缩性，可以根据需求自动扩展或缩减资源。

容错和高可用性：云原生应用通常设计为具有容错能力和高可用性，即使某个组件发生故障，整个应用程序也能继续运行。

云服务集成：云原生应用可以轻松地与云提供商提供的各种服务集成，例如数据库、消息队列、存储等。

3. Kubernetes的诞生

在云原生的四大要素中，无论是 微服务 的拆分与独立部署，容器 的标准化交付，还是 DevOps 的自动化流程以及 持续交付 所需的敏捷实践，都需要一种高度自动化、灵活扩展的基础设施支持。

云原生的核心是将应用程序设计成云环境的原生应用，即在系统设计之初，就考虑到应用程序将运行在云环境中，并以后不会脱离云环境独立运行！

正是在这种背景下，Kubernetes 应运而生。作为一个开源的容器编排平台，Kubernetes 专注于解决云原生应用在部署、扩展和管理上的复杂性。它通过自动化容器化应用的部署与运维，为开发者和运维人员提供了统一的工具，使云原生理念从理论走向了实践。

Kubernetes（K8s）是实现云原生架构的核心基础设施之一，也是云原生生态的基石。它负责管理容器化应用的部署、运行和扩展，与云原生理念紧密结合。

1. Kubernetes 是云原生的核心支柱

云原生的四个核心原则是 容器化、动态调度、服务网格 和 声明式 API。Kubernetes 通过其特性全面支持这些原则：

• 容器化：Kubernetes 管理和运行容器化的应用程序，如 Docker 容器。
• 动态调度：Kubernetes 自动将工作负载分配到最佳节点上，实现资源的高效利用。
• 服务网格：通过扩展组件（如 Istio）提供服务通信、监控和安全功能。
• 声明式 API：Kubernetes 使用声明式配置，让用户定义目标状态，Kubernetes 自动实现。

2. 云原生的基础设施

云原生应用需要一系列关键功能，比如服务发现、负载均衡、配置管理等。传统架构中，这些功能由独立的第三方组件提供，而在云原生中，这些功能往往由 Kubernetes 和云平台直接内置或扩展支持：

2.1 服务发现和负载均衡

• 传统方式：依赖 Nacos、Eureka 等服务发现工具和独立负载均衡器。
• Kubernetes 方式：通过 Service 和 Ingress 提供服务发现和负载均衡功能。
  • kube-dns 或 CoreDNS 实现服务名称解析。
  • Service 支持集群内的负载均衡。
  • Ingress 提供基于 HTTP/HTTPS 的外部访问路由。

2.2 配置和密钥管理

• 传统方式：依赖 Consul、Spring Cloud Config 等。
• Kubernetes 方式：
  • ConfigMap：用于存储和管理应用的配置信息。
  • Secret：用于存储敏感信息（如密码、密钥），并安全地挂载到容器。

2.3 弹性伸缩和自愈能力

• 传统方式：需要开发自定义的弹性扩展脚本和监控工具。
• Kubernetes 方式：
  • Horizontal Pod Autoscaler (HPA)：基于 CPU/内存使用率自动扩展 Pod。
  • Vertical Pod Autoscaler (VPA)：自动调整 Pod 的资源分配。
  • ReplicaSet 和 Deployment：保证所需的 Pod 数量运行，并在 Pod 失败时自动恢复。

2.4 日志和监控

• 传统方式：独立部署 ELK Stack 或 Prometheus。
• Kubernetes 方式：
  • 日志采集通过 Sidecar 容器或 Fluentd 集成。
  • 监控通过 Prometheus 和 Kubernetes 的 Metrics Server。

3. 云原生与 Kubernetes 的协作

Kubernetes 是云原生应用的运行和管理平台，它本身也支持云平台的特性。例如：

• 与云存储整合：Kubernetes 的 PersistentVolume 可以直接使用云服务（如 AWS S3、阿里云 OSS）。
• 与云负载均衡整合：Kubernetes 的 LoadBalancer 类型服务可以调用云平台的负载均衡器（如 ELB、SLB）。
• 与云安全整合：Kubernetes 支持使用云平台的密钥管理服务（如 AWS KMS、阿里云 KMS）。

4. Kubernetes 是云原生生态的基础

Kubernetes 是云原生计算基金会（CNCF）的核心项目，很多云原生工具和技术都是围绕 Kubernetes 构建的，比如：

• 服务网格：Istio、Linkerd
• 持续交付：ArgoCD、Flux
• 容器运行时：containerd、CRI-O
• 云原生存储：Rook、OpenEBS

通过 Kubernetes，这些工具可以更好地协同工作，为云原生应用提供全面的支持。

4.Kubernetes 核心架构

Kubernetes 采用控制平面（Control Plane） 和节点（Node） 的架构来协调资源管理和任务调度。

• 控制平面：
  控制平面是 Kubernetes 的“大脑”，负责管理集群的所有操作，包括资源分配、状态维护、调度和策略执行。主要组件包括：

  • API Server：集群的入口点，处理外部请求并分发至其他组件。
  • Scheduler：负责将 Pod 分配到合适的节点。
  • Controller Manager：维护集群的期望状态，例如处理副本数量、重启失败的 Pod。
  • etcd：保存所有集群数据的键值存储。

• 节点：
  节点是集群的执行单元，负责实际运行工作负载。每个节点上运行以下关键组件：

  • kubelet：与控制平面通信，接收指令并管理 Pod 生命周期。
  • kube-proxy：管理网络规则，处理服务之间的通信和负载均衡。
  • 容器运行时：例如 Docker 或 containerd，负责容器的运行。

详细的kubenetes核心架构介绍可以参考学习：kubernetes核心架构

5.Kubernetes核心概念

以下是 Kubernetes 的八个核心概念的介绍，并配合 YAML 文件展示如何定义和使用这些组件。

1 资源与对象

• 资源和对象的关系：
  • Kubernetes 中一切皆资源（类似于 Linux 一切皆文件，Java 一切皆对象）。
  • 对象是资源的实例，是持久化的实体，如具体的 Pod 或 Service。
  • 控制平面负责资源和对象的定义、调度和维护。
    • API Server 提供统一的入口，供用户通过 CLI 或编程接口创建、修改、删除资源对象。
    • Controller Manager 通过控制器调节实际状态与期望状态的差异。
  • 节点（Node）则是运行这些对象的执行环境。

2 对象规约与状态

• 规约（Spec）：
  • 描述对象的期望状态，是对象创建时的核心配置。
  • 控制平面通过调度器（Scheduler）解析规约，将资源分配给合适的节点。
• 状态（Status）：
  • 反映对象的实际运行状态，由 Kubernetes 自动维护。
  • 节点报告实际状态（如 Pod 的健康状况）给控制平面的 API Server，控制器根据差异做出调整。
  • 例如：如果 Pod 异常退出，控制器会通过节点反馈状态，启动新的 Pod 实例。

即：Spec是用户定义的期望状态，而Status则是系统维护的实际运行状态，控制平面持续调节Spec和Status，确保二者尽可能保持一致。

3 资源的分类

• 元空间（Metadata）： 是 Kubernetes 中每个资源的基础描述信息，包含名称（Name）、标签（Labels）、注解（Annotations）等，用于标识和管理资源。它是资源的“身份”和“注解”，便于查询、分类和操作。

• 集群（Cluster）： 是 Kubernetes 的运行环境，包含多个节点和控制平面组件。集群统一管理所有资源，并通过调度和自动化能力实现高效的应用部署与运行。

• 命名空间（Namespace）： 是集群内的逻辑隔离机制，用于将资源划分到不同的范围。它允许在一个集群中运行多个团队或项目，避免资源命名冲突并提供访问权限控制。

  • 用于对资源进行逻辑隔离。
  • 同一命名空间内的资源可以通信，跨命名空间则默认隔离。
  • 控制平面通过 API Server 管理命名空间的边界规则，确保隔离性。

4 Pod

• Pod 是 Kubernetes 的最小部署单元。
  • Pod 中的容器共享网络和存储。
  • 一个 Pod 通常包含一个容器，但也可以包含多个紧耦合的容器。
  • 节点是 Pod 的实际运行环境，kubelet 负责在节点上启动和管理 Pod 的生命周期。
• 副本（Replica）：
  • 基于 Pod 模板（PodTemplate）创建的多个实例，用于确保高可用性和负载分担。
  • 控制平面通过调度器决定将 Pod 副本部署到哪些节点。

下面给出一个yaml示例定义一个Pod

apiVersion: v1
kind: Pod
metadata:name: example-pod
spec:containers:- name: nginximage: nginx:1.21ports:- containerPort: 80

5 高级控制器

5.1 Deployment 和 ReplicaSet

• ReplicaSet
  • 确保指定数量的 Pod 副本始终运行。
  • 通过标签选择器（Label Selector）管理 Pod。
  • 控制平面通过 ReplicaSet 控制器动态调整副本数量。
• Deployment
  • 是 ReplicaSet 的封装，支持滚动更新和版本回滚。
  • 部署无状态应用的首选工具。
  • 控制平面负责管理滚动更新的步骤，节点则执行更新的具体操作。

下面给出一个yaml示例定义Deployment

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

5.2 StatefulSet

• 管理有状态应用。
  • 提供稳定的 Pod 标识、持久存储和有序部署。
  • 适合数据库等需要稳定网络标识的场景。
  • 控制平面确保 Pod 按预定义顺序启动或删除，节点负责提供持久化存储的挂载和网络连接。

下面给出一个yaml示例定义StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx # 必须匹配 .spec.template.metadata.labelsserviceName: "nginx"replicas: 3 # 默认值是 1minReadySeconds: 10 # 默认值是 0template:metadata:labels:app: nginx # 必须匹配 .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: registry.k8s.io/nginx-slim:0.24ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "my-storage-class"resources:requests:storage: 1Gi

5.3 DaemonSet

DaemonSet 是 Kubernetes 中的一种控制器，确保集群中每个节点（或指定节点）都运行一个特定的 Pod 副本。DaemonSet 常用于部署需要与每个节点交互的系统级服务，例如日志收集器（如 Fluentd）、监控代理（如 Prometheus Node Exporter）或网络组件（如 CNI 插件）。当有新节点加入集群时，DaemonSet 会自动在其上创建对应的 Pod 副本，确保服务的一致性和覆盖性。此外，DaemonSet 支持动态更新，通过滚动更新机制可以逐步替换所有节点上的 Pod 副本。

DaemonSet 的一些典型用法：

• 在每个节点上运行集群守护进程
• 在每个节点上运行日志收集守护进程
• 在每个节点上运行监控守护进程

下面给出一个yaml示例定义DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:name: fluentd-elasticsearchnamespace: kube-systemlabels:k8s-app: fluentd-logging
spec:selector:matchLabels:name: fluentd-elasticsearchtemplate:metadata:labels:name: fluentd-elasticsearchspec:tolerations:# 这些容忍度设置是为了让该守护进程集在控制平面节点上运行# 如果你不希望自己的控制平面节点运行 Pod，可以删除它们- key: node-role.kubernetes.io/control-planeoperator: Existseffect: NoSchedule- key: node-role.kubernetes.io/masteroperator: Existseffect: NoSchedulecontainers:- name: fluentd-elasticsearchimage: quay.io/fluentd_elasticsearch/fluentd:v2.5.2resources:limits:memory: 200Mirequests:cpu: 100mmemory: 200MivolumeMounts:- name: varlogmountPath: /var/log# 可能需要设置较高的优先级类以确保 DaemonSet Pod 可以抢占正在运行的 Pod# priorityClassName: importantterminationGracePeriodSeconds: 30volumes:- name: varloghostPath:path: /var/log

6. Job 和 CronJob

• Job：
  • 运行一次性任务，直至完成为止。适合任务型负载，如数据处理。
  • 控制平面负责调度任务，节点执行具体计算任务。

下面给出一个yaml示例定义Job

apiVersion: batch/v1
kind: Job
metadata:name: example-job
spec:template:spec:containers:- name: example-containerimage: busyboxcommand: ["echo", "Hello, Kubernetes!"]restartPolicy: Never

• CronJob：
  • 定时执行任务，类似于 Unix 的 crontab。用于周期性操作，如备份和报告生成。
  • 控制平面根据时间规则触发任务调度，节点按要求运行任务。

下面给出一个yaml示例定义CronJob

apiVersion: batch/v1
kind: CronJob
metadata:name: example-cronjob
spec:schedule: "*/1 * * * *"jobTemplate:spec:template:spec:containers:- name: example-containerimage: busyboxcommand: ["date"]restartPolicy: OnFailure

7. Service

• Service 是 Pod 的访问入口。
  • 提供服务发现和负载均衡功能。
  • 通过标签选择器管理 Pod，确保请求被分配到正确的实例。
  • 控制平面动态维护 Pod 的 Endpoint 列表，节点通过 kube-proxy 处理负载均衡和转发规则。

下面给出一个yaml示例定义Service

apiVersion: v1
kind: Service
metadata:name: example-service
spec:selector:app: exampleports:- protocol: TCPport: 80targetPort: 80

8. Ingress

• Ingress 是 HTTP(S) 路由的入口。
  • 定义外部请求如何访问集群内部的服务。
  • 需要与 Ingress Controller 配合使用，支持域名和路径路由规则。
  • 控制平面与 Ingress Controller 协同管理路由规则，节点实现流量转发至对应的 Service。

工作流程

1. 用户通过域名或路径发起请求。
2. Ingress Controller 拦截请求，根据定义的规则将其转发到相应的 Service。
3. Service 将请求路由到后端 Pod。
   

下面给出一个yaml示例定义Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: example-ingress
spec:rules:- host: example.comhttp:paths:- path: /pathType: Prefixbackend:service:name: example-serviceport:number: 80

9.数据卷

在 Kubernetes 中，ConfigMap、Downward API 和 Secret 是三种主要的配置和数据管理方式，帮助应用程序以灵活、安全和标准化的方式管理配置和运行时信息。

ConfigMap 用于存储非敏感的配置信息，例如应用程序的配置文件、环境变量或命令行参数。

特点

• 支持存储键值对或整个配置文件内容。
• 数据可通过环境变量、命令行参数或挂载为文件的方式供 Pod 使用。
• 非加密，适用于非敏感数据。

Downward API 提供运行时信息（如 Pod 名称、Namespace、资源请求限制等）给容器使用。

特点

• 提供关于 Pod 和容器的元信息。
• 通过环境变量或挂载为文件供 Pod 使用。
• 无需事先创建对象，直接基于 Pod 元数据。

Secret 用于存储敏感信息，例如密码、API 密钥或证书。

特点

• 数据加密存储于 etcd 中（Base64 编码，非真正加密）。
• 提供更高的安全性，适用于敏感信息。
• 数据可通过环境变量或挂载为文件供 Pod 使用。

云原生通过微服务、容器、DevOps 和持续交付实现敏捷开发和稳定运行，Kubernetes 是实现这一目标的核心技术。通过了解 Kubernetes 的资源模型、控制器和网络组件，可以帮助企业构建高效、灵活和可扩展的云原生应用。