k8s基础-了解k8s(1)

了解k8s

什么是k8s？

• 大规模集群管理系统，基于容器技术来实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。
• 基于容器技术的分布式架构领先方案，是容器云的优秀平台选型方案，已成为新一代的基于容器技术的PaaS平台的重要底层框架。
• 一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

为什么要使用k8s

1. 可以“轻装上阵”地开发复杂系统，节约开发部署运维成本。
2. 可以全面拥抱以微服务架构为核心思想的新一代容器技术的领先架构，包括基础的微服务架构，以及增强的微服务架构（如服务网格、无服务器架构等）。
3. 可以随时随地将系统整体迁移到公有云上。
4. Kubernetes内建的服务弹性扩容机制可以轻松应对突发流量。
5. 超强的横向扩容能力

基本概念和术语

k8s中的基本概念和术语大多是围绕资源对象（Resource Object）来说的，而资源对象在总体上可分为以下两类。

1. 某种资源的对象，例如节点（Node）、Pod、服务
   （Service）、存储卷（Volume）。
2. 与资源对象相关的事物与动作，例如标签（Label）、注解
   （Annotation）、命名空间（Namespace）、部署（Deployment）、HPA、PVC。

资源对象

集群类

1. Master

Master指的是集群的控制节点。在每个Kubernetes集群中都需要有一个或一组被称为Master的节点，来负责整个集群的管理和控制。

Master通常占据一个独立的服务器（在高可用部署中建议至少使用3台服务器），是整个集群的“大脑”，如果它发生宕机或者不可用，那么对集群内容器应用的管理都将无法实施。

Master上运行的关键进程：

• Kubernetes API Server（kube-apiserver）：提供HTTP RESTful API接口的主要服务，是Kubernetes里对所有资源进行增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
  
  

• Kubernetes Controller Manager（kube-controller-manager）：Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”。
  
  

• Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程，相当于公交公司的调度室。
  
  

• ETCD：服务注册发现

2. Node

Kubernetes集群中除Mater外的其他服务器被称为Node,与Master一样，Node可以是一台物理主机，也可以是一台虚拟机。Node是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他Node上。

Node上都运行着以下关键进程:

• kubelet：负责Pod对应容器的创建、启停等任务，同时与
  Master密切协作，实现集群管理的基本功能。
  
  

• kube-proxy：实现Kubernetes Service的通信与负载均衡机制的服务。
  
  

• 容器运行时（如Docker：负责本机的容器创建和管理。
  
  

Node可以在运行期间动态增加到Kubernetes集群中，前提是在这个Node上已正确安装、配置和启动了上述关键进程。

在默认情况下，kubelet会向Master注册自己，这也是Kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范畴，kubelet进程就会定时向Master汇报自身的情报，例如操作系统、主机CPU和内存使用情况，以及当前有哪些Pod在运行等，这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。

而某个Node在超过指定时间不上报信息时，会被Master判定为“失联”，该Node的状态就被标记为不可用（NotReady），Master随后会触发“工作负载大转移”的自动流程。

命名空间

命名空间，在很多情况下用于实现多租户的资源隔离，典型的一种思路就是给每个租户都分配一个命名空间。命名空间属Kubernetes集群范畴的资源对象，在一个集群里可以创建多个命名空间，每个命名空间都是相互独立的存在，属于不同命名空间的资源对象从逻辑上相互隔离。

在每个Kubernetes集群安装完成且正常运行之后，Master会自动创建两个命名空间，一个是默认的（default）、一个是系统级的（kube-system）。用户创建的资源对象如果没有指定命名空间，则被默认存放在default命名空间中；而系统相关的资源对象如网络组件、DNS组件、监控类组件等，都被安装在kube-system命名空间中。

我们可以通过命名空间将集群内部的资源对象“分配”到不同的命名空间中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时能被分别管理。当给每个租户都创建一个命名空间来实现多租户的资源隔离时，还能结合Kubernetes的资源配额管理，限定不同租户能占用的资源，例如CPU使用量、内存使用量等。

应用类

1. Service

一般说来，Service指的是无状态服务，通常由多个程序副本提供服务，在特殊情况下也可以是有状态的单实例服务，比如MySQL这种数据存储类的服务。与我们常规理解的服务不同，Kubernetes里的Service具有一个全局唯一的虚拟ClusterIP地址，Service一旦被创建，Kubernetes就会自动为它分配一个可用的ClusterIP地址，而且在Service的整个生命周期中，它的ClusterIP地址都不会改变，客户端可以通过这个虚拟IP地址+服务的端口直接访问该服务，再通过部署Kubernetes集群的DNS服务，就可以实现Service Name（域名）到ClusterIP地址的DNS映射功能，我们只要使用服务的名称（DNS名称）即可完成到目标服务的访问请求。

