快速了解Kubernetes

关于Kubernetes

起源

Kubernetes 源自于 Google 内部的服务编排系统 - Borg，诞生于2014年。它汲取了Google 十五年生产环境的经验积累，并融合了社区优秀的idea和实践经验。

名字

Kubernetes这个单词起源于古希腊是舵手的意思，因此它的logo是一个渔网状的七边形，里面还有一个罗盘。Google选择这样一个名字也是有必定的深意：既然docker把本身比做一只鲸鱼托着集装箱在大海中遨游，Google就要用Kubernetes去掌握去掌握大航海时代的话语权，去捕获和指引着这条鲸鱼按照主人设定的路线去巡游。

核心

得益于 Docker 的特性，服务的建立和销毁变得很是快速、简单。Kubernetes 正是以此为基础，实现了集群规模的管理、编排方案，使应用的发布、重启、扩缩容可以自动化。

---

Kubernetes的架构设计

Kubernetes 能够管理大规模的集群，使集群中的每个节点彼此链接，可以像控制一台单一的计算机同样控制整个集群。

在k8s集群中有两种角色，一种是 Master ，一种是 Node（也叫worker）：

• Master 是集群的"大脑"，负责管理整个集群，例如应用的调度、更新、扩缩容等。
• Node 就是具体"干活"的，一个Node通常是一个虚拟机或物理机，它上面事先运行着 docker 服务和 kubelet 服务（ Kubernetes 的一个组件），当接收到 master 下发的"任务"后，Node 就要去完成任务（用 docker 运行一个指定的应用）

以下图：

了解了集群中的两大角色后，咱们再看看Kubenetes的架构示意图：

Kubenetes Master节点剖析图：

在上文也说了Master节点至关于Kubenetes集群中的大脑，在Master节点具有四个主要模块：

• API Server：提供外部访问能力，使得咱们能够经过UI或CLI工具（如kubectl）与Kubenetes集群进行交互
• Scheduler：负责资源调度，当咱们在集群上建立一个容器时，该模块的调度算法会决定Pod被建立在哪一个集群节点上
• Controller：以守护进程形式存在的控制模块，相似事件循环的处理器，用于处理各类集群中的事件，控制并调节集群的指望状态。例如接收到某个服务挂掉的事件，就会自动去从新拉起这个服务，知足服务可用的状态。又或者某个服务的实例副本数是2，当挂掉一个实例时，也会自动恢复，以知足实例副本数为2这个状态
• etcd：这是一个分布式的key-value存储系统，主要用于存储Kubenetes集群的状态、资源和配置等信息

Kubenetes Node节点剖析图：

• Pod：Pod是Kubenetes集群中调度的最小单位，所谓Pod就是具备相同namespace的一个或多个container的组合
• Docker：底层的容器技术，由于除了Docker外还有其余的容器技术
• kubelet：运行在每一个节点上的主要的“节点代理”，每一个节点都会启动 kubelet 进程，用来处理 Master 节点下发到本节点的任务，按照 PodSpec 描述来管理 Pod 和其中的容器的生命周期（PodSpec 是用来描述一个 pod 的 YAML 或者 JSON 对象）。也就是说在Node中负责去调用Docker拉取镜像、运行、中止容器等工做是由 kubelet 完成的。
• kube-proxy：用于节点的网络代理，主要实现端口转发、负载均衡、service服务发现等功能
• Fluentd：负责日志的采集、存储及查询

---

Kubernetes的核心概念

Pod - Kubernetes中的最小调度单位

Kubernetes 的 Node 作的事情也并非简单的 docker run 一个容器。出于像易用性、灵活性、稳定性等的考虑，Kubernetes 提出了一个叫作 Pod 的东西，做为 Kubernetes 的最小调度单位。因此咱们的应用在每一个 Node 上运行的实际上是一个 Pod。Pod 也只能运行在 Node 上。以下图：

Pod中会包含一个或多个容器。容器自己就是一个小盒子了，Pod 至关于在容器上又包了一层小盒子。这个盒子里面的容器有什么特色呢？

• 能够直接经过 volume 共享存储。
• 有相同的网络命名空间（network namespace），通俗点说就是有同样的ip地址，有同样的网卡和网络设置。例如A容器监听了80端口，B容器监听了8080端口，A容器直接经过127.0.0.1:8080就能够访问到B容器的服务，反之亦然。
• 多个容器之间能够“了解”对方，好比知道其余人的镜像，知作别人定义的端口等。

Pause容器

每一个Pod里都会有一个特殊的Pause容器有时候也称为Infra容器，它与用户容器”捆绑“运行在同一个 Pod 中，最大的做用是维护 Pod 网络协议栈，将用户容器link到一块儿。这也是为何同一个Pod里的容器之间仅需经过localhost就能互相通讯的缘由。除此之外，Pause容器还会负责Pod的健康检查，而后汇报给k8s。

Pause容器主要为每一个用户容器提供如下功能：

• PID命名空间：Pod中的不一样应用程序能够看到其余应用程序的进程ID。
• 网络命名空间：Pod中的多个容器可以访问同一个IP和端口范围。
• IPC命名空间：Pod中的多个容器可以使用SystemV IPC或POSIX消息队列进行通讯。
• UTS命名空间：Pod中的多个容器共享一个主机名；Volumes（共享存储卷）：
  • Pod中的各个容器能够访问在Pod级别定义的Volumes。

