云的弹性管理

讨论对象 主要针对 Node 资源中 Pod 的调度 亲和性 概念 可以实现指定 Pod 应该调度到哪些节点上运行的调度策略，通过标签（Labels）和选择器（NodeSelectors）实现，分为硬

为什么要减小 Docker 镜像大小？ 安装不必要的软件包会增加攻击面，从而增加安全风险 镜像传输需要更多时间 部署大镜像需要更多时间 效率技巧 编写FROM时选择合适的基础镜像，以减小镜像体积 复用

构建镜像的第一条指令必须是 FROM，所以基础镜像的选择非常关键。 关注的是镜像的安全和大小 一般会选择 Alpine Busybox 的话，只包含部分 GNU 二进制文件，也就是很多 GNU 命令都

出现原因 Pods 终有一死，也就是说 Pods 也有自己的生命周期，当一个 Pod 挂了的时候，ReplicaSet 会创建新的，并且调度到合适的 Node 节点上。考虑下访问的问题，Pod 替换伴

概念和区别 声明式 API 只定义期望的状态，关注结果不关注细节，执行过程由系统按指定状态来执行，API 交付指定配置后可以做其他事情。 而命令式api需要调用者直接下达执行命令，并监控状态，再进行下

概念图 单机操作系统 这是一张传统的操作系统和 Kubernetes 的比较图。大家都知道，作为一个传统的操作系统，像 Linux 或者 Windows，它们扮演的角色，就是底层硬件的 一个抽象层。它

区别 Service 和 Ingress 负责管控 Pod 网络服务。其中，Service 负责某个服务对 Kubernetes 内部的网络访问，Ingress 则负责为来自 Kubernetes 外

概念 ReplicaSet 的作用就是管理和控制 Pod，管控他们好好干活。但是，ReplicaSet 受控于 Deployment。 从 K8S 使用者角度来看，用户会直接操作 Deployment

概念 Pod 就是 K8S 中一个服务资源的闭包。 简单来说，Pod 可以被理解成一群可以共享网络、存储和计算资源的容器化服务的集合。比如一个进程是存储和计算的闭包，一个线程是 CPU 资源（包括寄存

组件位置 一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件。 控制平面组件 API Server（在集群中表现为名称是 kubern

master节点 集群的控制平面，负责集群的决策（管理） node节点 集群的数据平面，负责为容器提供运行环境（干活）

前情 我们知道，Docker 通过将程序、依赖库、数据及 配置文件“打包固化”到一个不变的镜像文件中的做法，解决了应用的部署的难题，但这同时带来了棘手的问题，即配置文件中的参数在运行期如何修改的问题。

Replication Controller和Deployment Replication Controller 是 Kubernetes 早期版本中使用的一种资源对象，用于确保特定数量的 Pod 始

概念 Deployment 和 RC 相似度超过 90%，无论是作用、目的、Yaml 定义还是具体命令行操作，所以可以将其看作是 RC 的升级。而 Deployment 相对于 RC 的一个最大区别是

概念 Replication Controller，简称 RC，简单来说，它其实定义了一个期望的场景，即声明某种 Pod 的副本数量在任意时刻都符合某个预期值。 RC 的定义包括如下几个部分： Pod

概念 StatefulSet 则是Kubernetes中专门用于管理有状态服务的资源对象 应用场景 现实中有很多服务是有状态的，特别是 一些复杂的中间件集群，例如 MySQL 集群、MongoDB 集

概念 Namespace 在很多情况下用于实现多租户的资源隔离。分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。 作用 允许团队或项目存在于自己的虚拟集群中，

例或系统同时为多个租户（组织、用户或客户）提供服务，并将它们的数据和资源隔离开来。每个租户在系统中拥有独立的环境和资源，并且彼此之间相互隔离，使得每个租户感觉它们在使用独立的应用程序实例。 在多租户架

概念 namespace(命名空间)是linux kernel实现资源隔离的一种技术,命名空间将全局系统资源进行隔离，使命名空间内的进程看起来拥有自己的全局资源。在命名空间内对全局资源的更改对属于相同

传统部署 应用直接在物理机上部署，机器资源分配不好控制，出现Bug时，可能机器的大部分资源被某个应用占用，导致其他应用无法正常运行，无法做到应用隔离 虚拟机部署 在单个物理机上运行多个虚拟机，每个虚拟