一 Kubernetes 是什么
Kubernetes（k8s->8代表中间的八个字母）是一个基于容器技术的分布式架构领先方案；虽然诞生时间不长，但因为是含着金钥匙🔑出生（先天的优良基因Borg以及 Google 粑粑的完美背书），所以一经开源就获得了很大的反响，并迅速称霸了容器技术领域。Kubernetes 意在提供一个能够自动化部署、可拓展、应用容器可运营的平台，对资源进行自动化，只关注 service 的状态，从而大大的减少开发 & 运维的成本。
Borg 是 Google 内部使用的一个大规模集群管理系统，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率最大化；经过十几年的打磨，Borg 已经非常完善。Kubernete 算是 Borg 的第一个开源版本。
二 为什么要用 Kubernetes
自从2013年开源的Docker项目发布之后，其以惊人的速度被企业采用，已成为容器运行的事实标准，随着容器技术的迅速发展，容器技术所带来的便利性使得实现微服务架构变得更加容易，当然趋势也必定是这样，单体应用一定会被替代；而随着微服务架构的出现，对于运维人员来说，对集群的管理则变得非常困难，虽然目前已经有很多优秀的集群管理工具，但面对Kubernetes来说，还是只能当配角；Kubernetes 给我们带来了很多牛p的功能，比如：自我修复、水平扩展、自动发布&回滚、批量处理执行等。
三 Kubernetes 架构
总体架构
Kubernetes 集群分为两类节点：Master 和 Node。在 Master 上运行 etcd、APIServer、Controller Manager 和 Scheduler，后三个节点构成总控中心，负责对集群中所有的资源进行管理和调度。在每个 Node 上运行的有 Kubelet、Proxy 和 Docker Daemon 三个组件，负责对本节点的 Pod 的生命周期的管理。
1 基本概念
✨Pod
Pod 是 Kubenetes 中的最基本的单元，包含了一个或多个紧密相关的容器，类似豌豆荚（包含一个或多个豆豆）。一个 Pod 可以被认为是一个容器化的环境的“逻辑宿主机”。之所以有 Pod 这个概念的原因是因为 Docker 容器之间的通信受到了 Docker 通信机制的限制，一个 container 需要通过 link 的方式才能访问到另外一个 container。而在 Pod 中的 containers 他们之间仅需要通过 localhost 就可以相互通信了。一个 Pod 中的 containers 共享同一组资源：
- PID 命名空间： Pod 中不同的应用程序可以看到该 Pod 中其他应用程序的进程ID
- 网络空间命名：Pod 中的多个容器能够访问同一个 IP 和 端口范围
- UTS 命名空间：Pod 中的多个 container 共享同一主机名
- Volumes：Pod 中的各个容器可以访问 Pod 级别定义的 Volumes
Pod 拥有自己的 lifecycle 以及相应的管理方式，这在后面会详细分享。
✨Node （节点）
Node 是集群中相对与 master 而言的工作主机（我们的服务会以 Pod 的形式在 Node 中运行）。Node 可以是一台物理机，也可以是一台虚拟机。每个 Node 上会运行一个用于启动和管理 Pod 的服务 —— Kubelet，并且能够被 master 管理。每个 Node 上运行的进程包括了 Kubelet、kube-proxy 和 docker daemon
✨Replication Controller (RC)
Replication Controller 是 Kubernetes 的核心概念，用于定义 Pod 的数量（可用于高可用，滚动更新...）。在 Master 内，Controller Manager 进程通过 RC 的定义来完成 Pod 的创建、监控、启停等操作。
根据 Replication Controller 的定义（yaml / json），Kubernetes 会以多退少补的原则确保在任意时刻都能运行指定的 Pod 的“副本（Repica）”数量。
✨Service
在 Kubernetes 中，每个 Pod 都会有单独的 Ip 地址，Ip 地址会随着 Pod 的销毁而结束，创建新的 Pod 时 Ip 也会改变。那么当一组 Pod 组成一个集群的时候，我们该怎么来访问呢？Service 便可以用于解决该问题，Service 可以看作成一组提供相同服务的 Pod 的对外访问接口，当外界想要访问该服务时，会直接访问到 Service（可以通过服务名称访问），然后 Service 通过负载均衡选择一个 Pod 。在每个 Pod 资源（yaml/json）被创建时可以指定一个 lebal，而创建 Service 的时候可以指定一个 match label，这样 Service 创建成功后会匹配到相同的 label 的 Pod。当 Pod 挂掉后，有新的相同的 label 的 Pod 创建后也会自动的注册到该 Servcie 上。而当 service 的 ip 改变后，会有相应的 DNS 去处理，service 的服务名称并不会改变。
service
✨Namespace （命名空间）
Namespace 会通过系统内部的对象“分配”到不同的 Namespace 中，形成逻辑上分组的不同小组，便于不同的分组在共享使用集群的资源的同时还能被分别管理，比如测试环境和生产环境完全隔离。Kubernetes 集群启动后，会创建一个命为 “default” 的 Namespace，在创建其他资源时（Pod，RC，Service...）如果没有指定 Namespace ，都会被默认分到 default 的 Namespace 中。
✨etcd
etcd 是一个高可用的 key/value 的存储系统，用于持久化存储集群中所有的资源对象，例如集群中的 Node、Service、Pod、RC、Namespace...
✨API Server
API Server 是连接其他所有服务组件的枢纽，以 REST 方式提供服务，集群中所有对资源的管理都需要通过调用 API Server 来完成。
创建 Pod 的流程
- 通过 Kubectl 提交一个创建 RC 的请求（比如 Pod 副本为1），该请求会通过API Server 被写入到 etcd 中
- Controller Manager 通过 API Server 的监听资源变化的接口监听到这个 RC 事件后，发现 集群中还没有它对应的 Pod 实例，便会根据 RC 里面的 Pod 模版细腻些定义生成一个 Pod 对象，通过 API Server 写入到 etcd 中
- 此事件被 Scheduler 发现，它会执行一个复杂的调度流程，为这个新的 Pod 选择一个 Node 落户，然后通过 API Server 保存到 etcd 中
- 目标 Node 中的 Kubelet 进程通过 API Server 监听到这个 Pod ，并根据它的定义，负责管理这个 Pod，直到这个 Pod 结束掉
创建 Service 流程
- 通过 Kubectl 提交一个映射到该 Pod 的 Service 的创建请求
- Controller Manager 会通过 Label 查询到相关联的 Pod 实例，然后生成 Service 的 Endpoints 信息并通过 API Server 写入到 etcd 中
- 所有 Node 上运行的 Proxy 进程通过 API Server 查询并监听 Service 对象与其相对应的 Endpoints 信息，从而实现 Servide 访问到后端 Pod 的转发功能。
2 各组件功能
API Server： 提供了资源对象的唯一操作入口，其他的组件都必须通过它提供的 API 来对资源进行操作。通过对资源数据的“全量查询”和“变化监听”，从而可以实时的完成业务功能。
Controller Manager：集群内部的管理控制中心，目的主要是实现 Kubernetes 集群的故障检测和恢复的自动化工作。比如根据 RC 的定义对 Pod 的管理；根据 Service 与 Pod 的关系，对服务的 Endpoints 进行管理；以及对 Node 的管理。
Scheduler：集群中的调度器，负责 Pod 在集群节点中的调度分配
Kubelet：负责当前 Node 节点上的 Pod 的管理。创建、修改、监控、删除...
Proxy：实现 Service 的代理及软件模式的负载均衡
网友评论