Kubernetes速成课程：掌握容器编排的精髓-CSDN博客

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

微服务演进方向

• 面向分布式设计(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用于过滤筛选podlabel在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本质上是定制化的控制器只不过控制器层面额外做了很多封装操作这些操作使得我们做定制化资源控制和服务管理时更得心应手。

CRDCustomResourceDefinition非常有用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就是有一个容器器和其他容器进行了某种的共享策略然后基于共享的内容各自负责各自的事情。