38、自定义 Kubernetes：API 与插件深度解析

自定义 Kubernetes：API 与插件深度解析

在当今的容器编排领域，Kubernetes 凭借其强大的功能和高度的灵活性，成为了众多企业和开发者的首选。本文将深入探讨如何通过 Python 与 Kubernetes 进行交互，以及如何扩展 Kubernetes 的 API 并编写自定义插件。

1. 使用 Python subprocess 运行 Kubectl

Python 的 subprocess 模块为我们提供了一种便捷的方式来运行外部进程，例如 kubectl ，并捕获其输出。以下是一个 Python 3 的示例，展示了如何运行 kubectl 并显示其使用说明的开头部分：

import subprocess
out = subprocess.check_output('kubectl').decode('utf-8')
print(out[:276])

上述代码中， check_output 函数捕获的输出是字节数组，需要将其解码为 UTF - 8 字符串才能正确显示。为了方便使用，我们可以创建一个名为 k 的函数，该函数接受参数并将其传递给 kubectl ，然后解码输出并返回：

from subprocess import check_output
def k(*args):
    out = check_output(['kubectl'] + list(args))
    return out.decode('utf-8')

使用这个函数，我们可以列出默认命名空间中所有正在运行的 Pod：

print(k('get', 'po'))

当我们使用 -o 标志指定结构化输出选项时， kubectl 的真正强大之处就体现出来了。此时，结果可以自动转换为 Python 对象。以下是修改后的 k 函数，它接受一个布尔型的 use_json 关键字参数（默认为 False ），如果为 True ，则添加 -o json 并将 JSON 输出解析为 Python 对象（字典）：

from subprocess import check_output
import json
def k(use_json=False, *args):
    cmd = ['kubectl']
    cmd += list(args)
    if use_json:
        cmd += ['-o', 'json']
    out = check_output(cmd)
    if use_json:
        out = json.loads(out)
    else:
        out = out.decode('utf-8')
    return out

使用这个改进后的函数，我们可以获取 Pod 列表并遍历输出：

result = k('get', 'po', use_json=True)
for r in result['items']:
    print(r['metadata']['name'])

如果要删除部署并等待所有 Pod 消失，可以按以下步骤操作：

k('delete', 'deployment', 'nginx-deployment')
while len(k('get', 'po', use_json=True)['items']) > 0:
    print('.')
print('Done.')

2. 扩展 Kubernetes API

Kubernetes 是一个极其灵活的平台，允许我们通过自定义资源扩展其 API。如果这还不够，我们甚至可以提供自己的 API 服务器，并通过 API 聚合机制与 Kubernetes API 服务器集成。

2.1 自定义资源的用途

自定义资源可以用于管理 Kubernetes 集群外部的资源，使我们能够全面了解系统，并受益于 Kubernetes API 的许多功能，例如：
- 自定义 CRUD REST 端点
- 版本控制
- 监控
- 与通用 Kubernetes 工具的自动集成

此外，自定义资源还可用于自定义控制器和自动化程序的元数据。

2.2 自定义资源的结构

为了与 Kubernetes API 服务器兼容，第三方资源必须符合一些基本要求。与内置 API 对象类似，它们必须包含以下字段：
| 字段 | 说明 |
| ---- | ---- |
| apiVersion | apiextensions.k8s.io/v1beta1 |
| metadata | 标准的 Kubernetes 对象元数据 |
| kind | CustomResourceDefinition |
| spec | 描述资源在 API 和工具中的显示方式 |
| status | 指示 CRD 的当前状态 |

spec 具有内部结构，包括 group 、 names 、 scope 、 validation 和 version 等字段； status 包括 acceptedNames 和 Conditions 字段。

2.3 开发自定义资源定义（CRD）

我们可以使用自定义资源定义（CRD）来开发自定义资源。以下是一个名为 Candy 的自定义资源的示例：

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: candies.awesome.corp.com
spec:
  group: awesome.corp.com
  version: v1
  scope: Namespaced
  names:
    plural: candies
    singular: candy
    kind: Candy
    shortNames:
    - cn