“服务发现”这个传统架构中的棘手问题在这里首次得以完美解决，同时，凭借ClusterIP地址的独特设计，Kubernetes进一步实现了Service的透明负载均衡和故障自动恢复的高级特性。

2. Pod

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

pause容器是实现Pod内部多容器资源共享、通信和协调的关键组件，它确保了Pod内各容器之间具有紧密耦合、一致的运行环境。同时，pause容器的存在简化了对Pod整体行为的管理和控制。

1. 创建共享网络命名空间：

   pause容器首先启动，并创建一个网络命名空间，所有该Pod内的其他业务容器都加入到这个共享的网络命名空间中。这意味着这些容器可以相互通信就如同它们在同一台主机上的进程一样，共享相同的网络栈和IP地址。

2. PID命名空间共享：

   Pod中的不同容器通过共享pause容器的PID命名空间，使得容器间能够看到彼此的进程ID。

3. IPC命名空间共享：

   在同一Pod内的容器也可以通过pause容器共享IPC命名空间，从而允许它们使用SystemV IPC或POSIX消息队列进行跨容器通信。

4. 资源隔离与管理：

   虽然pause容器本身通常是一个非常小且不执行任何实际业务逻辑的镜像（仅包含一个无限循环或暂停进程），但它作为Pod内所有容器的父进程，有助于系统管理和跟踪容器生命周期。

5. 存储卷挂载点共享：

   pause容器也是负责挂载Pod级别Volume的实体，这样同一个Pod中的多个容器就可以访问相同的持久化存储资源。

引入pod的好处

• 为多进程之间的协作提供一个抽象模型，使用Pod作为基本的
  调度、复制等管理工作的最小单位，让多个应用进程能一起有效地调度和伸缩。

• Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接
  的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。

• 采用虚拟二层网络技术，一个Pod里的容器与另外主机上的Pod容器能够直接通信。

Pod一旦被创建，就会被放入etcd中存储，随后被Kubernetes Master调度到某个具体的Node上并绑定（Binding），该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。

在默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问题并且重新启动这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，就会将这个Node上的所有Pod都重新调度到其他节点上。

Pod的IP加上这里的容器端口（containerPort）组成了一个新的概念——Endpoint，代表此Pod里的一个服务进程的对外通信地址。

3. Label与标签选择器

Label（标签）是Kubernetes系统中的另一个核心概念，相当于我们熟悉的“标签”。一个Label是一个key=value的键值对，其中的key与value由用户自己指定。

Label可以被附加到各种资源对象上，例如Node、Pod、Service、Deployment等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。

Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作，例如，部署不同版本的应用到不同的环境中，以及监控、分析应用（日志记录、监控、告警）等。

一些常用的Label示例如下。

• 版本标签：release：stable和release：canary。
• 环境标签：environment：dev、environment：qa和
  environment：production。
• 架构标签：tier：frontend、tier：backend和tier：middleware。
• 分区标签：partition：customerA和partition：customerB。
• 质量管控标签：track：daily和track：weekly。

给某个资源对象定义一个Label，就相当于给它打了一个标签，随
后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象

4. Deployment

Deployment这个资源对象可以让程序根据我们指定的模板自动创建指定数量的Pod实例。

• replicas：Pod的副本数量。
• selector：目标Pod的标签选择器。
• template：用于自动创建新Pod副本的模板。

5. Service外网访问

Kubernetes的三种IP，这三种IP分别如下。

• Node IP：Node的IP地址。
• Pod IP：Pod的IP地址。
• Service IP：Service的IP地址。

首先，Node IP是Kubernetes集群中每个节点的物理网卡的IP地址，是一个真实存在的物理网络，所有属于这个网络的服务器都能通过这个网络直接通信，不管其中是否有部分节点不属于这个Kubernetes集群。这也表明Kubernetes集群之外的节点访问Kubernetes集群内的某个节点或者TCP/IP服务时，都必须通过Node IP通信。

其次，Pod IP是每个Pod的IP地址，在使用Docker作为容器支持引擎的情况下，它是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟二层网络。前面说过，Kubernetes要求位于不同Node上的Pod都能够彼此直接通信，所以Kubernetes中一个Pod里的容器访问另外一个Pod里的容器时，就是通过Pod IP所在的虚拟二层网络进行通信的，而真实的TCP/IP流量是通过Node IP所在的物理网卡流出的。

在Kubernetes集群内，Service的ClusterIP地址属于集群内的地址，无法在集群外直接使用这个地址。为了解决这个问题，Kubernetes首先引入了NodePort这个概念，NodePort也是解决集群外的应用访问集群内服务的直接、有效的常见做法。

