Kubernetes 的本质：一个以 API 为中心的“元操作系统”

最新推荐文章于 2025-12-04 19:53:28 发布

原创最新推荐文章于 2025-12-04 19:53:28 发布 · 783 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #java #容器

🌟 Kubernetes 的本质：一个以 API 为中心的“元操作系统”

Kubernetes 不是一个容器平台，而是一个用于构建和管理分布式系统的通用控制平面。

它的核心不是容器，而是：API + 控制器模式 + 可扩展性。

一、K8s 的 API 类型：统一的资源访问模型

Kubernetes 的 API 是分层、结构化的，支持内置资源与自定义资源的统一访问。

✅ 1. 标准 API（内置资源）

1.1 Namespaced 资源（命名空间作用域）

作用域：限定在某个 namespace 内
用途：多租户隔离、环境划分（dev/staging/prod）

API 格式：

/api/{version}/namespaces/{namespace}/{resource}

示例：

/api/v1/namespaces/default/pods
/api/v1/namespaces/prod/services

常见资源：
- Pods
- Services
- Deployments
- ConfigMaps
- Secrets
- NetworkPolicies

1.2 Un-namespaced 资源（集群作用域）

作用域：全局，不隶属于任何 namespace
命名特征：通常以 Cluster 开头
API 格式：
```
/api/{version}/{resource}
```

示例：

/api/v1/nodes
/apis/rbac.authorization.k8s.io/v1/clusterroles

常见资源：
- Nodes
- ClusterRoles / ClusterRoleBindings
- PersistentVolumes（PV）
- CustomResourceDefinitions（CRD）
- Namespaces

✅ 2. 扩展 API（API Extensions）

通过 API Aggregation 或 CRD，K8s 允许第三方服务扩展其 API。

2.1 CRD（Custom Resource Definition）—— 用户定义的“表”

CRD 是 K8s 可扩展性的核心机制，允许用户定义新的资源类型。

API 格式：

/apis/{group}/{version}/namespaces/{namespace}/{resource}

示例：

/apis/cilium.io/v2/namespaces/kube-system/ciliumnetworkpolicies
/apis/database.example.com/v1/namespaces/app-db/postgresclusters

CRD 的作用：
- 定义新资源的 schema（字段、类型、验证规则）
- K8s 自动为其生成 RESTful API
- 支持 kubectl get/list/create/delete 等操作

二、直观类比：K8s 是一个“API 数据库”

传统数据库	Kubernetes 类比	说明
Database	K8s Cluster	一个集群就是一个“数据库实例”
Schema	API Group + Version	如 `apps/v1`, `example.org/v1`
Table	Kind / CRD	每种资源类型是一张“表”
Row	Resource / CR	每个具体资源是一个“记录”
Column	Field in spec	如 `spec.sweet`, `spec.weight`
SQL	Kubernetes API	`GET`, `POST`, `PUT`, `DELETE`
Index	Label + Selector	`k get pods -l app=nginx`
Trigger	Controller / Operator	监听变化并执行逻辑

💡 kubectl 就是 psql 或 mysql 客户端，而 etcd 是底层存储引擎。

三、CRD 深入解析：如何定义一张“表”

以 Fruit CRD 为例：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: fruits.example.org
spec:
  group: example.org
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                sweet:
                  type: boolean
                weight:
                  type: integer
                comment:
                  type: string
  scope: Namespaced
  names:
    plural: fruits
    singular: fruit
    kind: Fruit
    listKind: FruitList

🔍 关键字段说明

字段	说明
`group`	API 组名，用于 `/apis/<group>/<version>` 路由
`versions`	支持的版本，可多版本共存
`schema`	OpenAPI v3 格式，定义字段类型和约束
`scope`	`Namespaced` 或 `Cluster`
`names.plural/singular`	kubectl 使用的资源名称
`names.kind`	资源的 CamelCase 类型名
`additionalPrinterColumns`	自定义 `kubectl get` 输出列

