从Linux基础到k8s进阶,马哥_K8s进阶实战(11)Kubernetes系统扩展

自定义资源类型 CRD

扩展Kubernetes API常用方式：

1、使用CRD自定义资源类型 (易用但限制颇多)

2、开发自定义API Server并聚合至主API Server (富于弹性但代码工作量大)

3、定制扩展K8s源码 (添加新的核心类型时采用)

CRD用于补充一种简单易用更为灵活和更高级别的自定义API资源的方式

CRD本身是一种资源类型，隶属于集群级别，实例化出特定对象后，会在API上注册生成GVR类型URL端点，并能作为一种资源类型被使用并实例化相应的对象

创建CRD对象

选定要使用的API群组名称、版本及新建的资源类型名称后，即可创建自定义资源类型，而后就可以创建自定义类型的资源对象

YAML

1

2

3

4

5

6

7

8

9

10

11

12

13

14

apiVersion: apiextensions.k8s.io/v1beta1

kind: CustomResourceDefinition

metadata:

name: users.auth.ilinux.io

spec:

group: auth.ilinux.io

version: v1beta1

names:

kind: User

plural: users

singular: user

shortNames:

-u

scope: Namespaced

URL路径前缀为：/apis/auth.ilinux.io/v1beta1/namespace/NS_NAME/users/

# CRD资源对象users.auth.ilinux.io，隶属名称空间级别

# metadata.name必须是 .

kubectl get crd  # 获取crd对象

# 使用自定义users.auth.ilinux.io创建资源

# users并未限制spec字段中可使用的字段及数据类型，于是可以随意设置

YAML

1

2

3

4

5

6

7

8

9

10

11

12

apiVersion: auth.ilinux.io/v1beta1

kind: User

metadata:

name: admin

namespace: default

spec:

userID: 1

email: k8s@ilinux.io

groups:

-supersuers

-adminstrators

password: ikubernetes

selfLink: /apis/auth.ilinux.io/v1beta1/namespaces/default/users/admin

自定义资源格式验证

定义CRD可用的有效字段，在将设计的自定义资源公开应用时非常有用

spec.validation.openAPIV3Schema

YAML

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

spec:

...

validation:

openAPIV3Schema:

properties:

spec:

properties:

userID:

type: integer

minimum: 1

maximum: 65535

groups:

type: array

email:

type: string

password:

type: string

format: password

required: ["userID","groups"]

spec.additionalPrinterColumns 定义 kubectl get/describe 等命令结果显示的字段：

YAML

1

2

3

4

5

6

7

8

9

10

11

spec:

...

additionalPrinterColumns:

- name: userID

type: integer

description: The user ID.

JSONPath: .spec.userID

- name: groups

type: string

description: The groups of the user.

JSONPath: .spec.groups

子资源

在CRD中为自定义资源启用 status 字段，status 为子资源

spec.subresources.status 字段，其内嵌字段等由系统自行维护，用户无需提供任何额外配置

YAML

1

2

3

4

spec:

...

subresources:

status:{}

对象admin的状态引用路径为：/apis/auth.ilinux.io/v1beta1/namespaces/default/users/admin/status

在没有相应资源控制器时，活动对象状态的非计划变动既不会实时反映到status中，也不会向spec定义的期望状态转换

在有相应资源控制器维护自定义资源类型时，可使用scale子资源和status子资源协同实现伸缩功能

YAML

1

2

3

4

5

6

7

8

spec:

...

subresources:

status:{}

scale:

specReplicasPath: string,定义表示期望副本数量的字段，JSONPath格式，如.spec.replicas

statusReplicasPath: string,引用保存在status中用于表示对象当前副本数量的字段，JSONPath格式，如.status.replicas

labelSelectorPath: string,可选字段，若要与HPA结合则为必选字段，引用status中用于表示使用的标签选择器字段，JSONPath格式，如.status.labelSelector

使用资源类别

spec.names.categories 类别，分组组织自定义资源的方法，定义crd对象时可指定一个或多个类别

kubectl get 可列出该类别中的所有自定义资源对象，all为内建类别

YAML

1

2

3

4

5

6

7

spec:

...

names:

categories:

-all

kind: User

plural: users

多版本支持

crd支持多个版本，但它们之间的转换必须手动完成

spec.version -> spec.versions 并将支持的各版本以对象列表形式给出定义，且必须仅有一个版本标记为存储 spec.versions[].storage: true

YAML

1

2

3

4

5

6

7

8

9

spec:

...

versions:

- name: v1beta1

served: true

storage: true

- name: v1beta2

served: true

storage: false

自定义控制器基础

crd仅提供json格式数据范式及存取能力，确保status中状态向spec中状态变动则由自定义控制器实现

提供业务逻辑代码的控制器由用户自行开发，并运行为API Server的客户端程序(类似于Ingress控制器)

控制器负责持续监视资源变动，根据资源的spec及status中信息执行某些操作逻辑，并将执行结果更新到资源的status中

创建控制器时，使用社区发布的workqueue example和sample-controller作为基础结构

或者，使用Kubebuilder、Operator SDK、Metacontroller

参考：https://github.com/nikhita/custom-database-controller

自定义API Server

kube-apiserver中，聚合自定义API Server的组合是kube-aggregator

先在主API Server上添加一个APIService资源对象，将自定义API Server注册到kube-aggregator上，以完成聚合操作

Kubernetes集群高可用

kubernetes cluster-autoscaler可为集群提供规模按需自动缩放能力

高可用控制平面至少需要三个Master节点，允许最多一个Master节点的丢失：

etcd集群

将无状态的apiserver运行为多副本，并在其前端添加负载均衡器，负载均衡器也应是高可用的

leader选举功能 --leader-election 控制器和调度器

etcd的高可用

静态集群：分配静态IP地址

基于etcd发现服务构建集群：依赖一个现存的可用的etcd服务，通过事先存在的集群创建新的集群

基于dns的服务资源记录构建集群：通过srv记录，而后基于此域名进行服务发现来动态组建新集群，依赖于dns服务及srv记录

etcd集群通常使用3、5、7个节点，过大的集群规模没有必要，对性能会产生负面影响

ControllerManager和Scheduler高可用

对于kube-controller-manager，某一时该，仅能有一个实例处于正常工作状态，余下均处于备用状态(等待状态)

多个kube-controller-manager实例要同时启用 --leader-elect=true 实现leader选举，仅leader实例处于活动状态

# 选举仅通过在kube-system名称空间中创建一个与程序同名的Endpoints资源对象实现

# kubectl get endpoints -n kube-system

# kubectl describe endpoints kube-controller-manager -n kube-system

## 资源锁，leader抢到锁后，更新注解 control-plane.alpha.kubernetes.io/leader 将 holderIdentity 设置为节点名称，表示持有锁，并周期性更新renewTime 以声明自己对锁资源的持有状态

kube-scheduler的实现方式与此类似

Kubernetes部署模式

核心基础架构：计算、网络、存储相关底层部件

叠加网络：Calico、Flannel、Romana、Weave Net

存储系统：GlusterFS、NFS、RBD

容器化工作负载：向个提供服务

供应和配置管理：Ansible、Chef、Puppet、Terraform

镜像仓库：可托管于集群之上

日志记录和监控：

负载均衡器：API Server的负载均衡和出站流量的负载均衡

工件仓库：配置设定、依赖项、软件包、脚本等

构建和发布管理：Jenkins

容器时代的DevOps

kube-applier是一种服务，在集群中作为Pod运行，监视Git仓库，通过将声明性配置文件从Git存储库应用到Kubernetes集群，实现持续部署资源对象

喜欢 (2)or分享 (0)