K8S基础概念

一、Kubernetes入门

1.1、Kubernets是什么？

​ Kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。它是一个全新的基于容器技术的分布式架构领先方案，是一个完备的分布式系统支撑平台。

​ Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。同时，Kubernetes提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。

1.2、使用Kubernets的理由

​ 使用Kubernetes的理由很多，最重要的理由是，IT行业从来都是由新技术驱动的。

​ 当前，Docker这门容器化技术已经被很多公司采用，从单机走向集群已成为必然，云计算的蓬勃发展正在加速这一进程。Kubernetes作为当前被业界广泛认可和看好的基于Docker的大规模容器化分布式系统解决方案，得到了以谷歌为首的IT巨头们的大力宣传和持续推进。

​ 使用Kubernetes能得到的好处：

• 可以“轻装上阵”地开发复杂系统。
• 可以全面拥抱微服务架构。
• 可以随时随地将系统整体“搬迁”到公有云上。
• Kubernetes内在的服务弹性扩容机制可以让我们轻松应对突发流量。
• Kubernetes系统架构超强的横向扩容能力可以让我们的竞争力大大提升。

1.3、基本词汇概念

​ Kubernetes中的大部分概念如Node、Pod、Replication Controller、 Service等都可以被看作一种资源对象，几乎所有资源对象都可以通过 Kubernetes提供的kubectl工具(或者API编程调用)执行增、删、改、查等操作并将其保存在etcd中持久化存储。从这个角度来看，Kubernetes 其实是一个高度自动化的资源控制系统，它通过跟踪对比etcd库里保存 的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

1.3.1、Master

​ Kubernetes里的Master指的是集群控制节点，在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制，基本上 Kubernetes的所有控制命令都发给它，它负责具体的执行过程，我们后面执行的所有命令基本都是在Master上运行的。

1.3.2、Node

​ 除了Master，Kubernetes集群中的其他机器被称为Node，在较早的版本中也被称为Minion。Node是Kubernetes集群中的工作负载节点，每个 Node都会被Master分配一些工作负载(Docker容器)。
​ 关于Node有两个重要命令 kubectl get nodes和kubectl describe node [nodeName]，分别用于查看集群的Node信息和指定Node的详细情况。

1.3.3、Pod

​ Pod是Kubernetes最重要的基本概念，每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

​ Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面，即用来隔离 Docker 容器的技术。就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。

​ Kubernetes 集群中的 Pod 主要有两种用法：

• 运行单个容器的 Pod。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。

• 运行多个协同工作的容器的 Pod。 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，而另一个单独的“边车”（sidecar）容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。
  

1.3.4、Label

​ Label(标签)是Kubernetes系统中另外一个核心概念。一个Label是 一个key=value的键值对，其中key与value由用户自己指定。Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等。

​ 给某个资源对象定义一个Label， 就相当于给它打了一个标签，随后可以通过Label Selector(标签选择器)查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。

​ 使用Label可以给对象创建多组标签，Label和Label Selector 共同构成了Kubernetes系统中核心的应用模型，使得被管理对象能够被精细地分组管理，同时实现了整个集群的高可用性。

1.3.5、Replication Controller

​ RC是Kubernetes系统中的核心概念之一，简单来说，它其实定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包括如下几个部分。

• Pod期待的副本数量。
• 用于筛选目标Pod的Label Selector。
• 当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板 (template)。

​ 在我们定义了一个RC并将其提交到Kubernetes集群中后，Master上 的Controller Manager组件就得到通知，定期巡检系统中当前存活的目标 Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，如果有过多的Pod副本在运行，系统就会停掉一些Pod，否则系统会再自动创建一些 Pod。

1.3.6、Deployment

​ Deployment相对于RC的一个最大升级是我们可以随时知道当前 Pod“部署”的进度。实际上由于一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一完整过程需要一定的时间，所以我们期待系统启动N个Pod副本的目标状态，实际上是一个连续变化的“部署过程”导致的最终状态。

1.3.7、 Horizontal Pod Autoscaler

​ Horizontal Pod Autoscaling(Pod横向自动扩容，HPA)，也属于一种Kubernetes资源对象。通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定是否需要有针对性地调整目标Pod的副本数量，这是HPA的实现原理。当前，HPA有以下两种方式作为Pod负载的度量指标。

• CPUUtilizationPercentage。
• 应用程序自定义的度量指标，比如服务在每秒内的相应请求数(TPS或QPS)。

1.3.8、StatefulSet

​ Pod的管理对象RC、Deployment、DaemonSet 和Job都面向无状态的服务。但现实中有很多服务是有状态的。StatefulSet从本质上来说，可以看作 Deployment/RC的一个特殊变种，它有如下特性。

• StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka，那么第1个Pod 叫kafka-0，第2个叫kafka-1，以此类推。
• StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod 时，前n-1个Pod已经是运行且准备好的状态。
• StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷(为了保证数据的安全)。

1.3.9、Service

​ Service服务也是Kubernetes里的核心资源对象之一，Kubernetes里的ßßß每个Service其实就是我们经常提起的微服务架构中的一个微服务，之前 讲解Pod、RC等资源对象其实都是为讲解Kubernetes Service做铺垫的。

​ Kubernetes的Service定义了一个服务的访问 入口地址，前端的应用(Pod)通过这个入口地址访问其背后的一组由 Pod副本组成的集群实例，Service与其后端Pod副本集群之间则是通过 Label Selector来实现无缝对接的。RC的作用实际上是保证Service的服务 能力和服务质量始终符合预期标准。

1.3.10、Job

​ 批处理任务通常并行(或者串行)启动多个计算进程去处