四、CR（Custom Resource）：插入“数据”

apiVersion: example.org/v1
kind: Fruit
metadata:
  name: apple
  namespace: default
  labels:
    color: red
spec:
  sweet: false
  weight: 100
  comment: little bit rotten

🔁 操作等价于 SQL

操作	kubectl 命令	等价 SQL
创建表	`kubectl create -f fruit-crd.yaml`	`CREATE TABLE fruits (...)`
插入数据	`kubectl create -f apple-cr.yaml`	`INSERT INTO fruits VALUES (...)`
查询数据	`kubectl get fruits`	`SELECT * FROM fruits`
条件查询	`kubectl get fruits -l color=red`	`SELECT * FROM fruits WHERE color='red'`
删除数据	`kubectl delete fruit apple`	`DELETE FROM fruits WHERE name='apple'`

五、API 是“SQL”：kubectl 背后的 HTTP 请求

kubectl 只是 API 的封装，实际调用的是 REST API。

kubectl create -f apple-cr.yaml -v 6

输出：

POST /apis/example.org/v1/namespaces/default/fruits
Content-Type: application/yaml

{
  "apiVersion": "example.org/v1",
  "kind": "Fruit",
  "metadata": { "name": "apple" },
  "spec": { "sweet": false, "weight": 100 }
}

✅ 所有操作最终都转化为对 API Server 的 HTTP 请求。

六、控制器（Controller）：数据库的“触发器”与“存储过程”

🔁 控制器模式 = 事件驱动 + 调谐循环（Reconciliation Loop）

for {
  desired := lister.Get("apple")        // 从 API 获取 spec
  actual  := client.GetPods("apple-*")  // 查询实际状态
  if !equal(desired, actual) {
    reconcile(desired, actual)          // 创建/删除/更新
  }
}

🧩 Operator 框架

用户编写 Operator（控制器），监听 CR 变化；
实现复杂运维逻辑：备份、升级、扩缩容、故障恢复；
例如：PostgresOperator 监听 PostgresCluster CR，自动管理数据库生命周期。

七、RBAC：API 的访问控制

K8s 的 RBAC 支持对 所有 API（内置 + 扩展）进行精细权限控制。

示例：允许用户操作 `Fruit` 资源

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: fruit-manager
rules:
- apiGroups: ["example.org"]
  resources: ["fruits"]
  verbs: ["get", "list", "create", "update", "delete"]

kind: RoleBinding
subjects:
- name: alice
  kind: User
roleRef:
  kind: Role
  name: fruit-manager

✅ CRD 自动继承 K8s 的安全模型，无需重新设计鉴权。

八、K8s 的成功：API 框架的胜利

维度	传统 IaC（Terraform）	Kubernetes API
抽象层级	基础设施资源	应用 + 基础设施
状态管理	外部状态文件	内置 etcd 状态
可扩展性	模块化	CRD + Operator
自动化	手动 apply	控制器自动调谐
生态整合	工具链拼接	统一 API 平台

🏆 K8s 不是替代 Terraform，而是提供了一个更高层次的“运行时控制平面”。

九、未来趋势：Everything as K8s API

Crossplane：将云资源（RDS、S3、VPC）映射为 K8s CRD
Argo CD：将 GitOps 流程抽象为 Application CRD
Istio：服务网格配置通过 VirtualService 等 CRD 管理
Knative：Serverless 函数作为 Service 资源部署

🌐 K8s 正在成为“云原生的通用语言”。

✅ 总结：K8s 的本质

误解	真相
“K8s 是容器编排工具”	“K8s 是一个可编程的、声明式的、事件驱动的 API 平台”
“我们用 K8s 跑容器”	“我们用 K8s 管理整个分布式系统的生命周期”
“CRD 是高级功能”	“CRD 是 K8s 可扩展性的核心，使 K8s 成为通用控制平面”