K8s-RoadMap
K8s 是什么 ?
容器编排工具，简单来讲，就是把一系列服务联合或非联合部署起来
K8s 有何优势 ？
- 多种应用混合部署以降低成本
- 管理大规模复杂应用
- 更好的应用可观测性 (容器维度，而非机器维度)
- 以 K8s 为核心的丰富的工具链
几个必须了解的词
kubectl: kubectl 是管理 k8s 集群的命令行客户端Helm3: K8s 应用打包/发布工具Docker: 容器引擎
Docker
Docker 是新时代虚拟化，云原生的基础, 尽管有多种容器化的方案，但是 Docker 目前是事实标准
Docker 的官方文档emmmm，还是看别的博客文章吧：
K8s Node/Pod/Container
Container 自然不用说，是docker中的基本概念（实例化的Image） Node 相当于物理节点，一个 Node 中可能有多个 Pod ，每个 Node 会对应一个子网段，如
10.10.10.1/24，而其中的每个 Pod 都会分配一个子网 Pod 是K8s调度的基本单位, 一个 Pod 包含几个关系紧密的 Container Pod 是 K8s 的逻辑概念，Node/Container 都是在 K8s 前已经有的概念
为何要有 Pod ? 就如 Pod 本来的含义 豌豆荚 一样，容器就是每颗豌豆
例如一个 Web网站的一个实例主要由: 一个 Nginx 容器组成，但是又想要做日志收集，又想要做指标收集，就可以额外加2个容器分别做这两件事情。 而将业务容器 Nginx, 日志收集，指标收集三个容器打包为一个Pod，因为这三个容器需要物理上在一台节点，而 Pod 这个概念可以描述这种情形。
K8s 工作负载
Deployment, StatefulSets, DaemonSet, Job, CronJob 是 K8s 常见的几种负载类型，了解这几种负载的使用场景，
并且动手去完成相关的例子，或许会对 K8s 的使用有一个认知（其实只了解Deployment在大部分时候也是够用的，但如果都会，就卷的过别人咯）
Deployment
Deployment 是最常用的无状态服务部署方式，例如 Web 网站服务。 Deployment 文档
StatefulSets
StatefulSets 是最常用的有状态服务部署方式，一般需要使用存储的服务都会是 StatefulSets，例如 数据库。 StatefulSets 文档
DaemonSet
DaemonSet 一般用于每个节点部署仅一个实例的情况，典型为 Agent，主机日志收集等。 StatefulSets 文档
Job
Job 一般用于只需运行一次的临时性工作，例如进行一次压测任务。 Job 文档
CronJob
CronJob 一般用于需要定期执行的任务，例如清理旧的数据。 CronJob 文档
PV/PVC
PV 代表了 K8s 的存储抽象概念，让单实例的有状态应用也获得了单机故障容忍能力，因为随时可以将存储/容器都切换到另一台主机。
Service/Ingress/DNS
K8s Service 代表了 K8s 的网络抽象概念 我们有时候发现，即使Pod因为故障迁移到另一台主机，服务仍然能够正常运行，便是依赖 Service 提供的能力
K8s 解决的问题:
- 一个 Pod 中的容器之间通过本地回路（loopback）通信
- 集群网络在不同 pod 之间提供通信
- Service 资源允许你对外暴露 Pods 中运行的应用程序，以支持来自于集群外部的访问
- 可以使用 Services 来发布仅供集群内部使用的服务
参考:
Ingress 是 LB 的抽象，用于将服务以统一入口暴露
调度
调度是 K8s 得以提升资源利用率的重要手段，也是大部分K8s初学者与熟练使用者的分水岭 简而言之，调度就是如何决定每一个Pod应该位于哪个节点上 有许多因素需要考虑:
- Pod 需要的资源大小, CPU/Memory
- 每个主机总资源/剩余资源大小
- 尽量分散在不同的主机/可用区，提升容灾能力
- 是否考虑就地重启
- Pod 是否必须调度到一些合适的机型 (例如有SSD硬盘)
- Pod 是否最好和其他关系紧密的 Pod 调度到相同主机
一般讲，调度会涉及到 NodeSelector 节点选择, Affinity and anti-affinity 亲和性调度
如果想要实现按照自己需求的调度，可以参考 Scheduling Framework
RBAC
RBAC 是 K8s API 的权限控制策略，在需要使用 K8s API 时会涉及，尤其是需要在容器内部访问 API 时, 通常需要赋予容器足够的权限
Helm
当应用规模变大，有许多服务需要管理的时候，Helm 是非常重要的一个工具 Helm 与 Kubectl 关系是: Helm 专门做应用部署并且很专业，可以管理比较复杂的应用。而 kubectl 部署简单的应用也是可以的，并且 Kubectl 也是管理K8s 集群的重要工具，所以 Helm 并不能替代 kubectl, 但是 Helm 可以让复杂应用的部署发布更轻松
Helm 是一个比较大并且实践性较强的 Topic，需要按照官方文档对照去练习
一定要用 Helm3，一定要用 Helm3，一定要用 Helm3
Custom Resources & Operator
Custom Resources(自定义资源) 是 K8s 得以成功的关键因素之一 使 K8s 的 API 可以得到第三方扩展，例如 Spark 利用 Custom Resources 创建了 Spark-Operator，用于更方便的创建 Spark Job
如果要开发自己的 Operator，可以参考 Operator Framework
扩展阅读
腾讯云开发者
