Kubernetes【一】 入坑

一 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 的流程

1. 通过 Kubectl 提交一个创建 RC 的请求（比如 Pod 副本为1），该请求会通过API Server 被写入到 etcd 中

2. Controller Manager 通过 API Server 的监听资源变化的接口监听到这个 RC 事件后，发现 集群中还没有它对应的 Pod 实例，便会根据 RC 里面的 Pod 模版细腻些定义生成一个 Pod 对象，通过 API Server 写入到 etcd 中

3. 此事件被 Scheduler 发现，它会执行一个复杂的调度流程，为这个新的 Pod 选择一个 Node 落户，然后通过 API Server 保存到 etcd 中

4. 目标 Node 中的 Kubelet 进程通过 API Server 监听到这个 Pod ，并根据它的定义，负责管理这个 Pod，直到这个 Pod 结束掉

创建 Service 流程

1. 通过 Kubectl 提交一个映射到该 Pod 的 Service 的创建请求

2. Controller Manager 会通过 Label 查询到相关联的 Pod 实例，然后生成 Service 的 Endpoints 信息并通过 API Server 写入到 etcd 中

3. 所有 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 的代理及软件模式的负载均衡

作者：司鑫
链接：https://www.jianshu.com/p/44af4eba44c6