Kubernetes介绍

墨颜丶2022-07-182025-04-15

k8s概述和特性

发音

有很多人不知道kubernetes应该怎么发音，正确的发音是[kubə’netis]，重音在第三个音节，读音：库伯耐踢死

那为什么很多场景称为是 k8s呢？

这个其实和硅谷的人起名有关系，他们有一个坏习惯，就是喜欢把一个单词首字母+跳过的字母数来进行缩写，比如亚马逊的Algorithms被缩写成A9，而kubernetes缩写为k8s，意思就是k后面跳过8个字母后到s，就变成了k8s。

概述

1. 什么是 Kubernetes？

定义：
Kubernetes 是一个开源的 容器编排平台，用于自动化部署、扩展和管理容器化应用。
由 Google 基于其内部系统 Borg 的经验设计，2014 年开源并捐赠给 CNCF（云原生计算基金会）。
核心目标：
- 自动化运维：简化容器化应用的部署、扩缩容、故障恢复等操作。
- 跨环境一致性：提供一致的运行环境（开发、测试、生产）。
- 资源高效利用：优化计算、存储、网络资源的分配与调度。

2. Kubernetes 解决了什么问题？

容器化应用的挑战：
- 编排困难：手动管理成百上千的容器（启动顺序、依赖关系、网络通信）。
- 高可用性：容器故障时需自动恢复，避免服务中断。
- 动态扩缩容：根据流量自动调整应用实例数量。
- 跨环境迁移：开发环境与生产环境配置差异导致部署问题。
传统运维的局限性：
- 人工操作易出错，难以应对微服务架构的复杂性。
- 虚拟机资源利用率低，启动速度慢。

3. Kubernetes 核心设计思想

声明式 API（Declarative API）：
- 用户通过 YAML/JSON 声明“期望状态”（如运行 3 个副本），k8s 自动驱动系统达到该状态。
- 与“命令式”（手动一步步执行）形成对比，更适应动态变化的环境。
控制循环（Control Loop）：
- 持续监控系统状态，通过控制器（Controller）不断调整实际状态，直到与期望状态一致。
- 例如：Deployment 控制器确保 Pod 副本数符合预期。
松耦合架构：
- 组件模块化设计，可替换或扩展（如替换容器运行时、自定义调度器）。
- 通过标准接口（如 CRI、CSI）支持多种插件。

4. Kubernetes 核心特性

特性	说明	典型场景
自动化部署与回滚	支持滚动更新、蓝绿发布、金丝雀发布，并可一键回滚到历史版本。	持续交付（CI/CD）
服务发现与负载均衡	通过 Service 和 DNS 自动暴露服务，流量均匀分发到后端 Pod。	微服务间通信
存储编排	动态挂载持久化存储（如本地磁盘、云存储），支持有状态应用。	数据库（MySQL）、消息队列（Kafka）
弹性伸缩	水平扩缩（HPA）基于 CPU/内存或自定义指标；集群节点自动扩缩（Cluster Autoscaler）。	应对突发流量
自我修复	自动重启失败的容器、替换不可用节点、杀死不健康的 Pod。	保障服务 SLA
密钥与配置管理	通过 ConfigMap 和 Secret 管理配置与敏感信息，支持动态注入。	不同环境（开发/生产）配置分离
批处理任务	支持一次性任务（Job）和定时任务（CronJob）。	数据备份、报表生成

5. Kubernetes 的适用场景

适合场景：
- 微服务架构：管理大量松散耦合的服务。
- CI/CD 流水线：与 Jenkins、GitLab 集成实现自动化部署。
- 混合云/多云部署：统一管理跨云厂商的资源。
- 机器学习与批处理：运行 TensorFlow 训练任务或 Spark 批处理作业。
不适用场景：
- 单机简单应用（直接使用 Docker 即可）。
- 对实时性要求极高的场景（如高频交易系统）。

6. Kubernetes 的优缺点

优点	缺点
自动化运维，降低人工干预	学习曲线陡峭，概念复杂（Pod、Service 等）
高可用性和故障自愈能力	初始部署和配置复杂（尤其生产环境）
灵活的扩展机制（CRD、Operator）	资源消耗较高（Master 节点需要一定配置）
庞大的生态系统（Helm、Istio 等）	网络和存储配置对底层设施依赖较强

k8s架构组件

Master组件

API Server
- API Server是Kubernetes控制程序的前端。
- 唯一与etcd交互的组件，提供RESTful API。
- 集群的统一入口，以RESTful API方式提供集群管理功能，交给etcd存储。
- 支持认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）。
etcd
- 键值存储（也称为etcd）是Kubernetes用来备份所有集群数据的数据库
- 它存储集群的整个配置和状态。主节点查询etcd以检索节点，容器和容器的状态参数。
Controller Manager
- 控制器的作用是从API Server获得所需状态
- 它检查要控制的节点的当前状态，确定是否与所需状态存在任何差异，并解决它们（如果有）。
Scheduler
- 调度程序会监视来自API Server的新请求，并将其分配给运行状况良好的节点
- 它对节点的质量进行排名，并将Pod部署到最适合的节点
- 如果没有合适的节点，则将Pod置于挂起状态，直到出现合适的节点。

Worker节点组件

kubelet
- 管理Pod生命周期（创建、销毁）、上报节点状态。
- 与容器运行时（如containerd）交互。
- 它监视从API Server发送来的任务，执行任务，并报告给主节点
kube-proxy
- 确保每个节点都获得其IP地址，维护节点网络规则（iptables/IPVS），实现Service的负载均衡。
Container Runtime
- 容器运行时从容器镜像库中拉取镜像，然后启动和停止容器
- 容器运行时由第三方软件或插件，如Docker、containerd、CRI-O等（通过CRI接口）。

