初步认识一下Kubernetes(k8s)

K8s是什么？

K8s就是Kubernetes，因为K和s之间有8个字母，所以简称K8s
K8s是以谷歌内部容器编排管理平台Borg为原型的开源实现

• 是一个容器编排管理平台
• 是一个微服务支撑平台
• 是一个可移植的云平台

K8s作为容器管理平台

1. 以Pod（容器组）为基本的编排和调度单元以及声明式的对象配置模型（控制器、configmap、sercet等）
2. 资源配额与分配管理
3. 健康检查、自愈、伸缩与滚动升级

K8s提供了对于微服务的支撑

1. 服务发现、服务编排与内部的路由支持
2. 服务的快速部署和自动负载均衡
3. 提供对“有状态”服务的支持等

K8s是一个可移植的云平台

1. 成为了面向云原生应用的新的可移植层，即“云平台”
2. 为用户提供简单且一致化的应用化容器部署、伸缩和管理机制，形成新的、通用的应用云化模型
3. 云应用支持跨云迁移

小结：
从云原生角度，Kubernetes带来的好处：

• 容器管理，调度和编排：摆脱锁定，支持跨云
• 先进的Wordload管理之经验模型：Pod和controller
• 原生支持微服务抽象：服务注册、服务发现和自动负载均衡

为啥子需要K8s

真正的生产型应用会涉及多个容器。这些容器必须跨多个服务器主机进行部署。容器安全性需要多层部署，因此可能会比较复杂。但 Kubernetes 有助于解决这一问题。Kubernetes 可以提供所需的编排和管理功能，以便您针对这些工作负载大规模部署容器。借助 Kubernetes 编排功能，您可以构建跨多个容器的应用服务、跨集群调度、扩展这些容器，并长期持续管理这些容器的健康状况。

K8s的作用

• 跨多台主机进行容器编排。
• 更加充分地利用硬件，最大程度获取运行企业应用所需的资源。
• 有效管控应用部署和更新，并实现自动化操作。
• 挂载和增加存储，用于运行有状态的应用。
• 快速、按需扩展容器化应用及其资源。
• 对服务进行声明式管理，保证所部署的应用始终按照部署的方式运行。
• 利用自动布局、自动重启、自动复制以及自动扩展功能，对应用实施状况检查和自我修复。

随口说说K8s的架构

一个K8S系统，通常称为一个K8S集群（Cluster）。
这个集群主要包含两个部分：

• 一个Master节点（主节点）
• 一堆Node节点（计算节点）

Master节点主要是负责管理和控制。Node节点是工作负载节点，里面是具体的容器。

关于Master节点

Master节点主要由API Server、Scheduler、Controller manager构成

1. API Server：是整个系统对外的接口，提供客户端和其它组件的调用，Kubernetes 中所有的组件都会和 API Server 进行连接，组件与组件之间一般不进行独立的连接，都依赖于 API Server 进行消息的传送
2. Scheduler：负责对集群内部的资源进行调度，可以理解为调度中心，一个用户提交的 Container，依据它对 CPU、对 memory 请求大小，找一台合适的节点，进行放置

3. Controller manager：负责管理控制器，比如说对容器进行修复，以及扩容
4. etcd：是一个分布式的一个存储系统，API Server 中所需要的这些原信息都被放置在 etcd 中，etcd 本身是一个高可用系统，通过 etcd 保证整个 Kubernetes 的 Master 组件的高可用性。

关于Node节点（真正运行业务负载）

Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。

1. Pod
   Pod是K8s最基本的操作单元，一个Pod代表着集群中运行的一个进程，其内部封装了一个或多个紧密相关的容器，除了Pod之外，K8s还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口，将工作内容与容器集分离。Kubernetes 服务代理会自动将服务请求分发到正确的容器集，无论这个容器集会移到集群中的哪个位置，哪怕被替换掉。

2. Docker：主要用来创建容器

3. Kubelet：主要负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等，也是真正去运行Pod组件的部分

4. Kube-proxy：主要负责为Pod对象提供代理

5. Fluentd：主要负责日志收集、存储与查询

过程描述：
用户可以通过 UI 或者 CLI 提交一个 Pod 给 Kubernetes 进行部署，这个 Pod 请求首先会通过 CLI 或者 UI 提交给 Kubernetes API Server，下一步 API Server 会把这个信息写入到它的存储系统 etcd，之后 Scheduler 会通过 API Server 的 watch 或者叫做 notification 机制得到这个信息：有一个 Pod 需要被调度。
这个时候 Scheduler 会根据它的内存状态进行一次调度决策，在完成这次调度之后，它会向 API Server report 说：“这个 Pod 需要被调度到某一个节点上。”
这个时候 API Server 接收到这次操作之后，会把这次的结果再次写到 etcd 中，然后 API Server 会通知相应的节点进行这次 Pod 真正的执行启动。相应节点的 kubelet 会得到这个通知，kubelet 就会去调 Container runtime 来真正去启动配置这个容器和这个容器的运行环境，去调度 Storage Plugin 来去配置存储，network Plugin 去配置网络。