Introduction basic of kubernetes
我们要学习 Kubernetes，就有首先了解 Kubernetes 的技术范围、基础理论知识库等，要学习 Kubernetes，肯定要有入门过程，在这个过程中，学习要从易到难，先从基础学习。
那么 Kubernetes 的入门基础内容（表示学习一门技术前先了解这门技术）包括哪些？
根据 Linux 开源基金会的认证考试，可以确认要了解 Kubernetes ，需要达成以下学习目标：
- Discuss Kubernetes.
- Learn the basic Kubernetes terminology.
- Discuss the configuration tools.
- Learn what community resources are available.
接下来笔者将一一介绍 Kubernetes 的一些概念(Discuss)、技术术语(Terminology)、相关配置工具以及社区开源资源(Community resources)。
本系列教程将会混杂一些英文，因为研究和使用 Kubernetes 的过程中，会接触到大量英文，并且 Kubernetes 的国际认证考试，都是英文考试，多接触一些英文单词，慢慢积累吧。。。
本系列教程主要参考 Linux 开源基金会的课程内容及 Kubernetes 文档，课程内容按照 Attribution 3.0 Unported (CC BY 3.0) 协议，在写作时参考、复制网站内容、共享知识库等。关于 CC BY 3.0 协议，其说明如下：
- 共享—以任何媒介或格式复制和重新分发材料
- 适应-重新混合，变换并在材料上构建
- 出于任何目的，甚至出于商业目的。
Linux 开源基金会认证考试与课程学习网址：
https://training.linuxfoundation.org/#
使用条款：
https://www.linuxfoundation.org/terms/
学习 Kubernetes 后，可以进一步考取以下认证证书：
Kubernetes 管理员认证 (CKA)、Kubernetes 应用程序开发者认证 (CKAD)、Kubernetes安全专家认证 (CKS)。
What Is Kubernetes?
我们先思考一下，运行一个 Docker 容器，只需要使用 docker run ... 命令即可，这是相当简单(relatibely simple)的方法。
但是，要实现以下场景，则是困难的：
- 跨多台主机的容器相互连接(connecting containers across multiple hosts)
- 拓展容器(scaling containers)
- 在不停机的情况下配置应用(deploying applications without downtime)
- 在多个方面进行服务发现(service discovery among several aspects)
在 2008年，LXC（Linux containers） 发布第一个版本，这是最初的容器版本；2013 年，Docker 推出了第一个版本；而 Google 则在 2014 年推出了 LMCTFY。
为了解决大集群(Cluster)中容器部署、伸缩和管理的各种问题，出现了 Kubernetes、Docker Swarm 等软件，称为 容器编排引擎。
Kubernetes 是什么？
"an open-source system for automating deployment, scaling, and management of containerized applications".
“一个自动化部署、可拓展和管理容器应用的开源系统”
Google 的基础设施在虚拟机(Virtual machines)技术普及之前就已经达到了很大的规模，高效地(Efficiency)使用集群和管理分布式应用成为 Google 挑战的核心。而容器技术提供了一种高效打包集群的解决方案。
多年来，Google 一直使用 Borg 来管理集群中的容器，积累了大量的集群管理经验和运维软件开发能力，Google 参考 Borg ，开发出了 Kubernetes，即 Borg 是 Kubernetes 的前身。（但是 Google 目前还是主要使用 Borg）。
Kubernetes 从一开始就通过一组基元(primitives)、强大的和可拓展的 API 应对这些挑战，添加新对象和控制器地能力可以很容易地地址各种各样的产品需求(production needs)。
因为 Kubernetes 这个单词不好发音，而 k 和 s 之间有 8 个单词，因此一般大家都读 k 8 s。
Kubernetes 是使用 Go 语言编写的。
当然，除了 Kubernetes ，还有 Docker Swarm、Apache Mesos、Nomad、Rancher 等软件可以监控容器状态、动态伸缩等。
Components of Kubernetes
Kubernetes 的组件分为两种，分别是 Control Plane Components(控制平面组件)、Node Components(节点组件)。
Control Plane Components 用于对集群做出全局决策；
Node Components 在节点中运行，为 Pod 提供 Kubernetes 环境。
Docker 和 Kubernetes 并不是想上就上的，这可能需要改变开发模式和系统管理方法(system administration approach)。在传统环境中，会在一台专用服务器(dedicated server)部署(Deploy)单一的应用(a monolithic application)，当业务发展后，需要更大的流量带宽、CPU和内存，这时可能对程序进行大量的定制（提高性能、缓存优化等），同时也需要更换更大的硬件(hardware)。
而在使用 Kubernetes 的解决方案中，是使用更多的小型服务器或者使用微服务的方式，去替代单一的、大型的一台服务器模式。
例如，为了保证服务可靠性，当一台主机的服务进程挂掉后，会启用另一台服务器去替代服务；如果单台服务器配置非常高，那么成本必定也会很高，这种方案的实现成本会比较高。而使用 Kubernetes 的方案中，当一台服务器或进程挂掉后，启动另一台服务器，可能只需要不到 1GB 的内存，更何况微服务可以实现应用模块解耦(decoupling)。
PS：现在大家使用的 Web 服务器应该大多数是 Nginx，Nginx 正是支持负载均衡、反向代理、多服务器配置等，非常适合微服务和多主机部署。而 Apache 的模式是使用许多 httpd 的守护进程(daemons) 去响应页面请求。
将一个单一应用拆分为多个 microservice；将一台高配置的服务器改完多态小型服务器，即 agent。接着便可以使用 Kubnentes 管理集群。而为了管理多台服务器、多个服务实例，Kubernentes 提供了各种各样的组件。
在 Kubernetes 中，在每台小型服务器上的部署的应用，我们称 microservice(逻辑上) 或 agent(等同于一台服务器)，应用的生命周期都是短暂(transient)，因为一旦出现异常，都可能被替换掉。为了使用集群中的多个 microservice，我们需要服务和 API 调用。一个服务需要连接到另一个服务，则需要 agent 跟 agent 之间通讯，例如 Web 需要连接到 数据库。 Kubernetes 和 Consul 都有服务发现和网络代理或组网的功能，Kubernetes 提供了 kube-proxy ，Consul 提供了 Consul connect ，读者可以单独查阅资料了解。
读者可以点击下面的链接了解更多 Components of Kubernetes 的知识：
https://www.vmware.com/topics/glossary/content/components-kubernetes
Kubernetes Architecture
上图是简单的 kubernetes 结构，左侧虚线方框中，称为 central manager (也叫master) ，意思是中心(central)管理器；而右侧是三个工作节点(worker node)，这些节点被称为 minions 。这两部分对应为 Master-Minions。
在 上图中， Master 由多个组件构成：
- 一个 API 服务(kube-apiserver)
- 一个调度器(kube-scheduler)
- 各种各样的控制器(上图有两个控制器)
- 一个存储系统(这个组件称为etcd)，存储集群的状态、容器的设置、网络配置等书籍
接下来我们将围绕这张图片，去学习那些 Kubernetes 中的术语和关键字。
Docker cgroup And namespace
我们知道，操作系统是以一个进程为单位进行资源调度的，现代操作系统为进程设置了资源边界，每个进程使用自己的内存区域等，进程之间不会出现内存混用。Linux 内核中，有 cgroups 和 namespaces 可以为进程定义边界，使得进程彼此隔离。
namespace
在容器中，当我们使用 top 命令或 ps 命令查看机器的进程时，可以看到进程的 Pid，每个进程一个 Pid，而机器的所有容器都具有一个 Pid = 1 的基础，但是为什么不会发生冲突？容器中的进程可以任意使用所有端口，而不同容器可以使用相同的端口，为什么不会发生冲突？这些都是命名空间可以设定边界的表现。
Linux 中，unshare 可以创建一个命名空间(实际上是一个进程，命名空间中的其它进程是这个进程的子进程)，并且创建一些资源(子进程)。为了深刻理解 Docker 中的 namespace，我们可以在 Linux 中执行：
sudo unshare --fork --pid --mount-proc bash
然后执行 ps aux 查看进程：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 23612 3556 pts/1 S 21:14 0:00 bash root 13 0.0 0.1 37624 3056 pts/1 R+ 21:14 0:00 ps aux
是不是跟 Docker 容器执行命令的结果相似？我们还可以使用 nsenter 命令进入另一个进程的命名空间。
上面的代码中，--pid 参数代码创建 pid 命名空间，但是因为并没有隔离网络，因此当我们执行 netstat --tlap 命令时，这个命名空间的网络跟其它命名空间的网络还不是隔离的。
Linux 中的 namespace 类型有：
- mount ：命名空间具有独立的挂载文件系统；
- ipc：Inter-Process Communication (进程间通讯)命名空间，具有独立的信号量、共享内存等；
- uts：命名空间具有独立的 hostname 、domainname；
- net：独立的网络，例如每个 docker 容器都有一个虚拟网卡；
- pid：独立的进程空间，空间中的进程 Pid 都从 1 开始；
- user：命名空间中有独立的用户体系，例如 Docker 中的 root 跟主机的用户不一样；
- cgroup：独立的用户分组；
Docker 中的命名空间正是依赖 Linux 内核实现的。
cgroups
cgroups 可以限制进程可使用的内存、CPU大小。cgroups 全称是 Control Groups，是 Linux 内核中的物理资源隔离机制。
为了避免篇幅过大，读者只需要知道 Docker 限制容器资源使用量、CPU 核数等操作，其原理是 Linux 内核中的 cgroups 即可，笔者这里不再赘述。
kube-apiserver
Kubernetes 通过 kube-apiserver 暴露一组 API，我们可以通过这些 API 控制 Kubernetes 的行为，而 kubernetes 有一个调用了这些 API 的本地客户端，名为 kubectl。当然，我们也可以利用这些 API 开发出跟 kubectl 一样强大的工具，例如网格管理工具 istio。
kube-scheduler
当要运行容器时，发送的请求会被调度器(kube-scheduler)转发到 API；调度器还可以寻找一个合适的节点运行这个容器。
node
集群中的每个节点都会运行着两个进程，分别是 kubelet，kube-proxy。（可以留意上图的 Kubernetes Mimons 里面）
在前面，我们知道当要运行一个容器时，需要调度器转发 API，这个请求最终会发送到 node 上的 kubelet，kubelet 可以接收 ”运行容器“ 的请求；kubelet 还可以管理那些必需的资源以及在本地节点上监控它们。
kube-proxy 可以创建和管理网络规则，以便在网络上公开容器。
Kubernetes Master 只能是 Linux，而 node 则可以是 Linux 和 Windows 等。
Terminology
本章将介绍一些 Kubenetes 的术语，以便提前了解 kubernetes 中的一些概念。本小节的内容并不会有太多解释，因为每部分要讲起来会很复杂，而这些在后面的 Kubernetes 技术中，都会单独讲解到，因此这里只是介绍一些简明的概念。读者不需要仔细看，只需要概览一遍即可。
Orchestration is managed
编排管理(Orchestration is managed) 是通过一系列的 监控循环(watch-loops)去控制或操作的；每个控制器(controller interogates) 都向 kube-apiserver 询问对象状态，然后修改它，直至达到条件。
容器编排是管理容器的最主要的技术。Dockers 也有其官方开发的 swarm 这个编排工具，但是在 2017 年的容器编排大战中，swarm 败于 Kubernetes。
namespace
Kubernetes 文档说，对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间。这里我们只需要知道，集群资源被使用名字划出来，资源之间可以隔离开，这种名字称为命名空间。当然这个命名空间跟前面提到的 Linux 内核的命名空间技术不同，读者只需要了解到两者的理念相通就行。
Pod
Pod 是 Kubernetes 中创建和管理的、最小的可部署的计算单元。
在前面的学习中，我们已经了解到 Kubernetes 是一个编排系统(orchestration system)，用于部署(deploy)和管理容器。而容器，在 一个 Pod 上运行，一个 Pod 运行着多个 容器，并且这些容器共享着 IP 地址、访问存储系统和命名空间。Kubernetes 通过命名空间让集群中的对象相互隔离开，实现资源控制和多租户(multi-tenant)连接。
Replication Controller
Replication Controller 简称 RC，应答控制器(Replication Controller) 用来部署和升级 Pod。
ReplicaSet
ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。
如果 Pod 挂了，我们可以手工重启 Pod，但是这种操作方法肯定不靠谱，不可能人力 24 小时以及瞬时执行完一系列命令。
Deployments
Deployment 提供了一种对 Pod 和 ReplicaSet 的管理方式。这里不赘述，以后需要时再提及。
Kubernetes 对象
kubernetes 对象是持久化的实体，通过这些实体，可以雕塑整个集群的状态。这里介绍一些对象信息的表示。
- 对象名称和 IDs：使用名称、UID来表示其在同类资源中的唯一性；
- 命名空间：即之前提到的 namespace；
- 标签和选择算符：标签（Labels） 是附加到 Kubernetes 对象（比如 Pods）上的键值对；
- 注解：为对象附加的非标识的元数据；
- 字段选择器：根据一个或多个资源字段的值 筛选 Kubernetes 资源；
到此这篇关于Kubernetes(K8S)入门基础内容的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持脚本之家。