NodePort的实现方式是，在Kubernetes集群的每个Node上都为需要外部访问的Service开启一个对应的TCP监听端口，外部系统只要用任意一个Node的IP地址+NodePort端口号即可访问此服务，在任意Node上运行netstat命令，就可以看到有NodePort端口被监听：

但NodePort还没有完全解决外部访问Service的所有问题，比如负载均衡问题。假如在我们的集群中有10个Node，则此时最好有一个负载均衡器，外部的请求只需访问此负载均衡器的IP地址，由负载均衡器负责转发流量到后面某个Node的NodePort上

存储类

存储类的资源对象主要包括Volume、Persistent Volume、PVC和StorageClass。

首先看看基础的存储类资源对象——Volume（存储卷）。
Volume是Pod中能够被多个容器访问的共享目录。Kubernetes中的Volume概念、用途和目的与Docker中的Volume比较类似，但二者不能等价。

• Kubernetes中的Volume被定义在Pod上，被一个Pod里的多个容器挂载到具体的文件目录下；
  
  
• 其次，Kubernetes中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失；
  
  
• Kubernetes支持多种类型的Volume，例如GlusterFS、Ceph等分布式文件系统。

Volume的使用也比较简单，在大多数情况下，我们先在Pod上声明一个Volume，然后在容器里引用该Volume并将其挂载（Mount）到容器里的某个目录下。举例来说，若我们要给之前的Tomcat Pod增加一个名为datavol的Volume，并将其挂载到容器的/mydata-data目录下，则只对Pod的定义文件做如下修正即可（代码中的粗体部分）：

Kubernetes提供了非常丰富的Volume类型供容器使用，例如临时目录、宿主机目录、共享存储等

emptyDir

一个emptyDir是在Pod分配到Node时创建的。从它的名称就可以看出，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为这是Kubernetes自动分配的一个目录，当Pod从Node上移除时，emptyDir中的数据也被永久移除。

emptyDir的一些用途如下。

• 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。
• 长时间任务执行过程中使用的临时目录。
• 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。

在默认情况下，emptyDir使用的是节点的存储介质，例如磁盘或者网络存储。还可以使用emptyDir.medium属性，把这个属性设置为Memory，就可以使用更快的基于内存的后端存储了。

需要注意的是，这种情况下的emptyDir使用的内存会被计入容器的内存消耗，将受到资源限制和配额机制的管理。

hostPath

hostPath为在Pod上挂载宿主机上的文件或目录，通常可以用于以下几方面。

• 在容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统对其进行存储。
• 需要访问宿主机上Docker引擎内部数据结构的容器应用时，可以通过定义hostPath为宿主机/var/lib/docker目录，使容器内部的应用可以直接访问Docker的文件系统。

在使用这种类型的Volume时，需要注意以下几点。

• 在不同的Node上具有相同配置的Pod，可能会因为宿主机上的目录和文件不同，而导致对Volume上目录和文件的访问结果不一致。
• 如果使用了资源配额管理，则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理。

公有云Volume

公有云提供的Volume类型包括谷歌公有云提供的
GCEPersistentDisk、亚马逊公有云提供的AWS Elastic Block Store（EBSVolume）等。当我们的Kubernetes集群运行在公有云上或者使用公有云厂家提供的Kubernetes集群时，就可以使用这类Volume。

动态存储管理

Volume属于静态管理的存储，即我们需要事先定义每个Volume，然后将其挂载到Pod中去用，这种方式存在很多弊端，典型的弊端如下。

• 配置参数烦琐，存在大量手工操作，违背了Kubernetes自动化的追求目标。
• 预定义的静态Volume可能不符合目标应用的需求，比如容量问题、性能问题。

所以Kubernetes后面就发展了存储动态化的新机制，来实现存储的自动化管理。相关的核心对象（概念）有三个：Persistent Volume（简称PV）、StorageClass、PVC。
PV表示由系统动态创建（dynamically provisioned）的一个存储卷，可以被理解成Kubernetes集群中某个网络存储对应的一块存储，它与Volume类似，但PV并不是被定义在Pod上的，而是独立于Pod之外定义的。

安全类

Kubernetes里的用户有两类：我们开发的运行在Pod里的应用；普通用户，如典型的kubectl命令行工具，基本上由指定的运维人员（集群管理员）使用。在更多的情况下，我们开发的Pod应用需要通过API Server查询、创建及管理其他相关资源对象，所以这类用户才是Kubernetes的关键用户。为此，Kubernetes设计了Service Account这个特殊的资源对象，代表Pod应用的账号，为Pod提供必要的身份认证。在此基础上，Kubernetes进一步实现和完善了基于角色的访问控制权限系统——RBAC（Role-Based Access Control）。