CRD自定义资源类型

k8s系统的扩展，指定是：扩展api-server所识别支持的资源类型、集群单点扩展为高可用、

扩展的资源类型，应兼容k8s基础特性：如kubectl管理、watch机制、etcd存储、通过认证、授权、准入控制等流程；rbac授权，等；

扩展k8s支持的资源类型有三种方式：

使用k8s给定标准k8s对象crd，按照其格式定义自己的自定义资源类型，（限制较大）
开发自定义api-server，其支持新的资源类型，然后借助聚合器，聚合到k8s的api-server
定义扩展k8s源码

创建crd对象

crd本身就会k8s标准的资源对象；

自定义资源类型：

用crd定义了一个扩展k8s资源类型为users，其中plural+spec.group两个字段合起来要等于metadata.name，定义的资源为名称空间级别，url路径为/apis/user.auth.ilinux.io/v1beta1/namespace/NS-NAME/user/具体的对象名

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


[root@client crd]# cat crd-users.yaml 
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
 name: user.auth.ilinux.io
spec:
 group: auth.ilinux.io
 version: v1beta1
 names:
  kind: User
  plural: user
  singular: user
  shortNames:
  - u
 scope: Namespaced

[root@client crd]# vim crd-users.yaml
[root@client crd]# kubectl apply -f crd-users.yaml 
customresourcedefinition.apiextensions.k8s.io/user.auth.ilinux.io created

创建自定义类型的对象：其中spec字段，可随意指定，但要符合yaml语法

[root@client crd]# cat user-obj1.yaml 
apiVersion: auth.ilinux.io/v1beta1
kind: User
metadata:
 name: user-obj1
spec:
 userID: 1
 email: shuai@gmail.com
 groups:
 - admin
 - superusers
 gender: male
----

[root@client crd]# kubectl apply -f user-obj1.yaml 
user.auth.ilinux.io/user-obj1 created
[root@client crd]# kubectl get crd
NAME                  CREATED AT
user.auth.ilinux.io   2020-11-29T02:54:03Z
[root@client crd]# kubectl get user.auth.ilinux.io
NAME        AGE
user-obj1   26s
[root@client crd]# kubectl get user.auth.ilinux.io user-obj1 -o yaml
apiVersion: auth.ilinux.io/v1beta1
kind: User
metadata:
  annotations:
    kubectl

限制自定义资源格式

定义crd新的资源类似时，在spec.validation中，可以定义自定义的资源类型，有哪些字段、每个字段的数据格式、数据取值范围、必填字段等信息，如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


[root@client crd]# cat crd-users.yaml 
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
 name: user.auth.ilinux.io
spec:
 group: auth.ilinux.io
 version: v1beta1
 names:
  kind: User
  plural: user
  singular: user
  shortNames:
  - u
 scope: Namespaced
 validation:
  openAPIV3Schema:
   properties:
    spec:
     properties:
      userID:
       type: integer
       minimum: 1
       maximum: 100
      groups:
       type: array
      email:
       type: string
      password:
       type: string
       format: password
     required: ["userID","groups"] 
---

[root@client crd]# kubectl apply -f crd-users.yaml 
customresourcedefinition.apiextensions.k8s.io/user.auth.ilinux.io configured

# 修改crd的实例对象后，其userid改为101，再次创建就验证失败，因为其取值范围最大101
[root@client crd]# vim user-obj1.yaml 
[root@client crd]# vim user-obj1.yaml 
[root@client crd]# kubectl apply -f user-obj1.yaml 
The User "user-obj1" is invalid: []: Invalid value: map[string]interface {}
...
spec.userID in body should be less than or equal to 100

此外：可以通过spec.additionalPrinterColumns字段，定义kubectl get 对象名时，打印哪些字段

子资源

刚定义的crd新资源类型，默认是没有status字段，因为也没有相应的控制器，自然不会去获取它的status和spec，通过不断的和解循环，使两者保持一致，

但可以通过subresources字段，定义staus字段，然后describe新资源类型的对象就可以看到status资源，只是是“假的”status信息，因为它没有控制器去获取它并和spec进行不断的和解循环，若定义了相应控制器情况下，也可以搭配scale实现资源扩缩容的效果；

[root@client crd]# kubectl explain crd.spec.subresources
KIND:     CustomResourceDefinition
VERSION:  apiextensions.k8s.io/v1beta1

RESOURCE: subresources <Object>