创建这个 CRD 的命令如下：

kubectl create -f crd.yaml

验证是否可以访问该 CRD：

kubectl get crd

创建自定义资源后，会有一个新的 API 端点用于管理该资源：

/apis/awesome.corp.com/v1/namespaces/<namespace>/candies/

使用 Python 代码访问该端点：

import config
config.load_kube_config()
print(k('get', 'thirdpartyresources'))

2.4 集成自定义资源

创建 CustomResourceDefinition 对象后，我们可以创建该资源类型的自定义资源。例如，创建一个 Candy 对象：

apiVersion: "awesome.corp.com/v1"
kind: Candy
metadata:
  name: chocolatem
spec:
  flavor: "sweeeeeeet"

创建这个 Candy 对象的命令如下：

kubectl create -f candy.yaml

此时， kubectl 可以像操作内置对象一样操作 Candy 对象。我们还可以使用 -o json 标志查看原始 JSON 数据：

kubectl get cn -o json

2.5 完成自定义资源

自定义资源支持终结器（finalizers），就像标准 API 对象一样。终结器是一种机制，对象不会立即被删除，而是需要等待后台运行的特殊控制器处理删除请求。以下是一个带有两个终结器的 Candy 对象示例：

apiVersion: "awesome.corp.com/v1"
kind: Candy
metadata:
  name: chocolate
  finalizers:
  - eat-me
  - drink-me
spec:
  flavor: "sweeeeeeet"

2.6 验证自定义资源

Kubernetes 1.9 引入了基于 OpenAPI V3 模式的 CRD 验证机制。我们可以在 CRD 的 spec 中添加 validation 部分：

validation:
    openAPIV3Schema:
      properties:
        spec:
          properties:
            cronSpec:
              type: string
              pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
            replicas:
              type: integer
              minimum: 1
              maximum: 10

如果尝试创建违反验证规则的对象，将会收到错误消息。

2.7 理解 API 服务器聚合

当我们只需要对自己的类型进行一些 CRUD 操作时，CRD 是一个不错的选择。但如果需要更高级的功能和定制化，可以使用 API 服务器聚合并编写自己的 API 服务器，Kubernetes API 服务器将委托该服务器进行处理。

自己的 API 服务器将使用与 Kubernetes API 服务器相同的 API 机制，具有以下高级功能：
- 控制对象的存储
- 多版本控制
- 除 CRUD 之外的自定义操作（如 exec 或 scale）
- 使用协议缓冲区有效负载

编写扩展 API 服务器是一项具有挑战性的任务，建议使用 API 构建器项目 ，它可以处理许多必要的样板代码。

3. 利用服务目录

Kubernetes 服务目录项目允许我们无缝集成任何支持开放服务代理 API 规范的外部服务。该项目的目标是通过标准规范将外部服务暴露给任何云环境，目前支持 Kubernetes 和 Cloud Foundry 等环境。

服务目录对于集成云平台提供商的服务特别有用，例如：
- Microsoft Azure Cloud Queue
- Amazon Simple Queue Service
- Google Cloud Pub/Sub

通过服务目录，我们可以将一些服务的部署、管理和维护工作交给云提供商，从而专注于自己的应用程序。

4. 编写 Kubernetes 插件

Kubernetes 的灵活性和可扩展性使其支持编写自定义插件。下面我们将重点介绍如何编写自定义调度器插件。

4.1 理解 Kubernetes 调度器的设计

调度器的主要任务是为新创建或重启的 Pod 找到合适的节点，并在 API 服务器中创建绑定，然后在该节点上运行 Pod。如果调度器找不到合适的节点，Pod 将处于待处理状态。

调度器的大部分工作是通用的，包括确定哪些 Pod 需要调度、更新其状态并在选定的节点上运行。自定义部分在于如何将 Pod 映射到节点。Kubernetes 团队认识到自定义调度的需求，通用调度器可以配置不同的调度算法。

