极客时间《云原生训练营》学习笔记。

Kubernetes 基础架构-概述

什么是 Kubernetes（K8s）

Kubernetes 是谷歌开源的容器集群管理系统，是 Google 多年大规模容器管理技术 Borg 的开源版本，主要功能包括：

• 基于容器的应用部署、维护和滚动升级；
• 负载均衡和服务发现；
• 跨机器和跨地区的集群调度；
• 自动伸缩；
• 无状态服务和有状态服务；
• 插件机制保证扩展性。

k8s功能大部分沿袭了borg它的功能，它的能力，比如说基于容器的应用部署，维护，滚动升级实现了负载均衡，和服务发现。实现了跨级群，跨地域的这种集群调度自动伸缩,可以承载有状态服务，和无状态服务.

命令式（ Imperative）vs 声明式（ Declarative）

• 命令式系统关注 “如何做”

在软件工程领域，命令式系统是写出解决某个问题、完成某个任务或者达到某个目标的明确步骤。此方法明确写出系统应该执行某指令，并且期待系统返回期望结果。

命令式一般就是交互式的系统，比如我通过cd命令可以切换目录, 比如 遥控器，

可以理解为同步任务，简单的，快速回应

• 声明式系统关注“做什么”

在软件工程领域，声明式系统指程序代码描述系统应该做什么而不是怎么做。仅限于描述要达到什么目的，如何达到目的交给系统。

生明式是 我只约定我需要做什么。但是你做怎么做我不关心，

比如 要控制空调的温度，我只能把它设定说我希望是25度，但是现在室温可能是30度，它自己控制慢慢调温，我不关心它是怎么做到的。

可以理解为异步任务， 周期长

声明式（Declaritive）系统规范

• 命令式：

  • 我要你做什么，怎么做，请严格按照我说的做。

• 声明式：

  • 我需要你帮我做点事，但是我只告诉你我需要你做什么，不是你应该怎么做。

  • 直接声明：我直接告诉你我需要什么。

  • 间接声明：我不直接告诉你我的需求，我会把我的需求放在特定的地方，请在方便的时候拿出来处理。

• 幂等性：

  • 状态固定，每次我要你做事，请给我返回相同结果。

• 面向对象的：

  • 把一切抽象成对象。

Kubernetes：声明式系统

Kubernetes 的所有管理能力构建在对象抽象的基础上，核心对象包括：

• Node：计算节点的抽象，用来描述计算节点的资源抽象、健康状态等。

  做了集群管理，对象的抽象 这个节点本身的状态是啥，我有多少的资源啊，我一共我能够提供的计算资源是多少，我可分配的计算资源是多少，这些东西都是体现在Node对象里面

• Namespace：资源隔离的基本单位，可以简单理解为文件系统中的目录结构。

  做资源隔离，解决对于用户的应用 能不能通过业务方式把多个用户不同的多个项目的对象隔离开来？

• Pod：用来描述应用实例，包括镜像地址、资源需求等。 Kubernetes 中最核心的对象，也是打通应用和基础架构的秘密武器。

  描述应用实例的。它主要包含比如说镜像地址资源需求这些信息

• Service：服务如何将应用发布成服务，本质上是负载均衡和域名服务的声明。

  服务发现，服务冶理

Kubernetes 以声明式系统为核心，也是为什么能够变成业界标准的核心原因

你可以把它理解成为

第一，抽象对象， 它定义了一堆API，是厂商中立的是一个通用的API。 第二，通过框架解决业界一些通用问题 ，它提供了一套框架来支撑，这些API，给它提供了一些最核心的功能，这些框架代码也完全是厂商中立的，它的目标是通过这种复用的核心的框架代码来解决业界的一些通用问题，那这些通用问题是什么呢？高可用怎么做？滚动升级怎么做？故障转移怎么做？扩缩绒怎么做？所有的这些这些问题的解都跟任何的厂商实现任何的技术实现没有太大关系，因为这些逻辑都是通用逻辑

Kubernetes 采用与 Borg 类似的架构

kubelet 负责把这些节点的状态上报，上报给APIServer，就是在管理节点上面的一个组件，也是整个集群的API网关， 可以看到 组件和组件之间是不通信的， 所有的组件都跟apiserver通信, 请求必须都过apiserver apiserver本身的逻辑又比较简单啊。就是认证健全和校验, 只要校验通过了那我唯一要做的事情就是把数据存起到ETCD scheduler 是做调度的 也就是说用户建一个pod那么这个pod就会被调度， controllers 是控制器， 会一直监听整个集群以及它感兴趣的一些对象，这个对象如果发生了一些变化，那么控制器就会去做一些配置的操作，用来确保整个机群的计算节点是健康的，里面跑的应用也是健康的。

架构设计原则

• 只有 APIServer 可以直接访问 etcd 存储，其他服务必须通过 Kubernetes API 来访问集群状态；
• 单节点故障不应该影响集群的状态；
• 在没有新请求的情况下，所有组件应该在故障恢复后继续执行上次最后收到的请求 （比如网络分区或服务重启等）；
• 所有组件都应该在内存中保持所需要的状态，APIServer 将状态写入 etcd 存储，而其他组件则通过 APIServer 更新并监听所有的变化；
• 优先使用事件监听而不是轮询。

引导（Bootstrapping）原则

• Self-hosting 是目标。
• 减少依赖，特别是稳态运行的依赖。
• 通过分层的原则管理依赖。
• 循环依赖问题的原则：
  • 同时还接受其他方式的数据输入（比如本地文件等），这样在其他服务不可用时还可以手动配置引导服务；
  • 状态应该是可恢复或可重新发现的；
  • 支持简单的启动临时实例来创建稳态运行所需要的状态，使用分布式锁或文 件锁等来协调不同状态的切换（通常称为 pivoting 技术）；
  • 自动重启异常退出的服务，比如副本或者进程管理器等。