30分钟了解K8S

CodingFuture 2022-09-23

571

微服务演进方向

•面向分布式设计(Distribution):容器、微服务、API 驱动的开发;

•面向配置设计(Configuration):⼀个镜像，多个环境配置;

•面向韧性设计(Resistancy):故障容忍和自愈;

•面向弹性设计(Elasticity):弹性扩展和对环境变化(负载)做出响应;

•面向交付设计(Delivery):⾃动拉起，缩短交付时间;

•面向性能设计(Performance):响应式，并发和资源高效利用;

•面向自动化设计(Automation):⾃动化的DevOps;

•面向诊断性设计(Diagnosability):集群级别的日志、metric 和追踪;

•面向安全性设计(Security):安全端点、API Gateway、端到端加密;

满足微服务架构模式要求

•容器化

•服务发现

•可编排

•动态调度

•支持标准cicd

•分布式配置架构

•声明式配置

Kubernetes就是为了满足上述微服务的各种演进和特点诞生的，在K8S的设计哲学里充满了对微服务编排的各种模式的定制化支持。

K8S的特性

•Predictable Demands

￮资源使⽤

￮服务配置

￮流量控制

￮依赖管理

•Declarative Deployment

￮滚动升级

￮固定方式升级

￮蓝绿升级

￮金丝雀发布

•HealthProbe

￮健康检查：health check

￮存活检查：lineness probes (HTTP,TCP,EXEC)

￮可用性检查：readiness probe

•Managed Lifecycle

￮Signal

￮sigkill

￮Restart

￮Prestop hook

￮Poststart hook

•Automated Placement

￮面向最合适的资源进行调度

K8S各个组件的联动

Pod介绍

将多个容器打通共享隔离机制，每个pod都会包含一个paused的容器用于初始化环境，其他容器继承该容器的隔离配置

Pod基础

pod的本质是多个共享资源的容器的组合。

Pod调度的筛选策略

Pod申请资源的优先级控制机制与模型

如上图所示，三种资源分配模型各自具备一定的特点，基于模型的特点可以整合资源混合部署的优先级控制机制，增强整体集群资源的利用率

•BestEffort

•Bustable

•Guaranteed

Service

在K8集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问⼀个服务。

•label：用于过滤筛选pod，label在k8s内部会进行索引，因此检索效率非常高效，业务模型设计的时候用于过滤检索的字段可以用label表示，尽量写的所有label都是有效检索字段。

•annotations：用于注解一些label不易说清楚的事项，注意annotation不会被索引，因此不要使用annotation用来做筛选字段。

•configmap：当开发控制器或者定义容器的时候需要额外的配置，这些配置信息又无法通过label和annotation来传递，此时最好的方案就是用configmap。

流量接入

通过proxy方式

负载均衡器直接接入到service

通过ingress组件暴露接口

ETCD说明

etcd是k8s的分布式存储中心，etcd集群管理，raft协议保证一致性。

关于etcd的详细说明有一个开源电子书：https://csunny.gitbook.io/etcd/introduce

Controller控制器模型

K8S在etcd基础之上提供了一个基于事件驱动的编程模型，基于该模型可以控制资源的生命周期以及响应事件的变化做出动态调整；

控制原理示意图

Obeserve--->Analyze--->Act事件循环，k8s提供的控制器编程模型提供了可靠的基于资源的扩展协议和通用的编程模型，在该模型下可以扩展更多的通用定制化逻辑。

用shell脚本模拟控制器模式如下：

K8S Watch的事件类型补充说明一下：

Operator

operator本质上是定制化的控制器，只不过控制器层面额外做了很多封装操作，这些操作使得我们做定制化资源控制和服务管理时更得心应手。

CRD（CustomResourceDefinition）非常有用，CRD对于我们扩展K8S的接口非常有帮助，有CRD我们就可以基于K8S做更多的定制化场景的服务管控。CRD将K8S的能力和特定领域的软件的能力进行了整合，这个整合使得K8S具备了非常好的扩展空间。

一个标准的crd定义举例：

1.Name

2.API归属组

3.确定资源类型，用于识别该资源

4.名称的复数形式，用于URL：/apis/<组>/<版本>/<名称的复数形式>

5.作用域，名字空间维度或者集群维度等

6.版本

7.具体支持的版本号

8.只有一个版本会标记为存档版本，设置为true表示当前版本需要存储

9.每个版本都可以通过served表示启用与否

10.openapi的版本schema定义模式

Volume

Volume是Pod中能够被多个容器访问的共享目录,Kubernetes中的Volume与Pod⽣生命周期相同，但与容器的⽣命周期不相关,Kubernetes⽀持多种类型的Volume，并且一个Pod可以同时使用任意多个Volume。

•EmptyDir:Pod分配时创建，K8S⾃自动分配，当Pod被移除数据被清空。⽤用于临时空间等。

•hostPath: 为Pod上挂载宿主机⽬目录。⽤用于持久化数据。

￮gcePersistentDisk、awsElasticBlockStore：挂载公有云盘。

￮ nfs、iscsi、glusterfs、rbd、gitRepo:挂载相应磁盘资源。

K8S声明式配置标准

•apiVersion

•kind

•metadata

•spec

示例：

Resource资源

K8S几乎所有对象都被抽象为了资源(Resource)，包括K8s Core Resources(Pod, Service, Namespace 等)、CRD、APIService 扩展的资源类型。同时K8s 底层将这些资源统一抽象为了RESTful 的存储(Storage)，一方面服务端按目录形式(/registry/xxx) 存放在ETCD 中，另一方面也为客户端提供了RESTful API 接口，便于对资源的操作(get/post/put/patch/delete 等)。

K8s Watch API就是为资源提供的一种持续监听其变化的机制，当资源有任何变化的时候，都可以实时、顺序、可靠的传递给客户端，使得用户可以针对目标资源进行灵活应用与操作。

容器内和K8S配置联动方式

容器内进程能获取到的外部编排的上下文信息有两个来源，环境变量和挂载项。

第一为环境变量

环境变量需要在编排期设置

挂载文件以及生成规则也需要在编排期设置，对于配置是否只读也可以在编排期设置选项

•示例，比如容器想在运行时了解容器编排的一些注解信息和标签信息，基于该注解内容来控制流量策略和业务模型，那么实现可以如下方式：

K8S集群编排服务的模式梳理

DaemonSet模式

类似于守护进程一样，每个节点部署一个pod。

SideCar模式

⽣产环境中经常需要有一些通⽤的配置初始化策略，比如权限统⼀设置，类似的活⼉交由sidecar 模式的容器器进行管理，这样的容器可以只处理通用性的需求，比如统⼀将⽇志⽬录的挂载采集策略进⾏编排，将日志挂载路路径规范化，采集统⼀化;所谓的sidecar就是有一个容器器和其他容器进行了某种的共享策略，然后基于共享的内容各自负责各自的事情。