调度器的主要数据类型是 Scheduler 结构体，它包含一个 Config 结构体：

type Scheduler struct {
    config *Config
}
type Config struct {
    SchedulerCache schedulercache.Cache
    Ecache     *core.EquivalenceCache
    NodeLister algorithm.NodeLister
    Algorithm  algorithm.ScheduleAlgorithm
    GetBinder  func(pod *v1.Pod) Binder
    PodConditionUpdater PodConditionUpdater
    PodPreemptor PodPreemptor
    NextPod func() *v1.Pod
    WaitForCacheSync func() bool
    Error func(*v1.Pod, error)
    Recorder record.EventRecorder
    StopEverything chan struct{}
    VolumeBinder *volumebinder.VolumeBinder
}

大部分字段都是接口，因此我们可以使用自定义功能配置调度器。特别是，如果要自定义 Pod 调度，调度算法是关键。

4.2 注册算法提供者

调度器有算法提供者和算法的概念，它们允许我们利用内置调度器的强大功能来替换核心调度算法。

已经有一个名为 ClusterAutoScalerProvider 的自定义提供者被注册。我们需要扩展 registerAlgorithmProvider 函数，以包含自己的算法提供者：

func registerAlgorithmProvider(predSet, priSet sets.String) {
    factory.RegisterAlgorithmProvider(factory.DefaultProvider, predSet, priSet)
    factory.RegisterAlgorithmProvider(ClusterAutoscalerProvider, predSet,
        copyAndReplace(priSet, "LeastRequestedPriority", "MostRequestedPriority"))
}

除了注册提供者，还需要注册适合谓词和优先级函数，用于实际执行调度。可以使用工厂的 RegisterFitPredicate() 和 RegisterPriorityFunction2() 函数。

4.3 配置调度器

调度器算法作为配置的一部分提供。自定义调度器可以实现 ScheduleAlgorithm 接口：

type ScheduleAlgorithm interface {
    Schedule(*v1.Pod, NodeLister) (selectedMachine string, err error)
    Preempt(*v1.Pod, NodeLister, error) (selectedNode *v1.Node,
                                         preemptedPods []*v1.Pod,
                                         cleanupNominatedPods []*v1.Pod,
                                         err error)
    Predicates() map[string]FitPredicate
    Prioritizers() []PriorityConfig
}

运行调度器时，可以通过命令行参数提供自定义调度器的名称或自定义算法提供者的名称。如果未提供，则使用默认算法提供者。调度器的命令行参数为 --algorithm-provider 和 --scheduler-name 。

4.4 打包调度器

自定义调度器作为 Pod 在其管理的 Kubernetes 集群内运行，需要将其打包为容器镜像。以下是打包调度器的步骤：
1. 从源代码构建 Kubernetes 以获取调度器镜像：

git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make

2. 创建 Dockerfile：

FROM busybox
ADD ./_output/bin/kube-scheduler /usr/local/bin/kube-scheduler

3. 构建 Docker 镜像：

docker build -t custom-kube-scheduler:1.0 .

4. 将镜像推送到容器注册表：

docker login
docker push g1g1/custom-kube-scheduler

4.5 部署自定义调度器

构建并将调度器镜像推送到注册表后，需要创建一个 Kubernetes 部署来运行它。以下是一个 YAML 文件示例，定义了一个具有单个副本和一些额外配置（如存活和就绪探针）的部署：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: custom-scheduler
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        component: scheduler
        tier: control-plane
        version: second
    spec:
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --address=0.0.0.0
        - --leader-elect=false
        - --scheduler-name=custom-scheduler
        image: g1g1/custom-kube-scheduler:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10251
          initialDelaySeconds: 15
        name: kube-second-scheduler
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10251
        resources:
          requests:
            cpu: '0.1'

