- Master节点
- Node节点
- 什么是Kubernetes?
- Kubernetes与Docker
- 关于AKS - Azure Kubernetes
- Kubernetes部署
- Azure DevOps
- Helm
- Azure Kubernetes 服务 (AKS)
- K8S软件版本的定义 A.B.C
Master节点
- ApiServer：对外提供一致的API接口，其他组件可以通过接口管理Cluster的资源
- Scheduler：分配Pod具体运行到哪个Node上，调度时充分考虑Cluster的结构、负载情况，结合应用的高可用、性能、数据亲和性需求进行分配
- Controller Manager：管理Cluster的各种资源，包括replication controller/endpoints controller/namespace controller/serviceaccounts controller等
- replication controller 管理Deployment \statefulset\daemonset
- etcd：存储Cluster的配置信息、资源信息，数据变化会快速通知K8S相关组件
- Pod Network：保障Pod之间可以互相通信，flannel\calico\cannel都是一些可选方案
| Master组件 | 描述 |
|---|---|
| kube-apiserver | API server 暴露底层K8S的API。主要给管理工具提供交互方式，类似于kubectl或者dashboard。 |
| etcd | etcd是k8s内一个高可用的键值存储的数据库，用于管理K8S集群和配置的状态 |
| kube-scheduler | 当你创建或者扩缩容应用的时候，Scheduler会决定具体运行它们的节点（通过各项指标计算的得分决定）。 |
| kube-controller-manager | Controller Manager 监管许多小的controllers（developments,replicasets,cronjobs,daemonsets…） |
| Network |
Node节点
Node是pod运行的地方，Node上主要有kubelet\kube-proxy\pod network 一些组件
| Node组件 | 描述 |
|---|---|
| kubelet | 是在Node节点上的K8S agent, 主要处理应用编排请求 |
| kube-proxy | 管理维护每个Node节点的虚拟网络，proxy会给服务和Pods路由网络流量和管理IP地址 |
| container runtime | 允许容器化的应用与额外的资源进行交互，比如虚拟网络或者外部存储 |
Kubelet
Scheduler确定某一个Pod要运行到某一个Node上，会将配置信息发送给Node上的kubelet，kubelet配置后将创建和运行容器信息向Master报告运行状态
Kube-proxy
外部经过service到pod的请求，需要kube-proxy进行TCP/UDP 转发，如果有多个副本，kube-proxy负责负载均衡
Pod Network
保障Pod能相互通信
kubectl提交创建一个Pod的流程
- 通过Apiserver发送消息到Controller，Controller准备一个Deployment资源
- Scheduler调度，将Pod发送到指定Node节点
- Node节点上的kubectl创建并运行Pod
什么是Kubernetes?
-
工作原理 Kubernetes 还会自动管理服务发现、合并负载均衡、跟踪资源分配并根据计算利用率进行缩放。此外，它还会检查单个资源的运行状态，并通过自动重启或复制容器使应用自行修复 通过创建名称空间（Kubernetes 中的一种分组方法），可以让服务、Pod、控制器和卷轻松协同工作，同时将它们与群集的其他部分隔离开来
-
为什么要用
- 使工作负载可移植
- 轻松缩放容器
- 构建扩展性更强的应用
Kubernetes与Docker
- Kubernetes 与 Docker 的比较问题
- Docker 与容器化的兴起
- Kubernetes 和容器业务流程
- Kubernetes 和 Docker 有何不同？
-
Kubernetes 和 Docker - 结合使用效果更佳,容器让你只需编写一次代码即可在任何地方运行；而 Kubernetes 则让你可从单一控制界面协调和管理所有容器资源，通过结合 DevOps 做法与容器以及 Kubernetes，可以进一步实现微服务体系结构的基线，从而支持云原生应用程序的快速交付和可缩放业务流程
- 结合使用 Kubernetes 和 Docker 可以：
- 使你的基础结构更加可靠，并使应用更具高可用性。你的应用将保持联机，即使部分节点脱机也是如此。
- 使你的应用程序更具可缩放性。如果你的应用开始逐渐产生越来越多的负载，并且需要横向扩展才能提供更好的用户体验，则只需启动更多容器或向 Kubernetes 群集添加更多节点即可
用户可以轻松地运行在 Kubernetes 群集上构建的 Docker，但 Kubernetes 本身并不是一个完整的解决方案。若要在生产中优化 Kubernetes，请实现其他工具和服务来管理安全性、治理、标识和访问权限以及持续集成/持续部署 (CI/CD) 工作流和其他 DevOps 做法
关于AKS - Azure Kubernetes
- 将微服务与 AKS 配合使用 使用 AKS 简化基于微服务的体系结构的部署和管理。AKS 简化了水平缩放、自我修复、负载均衡、机密管理。
- Secure DevOps for AKS DevOps 与 Kubernetes 相得益彰。在 Azure 上同时实现安全的 DevOps 与 Kubernetes，可达到速度与安全性之间的最佳平衡，并能够快速交付大规模的代码。
Kubernetes部署
- 了解你的 Kubernetes 部署选项
- Kubernetes 部署的工作原理
- Kubernetes 部署中的内容: YAML file, Pod, ReplicaSet, kube-controller-manager, kube-scheduler
Kubernetes 推出的工作原理
- 创建一个描述群集的所需状态配置的 YAML 文件。
- 通过 kubectl（Kubernetes 命令行接口）将 YAML 文件应用到群集。
- Kubectl 将请求提交给 kube-apiserver，后者在将更改记录到数据库 etcd 之前会对请求进行身份验证和授权。
- Kube-controller-manager 持续监视系统是否有新的请求，并努力将系统状态调节至所需状态 - 在此过程中创建 ReplicaSet、部署和 Pod。
- 在所有控制器都运行之后，kube-scheduler 会看到有 Pod 处于”挂起”状态，因为它们尚未被安排在节点上运行。计划程序会为 Pod 查找合适的节点，然后与每个节- 点中的 kubelet 通信以控制并启动部署。
部署中将用到
- 创建
- 更新
- 回滚
- 扩缩容
部署策略有多种，根据资源情况、业务性能要求进行
- 滚动更新、停机更新
- 滚动更新中的并发更新数量，可用副本数量等等
滚动更新： 是默认的部署方式，一个个替换，或者多个进行替换，可以配置新Pod可用后才继续，默认是Pod启动后就替换 总体更新替换比较慢，更新完成后才能进行完整的生产测试，增加生产环境的风险
蓝绿更新： 两倍的容量要求，可以实现蓝色版本和绿色版本同时运行，绿色提供生产业务生产，蓝色提供预发测试，测试通过后蓝色逐步替代绿色 需要多一倍的资源需求，如果有弹性的资源可以这样操作
canary金丝雀更新： 通过向一小部分客户发布新版本，来测试新的服务，生产同时运行预发版本和当前版本，当运行正常达到一定条件后，扩展新版本删除旧版本。这个一定条件可以是基于指标或者人为控制。
A/B测试： AB测试与Canary版本的策略类似，将部分流量转移给特定的人，结合不同目标可以验证功能的可用性、功能的接受使用度等。通常，新版本根据 cookie、地理位置、操作系统和设备类型等因素分发给用户，并且经常与当前版本一起运行 - 在新版本证明其价值后对其进行扩展。
赤裸的运维 可以直接通过YAML或者命令行驱动K8S来更新，以及借用一些CI/CD功能串接kubectl，以Push模式来推进k8s的部署。但是也有很多云上DevOps,GitOps的解决方案，更全面地保障集群和部署流程的安全性，自行搭建也可以参照。
Azure DevOps
用于自动进行 Kubernetes 部署的完整应用程序供应链。可以更快的速度大规模交付代码，同时在速度和安全性之间实现平衡。
Helm
一种开放源代码打包工具。让你能够通过创建、共享、发布图表并设置其版本来安装、升级和管理 Kubernetes 应用程序。
Azure Kubernetes 服务 (AKS)
一种高度可用、安全且完全托管的 Kubernetes 服务。在云中部署和管理容器化应用
K8S软件版本的定义 A.B.C
每一个版本数字表明相较前一版本的兼容性：
- A-主版本，表示有不可兼容的API更新或者可能损坏向后兼容性的变化
- B-次要版本，表示功能上的更新向后兼容其他次要版本的变化
- C-补丁版本，表示修复向后兼容BUG的变化
我们常规的应用软件版本定义也可以参照这个规则
