欢迎访问我的博客,你的支持,是我最大的动力!

马哥_K8s进阶实战(11)Kubernetes系统扩展

Docker 马从东 244℃ 评论
目录:
[显示]
自定义资源类型 CRD

扩展Kubernetes API常用方式:
1、使用CRD自定义资源类型 (易用但限制颇多)
2、开发自定义API Server并聚合至主API Server (富于弹性但代码工作量大)
3、定制扩展K8s源码 (添加新的核心类型时采用)

CRD用于补充一种简单易用更为灵活和更高级别的自定义API资源的方式
CRD本身是一种资源类型,隶属于集群级别,实例化出特定对象后,会在API上注册生成GVR类型URL端点,并能作为一种资源类型被使用并实例化相应的对象

创建CRD对象

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

URL路径前缀为:/apis/auth.ilinux.io/v1beta1/namespace/NS_NAME/users/
# CRD资源对象users.auth.ilinux.io,隶属名称空间级别
# metadata.name必须是 <spec.names.plural>.<spec.group>

kubectl get crd  # 获取crd对象

# 使用自定义users.auth.ilinux.io创建资源
# users并未限制spec字段中可使用的字段及数据类型,于是可以随意设置

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

自定义资源格式验证

定义CRD可用的有效字段,在将设计的自定义资源公开应用时非常有用
spec.validation.openAPIV3Schema

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

子资源

在CRD中为自定义资源启用 status 字段,status 为子资源
spec.subresources.status 字段,其内嵌字段等由系统自行维护,用户无需提供任何额外配置

对象admin的状态引用路径为:/apis/auth.ilinux.io/v1beta1/namespaces/default/users/admin/status
在没有相应资源控制器时,活动对象状态的非计划变动既不会实时反映到status中,也不会向spec定义的期望状态转换

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

使用资源类别

spec.names.categories 类别,分组组织自定义资源的方法,定义crd对象时可指定一个或多个类别
kubectl get <category-name>可列出该类别中的所有自定义资源对象,all为内建类别

多版本支持

crd支持多个版本,但它们之间的转换必须手动完成
spec.version -> spec.versions 并将支持的各版本以对象列表形式给出定义,且必须仅有一个版本标记为存储 spec.versions[].storage: true

自定义控制器基础

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集群,实现持续部署资源对象

 

转载请注明:轻风博客 » 马哥_K8s进阶实战(11)Kubernetes系统扩展

喜欢 (0)or分享 (0)