微服务的演进方向
• 分布式设计（Distribution）: 用于容器、微服务和API 驱动的开发。
• 面向配置的设计（Configuration） : 一张镜像，多种环境配置。
• 弹性（Resistance）: 专为容错和自我修复而设计。
• 弹性专为： 的弹性扩展和对环境变化（负载）的响应而设计。
• 专为时间而设计（交付） : 自动激活以缩短交付时间。
• 面向性能的设计（性能） : 响应能力、并发性和资源高效利用。
• 用于自动化设计： 自动化的DevOps（自动化）。
• 诊断设计（诊断） : 集群级日志、指标和跟踪。
• 面向安全的设计（安全） : 安全端点、API 网关、端到端加密。
满足微服务架构模型的要求
• 集装箱化
• 服务发现
• 可编程的
• 动态调度
• 支持标准cid
• 分布式配置架构
• 声明式配置
Kubernetes 的诞生就是为了适应上述微服务的各种演进和特性。 Kubernetes 的设计理念充满了对不同微服务编排模式的定制支持。
K8S的特点
• 可预测的需求
资源使用
服务配置
流量控制
依赖管理
• 声明式部署
滚动升级
固定方法升级
蓝绿升级
金丝雀发布
• 运行状况探测
健康检查：健康检查
活性检查：线性探针（HTTP、TCP、EXEC）
库存检查：准备探针
• 受管理的生命周期
信号
西格基尔
重启
按顶钩
启动后挂钩
• 自动放置
安排最佳资源
K8S各组件的配合
吊舱简介
为多个容器开启共享隔离机制。每个Pod 都包含一个暂停以初始化环境的容器。
Pod 基础知识
Pod 本质上是多个共享资源的容器的组合。
Pod调度的过滤策略
Pod应用资源优先级控制机制及模型
如上图所示，三种资源分配模型各自具有特定的特点，基于模型的特点，我们集成了资源混合部署的优先级控制机制，以提高集群资源的整体利用率。
• 尽最大努力
• 可沐浴
• 有保证
服务
在K8集群中，客户端需要访问的服务就是Service对象。每个服务都对应集群中的一个有效的虚拟IP，通过集群中的虚拟IP访问服务。
• label：用于过滤和选择pod。标签在k8s 内建立索引，因此在设计业务模型时，您可以使用标签来表示用于过滤和检索的所有字段。是一个有效的搜索字段。
• 注释：用于注释标签上难以清楚解释的内容。不要使用注释作为过滤字段，因为它们没有索引。
• configmap：开发控制器或定义容器时需要额外配置，但此配置信息不能通过标签或注释传递。在这种情况下，最好的解决方案是使用configmap。
交通接入
通过代理方法
负载均衡器直接连接到服务
通过入口组件公开接口
ETCD描述
etcd是K8S分布式存储中心，etcd集群管理，raft协议保证一致性。
有关详细的etcd 说明，有一本开源电子书：https://csunny.gitbook.io/etcd/introduce
控制器控制器型号
K8S 提供了基于etcd 的事件驱动编程模型，允许您控制资源的生命周期并随着事件的变化动态调整它们。
控制原理图
在Observe—Analyze—Act 事件循环中，k8s 提供的控制器编程模型提供了可靠的基于资源的扩展性协议和通用编程模型，在该模型下更通用的定制可以扩展你的逻辑。
使用shell 脚本模拟控制器模式，如下所示：
K8S Watch事件类型的附加说明：
操作员
Operator本质上是定制化的控制器，但在控制器层面进行了很多额外的封装操作，方便定制化的资源控制和服务管理。
CRD（CustomResourceDefinition）对于扩展K8S的接口非常有用。 CRD让您更好地掌控基于K8S的定制场景。 CRD 将K8S 的功能与特定领域软件的功能集成在一起。这种集成为K8S 提供了巨大的扩展空间。
标准crd 定义的示例：
1. 姓名
2.API组
3. 确定资源类型以识别您的资源。
4. 名称的复数形式（URL：/apis/group/version/名称的复数形式）
5.范围，例如命名空间维度或集群维度。
6. 版本
7. 支持的具体版本号
8. 仅将一个版本标记为存档版本，以指示应保存当前版本。
9. 每个版本都可以通过提供来启用或禁用。
10.Openapi版本的Schema定义schema
体积
卷是pod 内的共享目录，可由多个容器访问。 Kubernetes 中的卷与pod 具有相同的生命周期，但Kubernetes 支持多种类型的卷。一个Pod 可以同时使用任意数量的卷。
• EmptyDir: 是在分配Pod 时创建的，由K8S 自动分配，删除Pod 时数据会被清除。用于临时空间等。
• hostPath: 将主机目录挂载到Pod。用于持久化数据。
gcePersistentDisk、awsElasticBlockStore：挂载公有云盘。
nfs、iscsi、glusterfs、rbd、gitRepo: 挂载对应的磁盘资源。
K8S声明式配置标准
• API 版本
• 善良
• 元数据
·规格
例子：
资源资源
K8S 中几乎所有对象都被抽象为资源，包括K8s 核心资源（pod、服务、命名空间等）、CRD 以及APIService 扩展资源类型。同时，K8底层将这些资源抽象为RESTful存储，而服务器则以目录（/registry/xxx）的形式存储在ETCD中。 RESTful API 接口，方便客户端资源管理（获取/发布/部署/修补/删除等）。
K8s Watch API 是一种持续监控资源变化的机制，当资源发生变化时，可以将变化实时可靠地传递到客户端，让用户可以灵活地对目标资源进行应用和操作。
e=wK%2BvD33atkTYmemmQCORdmVoY08%3D” />
容器内和K8S配置联动方式
容器内进程能获取到的外部编排的上下文信息有两个来源，环境变量和挂载项。
第一为环境变量
环境变量需要在编排期设置
第二为挂载的文件
挂载文件以及生成规则也需要在编排期设置，对于配置是否只读也可以在编排期设置选项
• 示例，比如容器想在运行时了解容器编排的一些注解信息和标签信息，基于该注解内容来控制流量策略和业务模型，那么实现可以如下方式：
K8S集群编排服务的模式梳理
DaemonSet模式
类似于守护进程一样，每个节点部署一个pod。
SideCar模式
⽣产环境中经常需要有一些通⽤的配置初始化策略，比如权限统⼀设置，类似的活⼉交由sidecar 模式的容器器进行管理，这样的容器可以只处理通用性的需求，比如统⼀将⽇志⽬录的挂载采集策略进⾏编排，将日志挂载路路径规范化，采集统⼀化;所谓的sidecar就是有一个容器器和其他容器进行了某种的共享策略，然后基于共享的内容各自负责各自的事情。
Init Container
服务的启动依赖其他容器进⾏一些初始化工作，⽐如动态生成配置⽂件，静态文件独立编译生成
后交由服务容器器使⽤。
Singleton Service
全局只能有一个Pod实例，有些特定场景的服务只能全局保证只有一个容器在干活，其他的同时处理会有资源竞争或者分布式锁的问题，因此该场景下可以考虑singleton的部署方式。
Stateful Service
有状态服务比如mysql，其数据层关系到该POD不能跟无状态图服务一样故障后重新寻找资源然后启动就OK了，有状态服务需要保证带状态的层和服务的捆绑。因此一个服务一旦对某个特定状态有依赖务必需要重点考虑其部署编排模式。
Ambassador
ambassador模式类似于代理模式，将服务基础能力通过封装的方式独立出去，然后业务逻辑通过容器内去访问，降低容器接入外部服务的成本。
动态扩缩容
扩容，缩容涉及到的维度不同工作原理与方案就不同，比如集群维度，pod维度等差异。
K8S内置了很多可以面向动态扩缩容的机制，比如基于metirc指标动态生成扩容计划
• POD的动态调整模型
• 集群的动态调整模型
其他
• K8S常用的各种命令：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#create
• k8s的watchapi整理：https://mp.weixin.qq.com/s/swmMoegiNgNHUwc67NN6AA
• kubebuilder：将多个crd整合到一起开发的项目
￮ https://github.com/kubernetes-sigs/kubebuilder
• Metacontroller：提供一个定制化的crd，但是该crd提供了各种能力的通用型扩展语义
￮ https://github.com/metacontroller/metacontroller
• jsonnet数据模板语言：https://github.com/google/jsonnet
• operatorhub：https://operatorhub.io/
• operator sdk：https://github.com/operator-framework/operator-sdk
原创文章，作者：小条，如若转载，请注明出处：https://www.sudun.com/ask/83525.html
