【学习笔记】Kubernetes
一、 概览
Kubernetes 提供了一个抽象层，是用户可以在屋里或虚拟环境中部署容器化应用，提供以容器为中心的基础架构。
Kubernetes的控制平面和工作节点都有什么组建？ 分别有什么作用？
1.1 Kubernetes控制平面和工作节点的组件及其作用
控制平面组件
控制平面组件负责管理集群的全局决策（如调度），以及检测和响应集群事件。
-
kube-apiserver
- Kubernetes API的前端，所有组件通信的枢纽
- 公开了Kubernetes API，使内部和外部组件可以与集群交互
- 设计为水平扩展（可运行多个实例）
-
etcd
- 一致且高可用的键值存储
- 存储所有集群数据（如配置、状态等）
- 作为Kubernetes的"真相来源"
-
kube-scheduler
- 监视新创建的、未分配节点的Pod
- 根据资源需求、亲和性/反亲和性、污点/容忍等选择最佳节点
- 决定Pod放置在哪个节点上运行
-
kube-controller-manager
- 运行多个控制器进程，例如：
- 节点控制器：管理节点状态
- 副本控制器：维护正确数量的Pod副本
- 端点控制器：连接Service与Pod
- 服务账户和令牌控制器：创建默认账户和API访问令牌
- 运行多个控制器进程，例如：
-
cloud-controller-manager（可选）
- 嵌入特定云平台逻辑的控制器
- 允许Kubernetes代码与云提供商代码分离
- 包含节点控制器、路由控制器、服务控制器等
工作节点组件
工作节点组件在每个节点上运行，维护运行中的Pod并提供Kubernetes运行环境。
-
kubelet
- 在每个节点上运行的主要"节点代理"
- 确保容器按照PodSpec的描述运行
- 管理由Kubernetes创建的容器的生命周期
- 通过API服务器注册节点并报告节点和Pod状态
-
kube-proxy
- 维护节点上的网络规则
- 允许从集群内部或外部与Pod通信
- 实现Kubernetes Service概念
- 处理虚拟IP地址到Pod IP的转发，支持负载均衡
-
容器运行时
- 负责运行容器的软件
- Kubernetes支持多种运行时，如：
- containerd
- CRI-O
- Docker Engine
- 其他符合CRI (Container Runtime Interface) 的实现
此外，集群中通常还会部署一些附加组件（如CoreDNS用于DNS服务、Dashboard用于Web界面等），这些组件增强了集群的功能性。
1.2 目录结构
正在收集工作区信息# Kubernetes目录结构概述
从提供的工作区信息中，可以看到Kubernetes项目的主要目录结构如下：
顶层目录
- api/ - 包含API规范和OpenAPI文档
- build/ - 构建脚本和工具
- cluster/ - 集群部署脚本
- cmd/ - 可执行命令入口点
- docs/ - 项目文档
- hack/ - 开发辅助脚本
- pkg/ - 核心代码库
- plugin/ - 插件代码
- staging/ - 分阶段发布的独立仓库
- test/ - 测试代码和工具
- third_party/ - 第三方代码
- vendor/ - 依赖库
重要的子目录
staging/
这是特别重要的目录，包含已分离成独立仓库的代码包。这些代码最终会作为独立的 k8s.io/ 仓库发布，例如：
- k8s.io/api
- k8s.io/apimachinery
- k8s.io/client-go
- k8s.io/kubectl
- 等20多个子项目
kubectl 目录
从提供的信息中可以看到 kubectl 相关代码位于 staging/src/k8s.io/kubectl 目录中，包含对资源进行描述的 describe 包。
OpenAPI 规范
api/openapi-spec 目录包含 Kubernetes API 的 OpenAPI 规范，定义了 x-kubernetes-group-version-kind 和 x-kubernetes-action 等扩展。
构建系统
Kubernetes 提供了两种环境构建方式：
- 本地 Go 环境
- Docker 容器环境（推荐，提供一致的构建环境）
构建产物输出到 _output/ 目录，主要包括二进制文件和Docker镜像。
总结
Kubernetes 代码库是一个大型项目，使用模块化结构组织代码。核心功能被分解到不同的子模块中，这些子模块最终会发布为独立的仓库，便于其他项目引用。构建系统提供了一致的环境来编译和测试代码。
Kubernetes 层次架构
1. 物理架构层
控制平面（Control Plane）
- API Server: 所有组件的通信中枢
- etcd: 分布式键值存储
- Controller Manager: 控制器管理
- Scheduler: 调度决策
工作节点（Worker Nodes）
- Kubelet: 节点代理
- Container Runtime: 容器运行时
- Kube-proxy: 网络代理
2. 逻辑架构层
基础抽象层
- Node: 计算节点抽象
- Container: 容器抽象
- Pod: 最小部署单元
控制器抽象层
- ReplicaSet: 副本控制
- Deployment: 部署控制
- StatefulSet: 有状态应用
- DaemonSet: 守护进程集
- Job/CronJob: 任务控制
应用配置层
- ConfigMap: 配置管理
- Secret: 敏感信息
- Volume: 存储卷
服务访问层
- Service: 服务发现和负载均衡
- Ingress: 外部访问入口
3. 接口层
API 层级
/api/v1 (核心API组)
/apis/apps/v1 (命名API组)
/apis/batch/v1
/apis/networking.k8s.io/v1
扩展接口
- CRD: 自定义资源定义
- Admission Webhooks: 准入控制
- API Aggregation: API聚合层
4. 功能层
集群管理
- 节点管理
- 资源配额
- 命名空间隔离
应用管理
- 部署管理
- 配置管理
- 状态管理
网络管理
- Pod网络
- Service网络
- 集群网络策略
存储管理
- 持久化存储
- 临时存储
- 存储类
5. 安全层
认证
- X.509 证书
- Bearer Token
- Service Account
授权
- RBAC
- ABAC
- Node/Webhook
准入控制
- ValidatingWebhook
- MutatingWebhook
这种分层架构使得 Kubernetes:
- 高度模块化
- 易于扩展
- 解耦合度高
- 职责划分清晰
- 维护性好
每一层都专注于特定的功能，通过标准接口相互协作，共同构建了一个完整的容器编排平台。
构建过程
二、 Kubernetes 核心数据结构
2.1 Kubernetes API 的层次结构
Kubernetes API 采用了分层的设计架构，主要分为以下几个层次：
1. API Groups（API 组）
API Groups 是相关 API 的集合，便于扩展和演进。主要分为两类：
-
核心组（Core Group）：也称为 Legacy Group
- 路径：
/api/v1 - 包含：Pod、Service、Node 等核心对象
- 路径：
-
命名组（Named Groups）：
- 路径：
/apis/$GROUP_NAME/$VERSION - 例如：
- apps/v1 (Deployments, StatefulSets)
- batch/v1 (Jobs, CronJobs)
- networking.k8s.io/v1 (Ingress)
- 路径：
2. API 版本（Versions）
每个 API Group 可以存在多个版本：
/apis/apps/v1 # 稳定版
/apis/apps/v1beta1 # 测试版
/apis/apps/v1alpha1 # 实验版
版本命名规则：
- alpha: 不稳定，可能有重大变化
- beta: 相对稳定，可能有小的变化
- GA/stable: 稳定版本，向后兼容
3. API 资源（Resources）
每个 API Group 和 Version 下包含多个资源类型：
/apis/apps/v1/deployments
/apis/apps/v1/statefulsets
/apis/apps/v1/daemonsets
4. API 对象结构
所有 API 对象都遵循相同的结构：
apiVersion: GROUP/VERSION # 如 apps/v1
kind: RESOURCE_TYPE # 如 Deployment
metadata: # 元数据
name: my-deployment
namespace: default
spec: # 规约
...
status: # 状态
...
5. 常见 API Groups
-
核心组 (/api/v1)
- Pod
- Service
- ConfigMap
- Secret
- Namespace
- Node
-
apps (/apis/apps/v1)
- Deployment
- StatefulSet
- DaemonSet
- ReplicaSet
-
batch (/apis/batch/v1)
- Job
- CronJob
-
networking.k8s.io (/apis/networking.k8s.io/v1)
- Ingress
- NetworkPolicy
-
rbac.authorization.k8s.io (/apis/rbac.authorization.k8s.io/v1)
- Role
- RoleBinding
- ClusterRole
- ClusterRoleBinding
6. API 扩展机制
Kubernetes 提供了两种扩展 API 的机制：
-
CustomResourceDefinitions (CRDs)
- 允许用户定义自己的资源类型
- 无需修改 Kubernetes 源码
-
API Aggregation
- 允许在集群中运行自定义 API 服务器
- 更灵活但实现更复杂
这种分层结构使得 Kubernetes API：
- 易于扩展
- 支持版本控制
- 便于管理不同成熟度的功能
- 提供清晰的组织结构
Kubernetes 常用对象及其分组
1. 核心组 (Core Group - v1)
位于 /api/v1 路径下
# 基础对象
- Pod # 最小部署单元
- Service # 服务发现和负载均衡
- ConfigMap # 配置管理
- Secret # 敏感信息
- Namespace # 命名空间
- Node # 节点
- PersistentVolume # 持久卷
- PersistentVolumeClaim # 持久卷声明
2. apps 组 (/apis/apps/v1)
用于管理应用部署和扩展
# 工作负载对象
- Deployment # 无状态应用部署
- StatefulSet # 有状态应用部署
- DaemonSet # 守护进程集
- ReplicaSet # 副本集控制
3. batch 组 (/apis/batch/v1)
用于批处理和定时任务
# 任务相关对象
- Job # 一次性任务
- CronJob # 定时任务
4. networking.k8s.io 组 (/apis/networking.k8s.io/v1)
网络相关资源
# 网络对象
- Ingress # 入口控制器
- NetworkPolicy # 网络策略
- IngressClass # Ingress类别
5. rbac.authorization.k8s.io 组 (/apis/rbac.authorization.k8s.io/v1)
角色基于访问控制
# 权限控制对象
- Role # 角色
- RoleBinding # 角色绑定
- ClusterRole # 集群角色
- ClusterRoleBinding # 集群角色绑定
6. storage.k8s.io 组 (/apis/storage.k8s.io/v1)
存储相关资源
# 存储对象
- StorageClass # 存储类
- VolumeAttachment # 卷附加
7. autoscaling 组 (/apis/autoscaling/v2)
自动扩缩容
# 扩缩容对象
- HorizontalPodAutoscaler # 水平Pod自动扩缩容
- VerticalPodAutoscaler # 垂直Pod自动扩缩容
8. policy 组 (/apis/policy/v1)
策略相关
# 策略对象
- PodDisruptionBudget # Pod中断预算
示例用法
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
常见使用模式
-
基础部署
- Deployment + Service + ConfigMap
- StatefulSet + Service + PVC
- DaemonSet + ConfigMap
-
网络访问
- Service + Ingress
- NetworkPolicy
-
权限控制
- ServiceAccount + Role + RoleBinding
- ClusterRole + ClusterRoleBinding
-
存储方案
- PV + PVC + StorageClass
这些对象通过API Server进行管理，使用kubectl命令行工具或其他客户端进行操作。每个对象都有其特定的用途和最佳实践，组合使用可以构建完整的应用系统。