关于Pause容器更多的内容能够参考：

• https://mp.weixin.qq.com/s/7XmskGWafUleqcjEalO9KQ

ReplicaSet（RS）

Pod的上一层是ReplicaSet（副本集），简称RS。ReplicaSet负责维护应用的实例副本，因此ReplicaSet里的每个Replica就是一个Pod而不是容器，由于Pod是最小调度单位。例如某个应用的ReplicaSet数量是2，当某一个节点上的Pod挂掉了，那么ReplicaSet就会检测到副本数量不知足2，此时k8s就会从新根据调度算法在其余节点建立并运行一个新的Pod，通俗来讲就是再拉起一个Pod。

Deployment - 应用管理者

当咱们拥有一个 Kubernetes 集群后，就能够在上面跑咱们的应用了，前提是咱们的应用必须支持在 Docker 中运行，也就是咱们要事先准备好Docker镜像。

有了镜像以后，通常咱们会经过Kubernetes的 Deployment 的配置文件去描述应用，好比应用叫什么名字、使用的镜像名字、要运行几个实例、须要多少的内存资源、cpu 资源等等。

有了配置文件就能够经过Kubernetes提供的命令行客户端 - kubectl 去管理这个应用了。kubectl 会跟 Kubernetes 的 master 经过RestAPI通讯，最终完成应用的管理。

好比咱们建立并配置好的 Deployment 配置文件叫 app.yaml，咱们就能够经过"kubectl create -f app.yaml" 命令来建立这个应用，以后就由 Kubernetes 来保证咱们的应用处于运行状态，当某个实例运行失败了或者运行着应用的 Node 忽然宕机了，Kubernetes 会自动发现并在新的 Node 上调度一个新的实例，保证咱们的应用始终达到咱们预期的结果。

RollingUpdate - 滚动升级

滚动升级是Kubernetes中最典型的服务升级方案，主要思路是一边增长新版本应用的实例数，一边减小旧版本应用的实例数，直到新版本的实例数达到预期，旧版本的实例数减小为0，滚动升级结束。在整个升级过程当中，服务一直处于可用状态。而且能够在任意时刻回滚到旧版本。

咱们之因此不会直接将应用定义为Pod，而是定义为 Deployment 的一个重要缘由就是由于只有将应用定义成 Deployment 时才能支持滚动升级。当 Deployment 中的容器须要升级更新时，Deployment 会先建立一个新的 ReplicaSet 及Pod，而后中止并删除旧的 ReplicaSet 中的一个Pod，接着再新建一个新版本Pod，而后再删除一个旧版本的Pod......以此实现滚动式的更新，因此在更新过程当中应用能够实现不中断地服务。

Service - 服务发现 - 找到每一个Pod

假设咱们上面介绍的 Deployment 建立了，Pod 也运行起来了。如何才能访问到咱们的应用呢？

最直接想到的方法就是直接经过 Pod的 ip + 端口号去访问，但若是实例数不少呢？好，拿到全部的 Pod - ip 列表，配置到负载均衡器中，轮询访问。但上面咱们说过，Pod 可能会死掉，甚至 Pod 所在的 Node 也可能宕机，Kubernetes 会自动帮咱们从新建立新的Pod。再者每次更新服务的时候也会重建 Pod。而每一个 Pod 都有本身的 ip。因此 Pod 的ip 是不稳定的，会常常变化的，不可能每次ip变化都去修改一下负载均衡中的ip列表。

面对这种变化咱们就要借助另外一个概念：Service。它就是来专门解决这个问题的。无论Deployment的Pod有多少个，无论它是更新、销毁仍是重建，Service老是能发现并维护好它的ip列表。Service对外也提供了多种入口：

• ClusterIP：Service 在集群内的惟一 ip 地址，咱们能够经过这个 ip，均衡的访问到后端的 Pod，而无须关心具体的 Pod。
• NodePort：Service 会在集群的每一个 Node 上都启动一个端口，咱们能够经过任意Node 的这个端口来访问到 Pod。
• LoadBalancer：在 NodePort 的基础上，借助公有云环境建立一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort。
• ExternalName：将服务经过 DNS CNAME 记录方式转发到指定的域名（经过 spec.externlName 设定）。

好，看似服务访问的问题解决了。但你们有没有想过，Service是如何知道它负责哪些 Pod 呢？是如何跟踪这些 Pod 变化的？

最容易想到的方法是使用 Deployment 的名字。一个 Service 对应一个 Deployment 。固然这样确实能够实现。但Kubernetes 使用了一个更加灵活、通用的设计 - Label 标签，经过给 Pod 打标签，Service 能够只负责一个 Deployment 的 Pod 也能够负责多个 Deployment 的 Pod 了。Deployment 和 Service 就能够经过 Label 解耦了。

---

Kubernetes的认证与受权

关于Kubernetes的认证与受权机制内容比较多也比较复杂，因此这里引用一些文章做为参考：

• http://www.javashuo.com/article/p-fowgtzuu-cy.html
• https://www.kuboard.cn/learning/k8s-advanced/sec/authenticate/#users-in-kubernetes
• https://www.jianshu.com/p/83330fad9b5d

也能够直接翻阅官方文档：

• https://kubernetes.io/docs/reference/access-authn-authz/authentication/