Kubernetes学习之基础架构

前段时间学习 Docker 容器的一些知识，探索明白了容器的本质其实就是一个特殊的进程。

一个容器，实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境。

有了 Docker 之后，我根本不需要什么 Kubernetes，只要使用 Docker 公司的 Compose+Swarm 项目，就完全可以很方便地 DIY 出这些功能了！

所以说，如果 Kubernetes 项目只是停留在拉取用户镜像、运行容器，以及提供常见的运维功能的话，那么别说跟“原生”的 Docker Swarm 项目竞争了，哪怕跟经典的 PaaS 项目相比也难有什么优势可言。

一个技术的出现必然是用来解决领域中的某一问题，现在就行动起来，一起探讨一下这项技术能带来什么惊喜吧~

Kubernetes 定义

“

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验 的基础上，结合了社区中最好的想法和实践。——Kubernets 官网

”

其实大白话可以理解为：Kubernetes 是 Google 与 RedHat 公司共同主导开源的一个容器编排引擎。

它是基于容器的集群编排引擎，具备扩展集群、滚动升级回滚、弹性伸缩、自我修复、服务发现等多种特性能力。

Kubernetes 架构

Kubernetes 在定义核心功能的过程中，依托着 Brog^[1]项目的理论优势，架构上和Brog非常类似。

Kubernetes 是由 Master 和 Node 两种节点组成，而两种角色分别对应控制节点 和 计算节点。

核心组件介绍

控制节点：即 Master 节点，由三个紧密协作的独立组件结合而成，kube-apiserver，kube-controller-manange，kube-scheduler。整个集群的持久化数据，则由 kube-apiserver 处理后保存在 kube-etcd 中。

• kube-apiserver：负责API服务。主要提供资源操作的统一入口，屏蔽了与Etcd的直接交互；功能提供安全、注册与服务发现等。
• kube-controller-manange：负责容器的编排。资源控制中心，确保资源处于预期的工作状态。
• kube-scheduler：负责调度。按照一定的调度规则将 pod 调度到 Node 上。

计算节点：即 Node 节点，为整个集群提供计算力，是容器真正运行的地方，包括底层运行时（docker）、kubelet、kube-proxy。

• kubelet：负责容器真正运行的核心组件，主要功能包括：

• 负责 Node 节点上 Pod 创建、修改、监控、删除等生命周期的管理；
• 上报本地 Node 节点状态给 Api Server；
• 接收 Api Server 分配的任务并执行；
• 通过 Api Server 间接的与 etcd 进行通信读取集群配置信息；
• 创建、删除容器、设置容器环境变量、绑定数据卷。

• kube-proxy：为了解决外部网络能够访问集群中容器提供的应用服务设计的。

• kube-proxy 运行在每个 Node 节点上，每创建一个 Service，kube-proxy 就会从 Api Server 获取 Service 和 Endpoints 配置信息在 Node 节点上创建一个 proxy 进程监听相应的服务端口。

Deployment

Deployment 是 Pod 的多实例管理器，用于编排 Pod 的一种控制器资源。首先看看各组件在创建 deployment 资源的过程中做了什么。

• 首先是 kubectl 发起一个创建 pod 的请求；
• apiserver 接收到 deployment 发送的请求，将相关的 pod 写入 etcd，之后所有组件与 apiserver/etcd 的交互都是这样；
• deployment controller 监听到资源的变化并发起创建 replicaSet 请求；
• replicaSet 监听到资源变化并发起创建 pod 请求；
• scheduler 检测到未绑定的 pod 资源，通过一系列匹配以及过滤选择合适的 node 进行绑定；
• kubelet 发现自己 node 上需创建新 pod，负责 pod 的创建及后续生命周期管理；
• kube-proxy 负责初始化 service 相关的资源，包括服务发现、负载均衡等网络规则。

经过 kubernetes 各组件的分工协调，完成了从创建一个 deployment 请求到各个 pod 正常运行的全过程。

Pod

Pod 是 kubernetes 中你可以创建和部署的最小也是最简单的单位，Pod 代表着集群中运行的进程。

总结出一类非常常见的紧密交互的关系，也就是：这些应用之间非常频繁的交互和访问；又或者，他们会直接通过本地文件进行交互。

在常规的环境下，这些应用往往都被直接部署在同一台机器上，通过 localhost 进行通信，通过本地磁盘进行交换文件。

在 kubernetes 中这些容器会被划分为一个 Pod ， Pod 里的容器共享一个Network Namespace、同一个数据卷，从而达到高效率交换信息的目，因此有了pod。

在 kubernetes 集群中，Pod有两种使用方式：

• 一个 Pod 中运行一个容器：这种模式是最常见的用法；可以将 Pod 想象成单个容器的封装。

• 一个 Pod 中运行多个容器：一个 Pod 中的容器可以同时封装多个需要紧密交互的容器，他们之间共享资源，这些容器可以互相协作成一个 service 单位。

Service 服务

Service 服务的主要作用，就是作为 Pod 的代理入口，从而代替 Pod 对外暴露一个固定的网络地址。

为什么说是代理入口呢，举个栗子：

对于一种比较常见的需求，比如 Web 服务和数据库之间的关系。像这样的两个应用，往往故意都不会部署在同一台机器上面。

这样即使 Web 应用所在的机器宕机了，也不会影响数据库的正常使用。

可是对于容器来讲，我们知道他的地址等信息是不固定的，那么 Web 应用怎么能找到数据库容器呢？

所以这个时候 kubernetes 的做法就是给 Pod 绑定一个 Service 服务，而 Service 声明的ip地址等信息是终生不变的。

这样，对于 Web 应用的 Pod 来讲，他关心的就是数据库 Pod 的 Service 信息。

不难想象，Service 后端真正代理 Pod 的ip地址、端口等信息的自动更新、维护，则是 kubernetes 项目的职责。

小结

从容器这个最基本的概念出发，发现我们遇到了容器之间紧密交互的难题，于是产生了 Pod。

有了 Pod 之后，我们希望能一次性启动多个应用的实例，这样就需要 Deployment 这个 Pod 的多实例管理器。

有了这样一组相同的 Pod 之后，我们又需要通过一个固定的ip地址和端口以负载均衡的方式访问它，产生了 Service。

End

kubernetes 要学习的东西还有很多，一篇文章肯定是解决不了的。

后面会一点点进行学习总结，也希望大家多多支持，跟紧学习的脚步。

总结不对的地方，还请各位大佬多多指点。

如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我继续坚持下去，非常感谢！

你还可以把我的公众号设为「星标」，这样当公众号文章更新时，你会在第一时间收到推送消息，避免错过我的文章更新。

参考资料