通过以上步骤，我们可以深入了解如何使用 Python 与 Kubernetes 交互，扩展其 API 并编写自定义插件，从而更好地满足不同的业务需求。

自定义 Kubernetes：API 与插件深度解析

5. 自定义调度器插件实践总结与思考

在前面的内容中，我们详细介绍了编写自定义调度器插件的各个步骤，包括理解调度器设计、注册算法提供者、配置调度器、打包和部署调度器。下面我们对整个过程进行总结，并思考一些可能遇到的问题及解决方案。

5.1 自定义调度器插件开发流程回顾

整个自定义调度器插件的开发流程可以用以下 mermaid 流程图表示：

graph LR
    A[理解调度器设计] --> B[注册算法提供者]
    B --> C[配置调度器]
    C --> D[打包调度器]
    D --> E[部署自定义调度器]

从流程图可以清晰地看到，每个步骤都是紧密相连的，前一个步骤为后一个步骤提供基础。

5.2 可能遇到的问题及解决方案

• 打包问题 ：在打包调度器时，如果在不同的操作系统上进行构建和部署，可能会遇到兼容性问题。例如，在开发环境中构建的镜像在生产环境中无法正常运行。解决方案是将构建命令插入到 Dockerfile 中，虽然这样会增加镜像的大小，但可以确保在不同环境中的一致性。
• 调度算法问题 ：自定义调度算法可能会出现性能问题，导致调度效率低下。在开发过程中，需要对调度算法进行充分的测试和优化，确保其能够高效地将 Pod 映射到节点。
• 集成问题 ：自定义调度器插件与 Kubernetes 集群的集成可能会出现问题，例如无法正常与 API 服务器通信。这可能是由于配置错误或网络问题导致的，需要仔细检查配置文件和网络设置。

6. 其他 Kubernetes 插件类型简介

除了自定义调度器插件，Kubernetes 还支持其他类型的插件，下面简要介绍几种常见的插件类型。

6.1 认证和授权插件

认证和授权插件用于控制对 Kubernetes API 服务器的访问。常见的认证插件包括基于证书的认证、基于令牌的认证等；授权插件包括基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）等。

配置认证和授权插件的步骤如下：
1. 选择合适的认证和授权插件。
2. 在 Kubernetes API 服务器的配置文件中启用相应的插件。
3. 配置插件的参数，例如证书的路径、令牌的有效期等。

6.2 存储插件

存储插件用于管理 Kubernetes 集群中的存储资源。常见的存储插件包括 NFS、iSCSI、Ceph 等。

使用存储插件的步骤如下：
1. 安装和配置存储系统，例如 NFS 服务器、Ceph 集群等。
2. 在 Kubernetes 集群中安装相应的存储插件。
3. 创建存储类（StorageClass），定义存储资源的属性和配置。
4. 创建持久卷声明（PVC），请求存储资源。
5. 在 Pod 中使用 PVC 挂载存储卷。

6.3 网络插件

网络插件用于管理 Kubernetes 集群中的网络通信。常见的网络插件包括 Flannel、Calico、Weave Net 等。

配置网络插件的步骤如下：
1. 选择合适的网络插件。
2. 在 Kubernetes 集群中安装相应的网络插件。
3. 配置网络插件的参数，例如网络地址范围、子网掩码等。

7. 总结与展望

通过本文的介绍，我们深入了解了如何使用 Python 与 Kubernetes 进行交互，扩展其 API 并编写自定义插件。自定义 Kubernetes 可以帮助我们更好地满足不同的业务需求，提高系统的灵活性和可扩展性。

在未来，随着 Kubernetes 的不断发展，我们可以期待更多的插件类型和功能的出现。例如，更加智能的调度算法、更加安全的认证和授权机制等。同时，我们也需要不断学习和掌握新的技术，以适应不断变化的需求。

总之，自定义 Kubernetes 是一个充满挑战和机遇的领域，希望本文能够为你提供一些有用的参考和指导，让你在 Kubernetes 的世界中探索更多的可能性。