DESCRIPTION:
     Subresources describes the subresources for CustomResources

     CustomResourceSubresources defines the status and scale subresources for
     CustomResources.

FIELDS:
   scale	<Object>
     Scale denotes the scale subresource for CustomResources

   status	<>
     Status denotes the status subresource for CustomResources

资源类别使用

资源类型都有分类分组，如pod，service，在kubectl get时可以利用分类名获取当前类下所有对象，而all包含了所有分类，

如下，定义crd时，将其归为了all分类，

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
 name: user.auth.ilinux.io
spec:
 group: auth.ilinux.io
 version: v1beta1
 names:
  kind: User
  plural: user
  singular: user
  shortNames:
  - u
  categories:
  - all
 subresources:
  status: {}

get 查看all分类时就能看到其对应的实例对象

[root@client crd]# kubectl get all
NAME             READY   STATUS      RESTARTS   AGE
pod/limit-pod1   0/1     Completed   0          4d1h

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   4d1h

NAME                            AGE
user.auth.ilinux.io/user-obj1   1h

自定义api-server

自行编写api-server也可以实现k8s资源类型的扩展，但一般编写的自定义api-server要通过原生kube-apiserver中的kube-aggregator聚合到主api-server，由其统一对外提供服务；

apiService

自定义api-server扩展k8s资源类型的实现步骤：

编写自定义的api-servre代码，并以pod方式运行在k8s集群上
为其pod创建service对象
定义个apiService对象，引用上步的service对象，kube-aggregator借助该apiService对象完全自定义api-server的聚合

apiService就是帮助把自定义的api-server聚合到aggregator之上的一种资源对象；

k8s集群高可用

图示：

k8s集群(控制端)各组件高可用结构

kube-apiserver为无状态组件：可同时运行多个，分担客户端的请求
kube-controller-manager
kube-schduler，调度器和控制器组件，为避免多个组件做的决策冲突，因此运行多个副本，但只有一个为活动态，其余备用
etcd集群，整个集群的数据、状态所在地，可以同时运行奇数个节点做高可用，依赖其raft算法实现，（一般3、5、7个节点）

k8s部署模式

k8s集群及周边组件

k8s作为容器应用编排系统，基本完成了容器应用的编排各个方面，但若投入生产中使用，还需周边一系列配套的组件和基础架构，如：

底层平台：数据中心物理机、虚拟机、公有云、私有云；
网络和存储
1. 依赖sdn-软件定义网络，的组件实现k8s集群的网络实现
2. 依赖sds-软件定义存储，的组件，如ceph、glusterfs集群为k8s集群提供持久、高可用存储
然后是k8s自身
1. 控制平面组件
2. 其上容器化应用
外部负载均衡器
1. 控制端高可用的apiserver组件需要通过负载均衡器接入管理员客户端
2. 容器化应用提供的服务，暴露到集群外部时，如loadbalancer型service需要负载均衡器接入
日志和监控
1. elk日志收集、处理系统
2. prometheus、grafana等监控系统
配置管理
1. puppet
2. ansible
镜像仓库
1. habor
it资产管理
1. cmdb等系统
CI/CD系统
1. gitlab
2. Jenkins
3. snarqube等，做流水线式应用编码、构建、测试、上线、失败回滚等一系列流程

k8s常用部署模式

完全由管理员手动一步步部署k8s集群，以及其周边组件；
借助部署工具部署k8s集群，如kubeadm简化k8s的部署，以及其他周边组件；
直接使用云服务商的k8s集群服务、以及其周边服务；

容器与devops

容器自包含依赖的特性消除了开发、测试、生产各种环境的差异，使得开发、测试、运维专注于自己的部分，且极大提高了运维效率，降低了复杂性；

开发人员在k8s和容器化应用的工作流：【编码、构建镜像、提交清单给k8s】

**编码：**开发编写应用代码，推送到git仓库，经由ci工具链测试，然后释出；
**构建镜像：**开发编写dockerfile，推送到git仓库，基于基础镜像、释出应用包构建docker镜像，推送到docker仓库；
**提交清单：**开发编写k8s清单-yaml文件，或helm charts，由kube applier等客户端应用提交到k8s集群运行；

运维只需维护k8s集群，以及周边组件集群如监控、存储即可；各司其职！（不止应用程序、很多周边组件，也可以托管于k8s之上）

k8s之系统扩展

相关文章：