Kubernetes 应用部署流程

用户通过 kubectl apply 提交 YAML/JSON 清单到 API Server，API Server 验证资源合法性后，将对象状态写入 etcd
控制器（Controller）通过etcd注意到新创建的对象并创建多个新对象-每个对象对应一个应用程序实例
调度器（Scheduler）为每个实例分配一个节点，将节点信息绑定到 Pod 并更新到 etcd
Kubelet 注意到一个实例被分配给了 Kubelet 的节点。它通过容器运行时（Container Runtime）运行应用程序实例
Kube-proxy注意到应用程序实例已准备好接受来自客户端的连接并为他们配置网络，负载均衡等
Kubelet 和 Controller 监控系统并保持应用程序运行

k8s核心概念

Pod

定义与作用

最小部署单元：Pod 是 Kubernetes 中最小的可调度和可部署的单位，包含一个或多个共享资源（如网络、存储）的容器。
共享资源：
- 网络：所有容器共享同一个 IP 地址和端口空间（通过 localhost 通信）。
- 存储：容器可以共享存储卷（如 emptyDir、PersistentVolume）。
- 生命周期：Pod 内的容器要么同时启动，要么同时终止。
短暂性：Pod 是短暂的，可能因节点故障、资源不足或控制器操作而被销毁并重新创建。

典型场景

单容器 Pod：运行一个简单的应用（如 Nginx）。
多容器 Pod：运行主应用容器和辅助容器（如日志收集工具）。

控制器（Controller）是一系列管理Pod生命周期的对象。它们根据用户定义的状态自动调整实际状态，确保集群的实际状态与期望状态保持一致。

Controller

常见控制器类型

Deployment：用于管理无状态应用的更新和扩展，支持滚动更新和回滚。
ReplicaSet：确保任何时间都有指定数量的Pod副本处于运行状态。
DaemonSet：保证所有（或一些）节点运行一个Pod的副本，常用于日志收集、监控等场景。
StatefulSet：用于管理有状态应用，提供有序部署、扩展和更新的能力。
Job/CronJob：用于执行一次性任务或周期性任务。

定义与作用

控制器：如 Deployment 是 Kubernetes 的控制器，用于声明式管理 Pod 的副本，确保集群中始终运行指定数量的 Pod 副本。
核心功能：
- 滚动更新：逐步替换旧 Pod 为新 Pod（如升级镜像版本），避免服务中断。
- 回滚：在更新失败时快速回滚到之前版本。
- 扩缩容：动态调整 Pod 副本数量（如应对流量高峰）。
- 自愈能力：自动替换失败的 Pod。
依赖 ReplicaSet：Deployment 通过 ReplicaSet 管理 Pod 副本，确保副本数量符合预期。

典型场景

部署无状态应用（如 Web 服务、API 服务）。
需要自动更新和回滚的场景。

Service

定义与作用

服务（Service）是一种抽象方式，用于定义一组逻辑Pod及其访问策略。通过服务，您可以为一组Pod提供一个稳定的IP地址和DNS名称，使得这些Pod可以被其他组件或外部客户端访问。

核心功能：

服务发现：通过虚拟 IP（ClusterIP）和 DNS 名称让 Pod 之间互相通信。
负载均衡：将请求分发到后端 Pod（如 ClusterIP、NodePort、LoadBalancer 类型）。
抽象后端 Pod 变化：即使后端 Pod 的 IP 地址变化（如滚动更新），Service 的 IP 和 DNS 保持稳定。

服务类型

ClusterIP：默认类型，仅在集群内部可访问。
NodePort：通过在每个节点的IP上开放特定端口使外部流量可以访问到该服务。
LoadBalancer：使用云提供商的负载均衡器将外部流量分配给各个节点上的服务。
ExternalName：通过返回CNAME记录将服务映射到外部资源。

典型场景

内部服务间通信（如前端调用后端 API）。

对外暴露应用（如通过 NodePort 或 LoadBalancer）。

三者的区别与协作关系

特性	Pod	Deployment	Service
作用	运行容器的最小单元	管理 Pod 副本，实现自动扩缩容和更新	提供稳定网络访问，负载均衡和发现
生命周期	短暂（可被销毁和重建）	长期存在，管理 Pod 的生命周期	长期存在，抽象后端 Pod 的变化
是否管理多个实例	单个实例（一组容器）	管理多个 Pod 副本	通过标签选择一组 Pod
更新方式	直接删除并重建	通过滚动更新逐步替换 Pod	不直接管理 Pod，仅关注网络暴露
典型用途	运行单个或多个容器	部署和管理无状态应用	连接不同组件，暴露服务

协作关系

Deployment 管理 Pod：
- Deployment 定义 Pod 的模板（如镜像、端口、环境变量），并通过 ReplicaSet 确保指定数量的 Pod 副本始终运行。
- 当更新 Deployment 时（如镜像版本升级），会创建新 Pod 并逐步替换旧 Pod。
Service 暴露 Pod：
- Service 通过标签选择器（selector）关联一组 Pod（例如，由 Deployment 管理的 Pod）。
- Service 为这些 Pod 提供一个稳定的虚拟 IP 和 DNS 名称，实现负载均衡和流量分发。
整体流程示例：
- 用户通过 Deployment 部署 3 个 Nginx Pod。
- 创建一个 Service，选择标签 app=nginx，将这 3 个 Pod 暴露为 http://nginx-service。
- 当 Pod 因更新或故障被替换时，Service 的 IP 和 DNS 保持不变，确保客户端访问不受影响。