Kubernetes简述

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

Kubernetes一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让apache一直运行，用户不需要关心怎么去做，Kubernetes会自动去监控，然后去重启，新建，总之，让apache一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用（就像canary deployments）。

现在Kubernetes着重于不间断的服务状态（比如web服务器或者缓存服务器）和原生云平台应用（Nosql）,在不久的将来会支持各种生产云平台中的各种服务，例如，分批，工作流，以及传统数据库。

在Kubenetes中，所有的容器均在Pod中运行,一个Pod可以承载一个或者多个相关的容器，在后边的案例中，同一个Pod中的容器会部署在同一个物理机器上并且能够共享资源。一个Pod也可以包含O个或者多个磁盘卷组（volumes）,这些卷组将会以目录的形式提供给一个容器，或者被所有Pod中的容器共享，对于用户创建的每个Pod,系统会自动选择那个健康并且有足够容量的机器，然后创建类似容器的容器,当容器创建失败的时候，容器会被node agent自动的重启,这个node agent叫kubelet,但是，如果是Pod失败或者机器，它不会自动的转移并且启动，除非用户定义了 replication controller。

用户可以自己创建并管理Pod,Kubernetes将这些操作简化为两个操作：基于相同的Pod配置文件部署多个Pod复制品；创建可替代的Pod当一个Pod挂了或者机器挂了的时候。而Kubernetes API中负责来重新启动，迁移等行为的部分叫做“replication controller”，它根据一个模板生成了一个Pod,然后系统就根据用户的需求创建了许多冗余，这些冗余的Pod组成了一个整个应用，或者服务，或者服务中的一层。一旦一个Pod被创建，系统就会不停的监控Pod的健康情况以及Pod所在主机的健康情况，如果这个Pod因为软件原因挂掉了或者所在的机器挂掉了，replication controller 会自动在一个健康的机器上创建一个一摸一样的Pod,来维持原来的Pod冗余状态不变，一个应用的多个Pod可以共享一个机器。

我们经常需要选中一组Pod，例如，我们要限制一组Pod的某些操作，或者查询某组Pod的状态，作为Kubernetes的基本机制，用户可以给Kubernetes Api中的任何对象贴上一组 key:value的标签，然后，我们就可以通过标签来选择一组相关的Kubernetes Api 对象，然后去执行一些特定的操作，每个资源额外拥有一组（很多） keys 和 values,然后外部的工具可以使用这些keys和vlues值进行对象的检索，这些Map叫做annotations（注释）。

Kubernetes支持一种特殊的网络模型，Kubernetes创建了一个地址空间，并且不动态的分配端口，它可以允许用户选择任何想使用的端口，为了实现这个功能，它为每个Pod分配IP地址。

现代互联网应用一般都会包含多层服务构成，比如web前台空间与用来存储键值对的内存服务器以及对应的存储服务，为了更好的服务于这样的架构，Kubernetes提供了服务的抽象，并提供了固定的IP地址和DNS名称，而这些与一系列Pod进行动态关联，这些都通过之前提到的标签进行关联，所以我们可以关联任何我们想关联的Pod，当一个Pod中的容器访问这个地址的时候，这个请求会被转发到本地代理（kube proxy）,每台机器上均有一个本地代理，然后被转发到相应的后端容器。Kubernetes通过一种轮训机制选择相应的后端容器，这些动态的Pod被替换的时候,Kube proxy时刻追踪着，所以，服务的 IP地址（dns名称），从来不变。

所有Kubernetes中的资源，比如Pod,都通过一个叫URI的东西来区分，这个URI有一个UID,URI的重要组成部分是：对象的类型（比如pod），对象的名字，对象的命名空间，对于特殊的对象类型，在同一个命名空间内，所有的名字都是不同的，在对象只提供名称，不提供命名空间的情况下，这种情况是假定是默认的命名空间。UID是时间和空间上的唯一。

Kubernetes的核心概念

1.Master

　　k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程，关联工作节点Node。

• Kubernetes API server提供HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程；
• Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心；
• Kubernetes Schedule是负责资源调度（Pod调度）的进程

2.Node

　　Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.

每个Node节点都运行着以下一组关键进程

• kubelet：负责对Pod对于的容器的创建、启停等任务,同时与Master节点密切协作，实现集群管理的基本功能
• kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件
• Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作

　　Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会想master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，并实现高效均衡的资源调度策略。当某个node超过指定时间不上报信息时，会被master判定为失联，node的状态被标记为不可以not ready，随后master会触发“工作负载转移”的自动流程。

##查看集群中有多少node
#kubectl get nodes
NAME          STATUS                     ROLES    AGE   VERSION
10.2.33.100   Ready,SchedulingDisabled   master   40d   v1.21.0
10.2.33.101   Ready,SchedulingDisabled   master   39d   v1.21.0
10.2.33.94    Ready                      node     39d   v1.21.0
10.2.33.95    Ready                      node     40d   v1.21.0
10.2.33.96    Ready                      node     40d   v1.21.0
10.2.33.97    Ready                      node     40d   v1.21.0
10.2.33.98    Ready,SchedulingDisabled   master   40d   v1.21.0
10.2.33.99    Ready,SchedulingDisabled   master   40d   v1.21.0

##查看某个node的详细信息
#kubectl describe node 10.2.33.100
Name:               10.2.33.100        ##node名称
Roles:              master             ##标签
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=10.2.33.100
                    kubernetes.io/os=linux
                    kubernetes.io/role=master
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"5a:9b:56:32:ad:44"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 10.2.33.100
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Wed, 20 Oct 2021 16:00:04 +0800        ##创建时间
Taints:             node.kubernetes.io/unschedulable:NoSchedule    
Unschedulable:      true
Lease:
  HolderIdentity:  10.2.33.100
  AcquireTime:     <unset>
  RenewTime:       Mon, 29 Nov 2021 16:49:15 +0800
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Wed, 20 Oct 2021 16:04:47 +0800   Wed, 20 Oct 2021 16:04:47 +0800   FlannelIsUp                  Flannel is running on this node
  MemoryPressure       False   Mon, 29 Nov 2021 16:48:45 +0800   Wed, 20 Oct 2021 16:00:04 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Mon, 29 Nov 2021 16:48:45 +0800   Wed, 20 Oct 2021 16:00:04 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Mon, 29 Nov 2021 16:48:45 +0800   Wed, 20 Oct 2021 16:00:04 +0800   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Mon, 29 Nov 2021 16:48:45 +0800   Wed, 20 Oct 2021 16:00:04 +0800   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:  10.2.33.100
  Hostname:    10.2.33.100
Capacity:
  cpu:                8
  ephemeral-storage:  53986556Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             16257696Ki
  pods:               110
Allocatable:
  cpu:                8
  ephemeral-storage:  49754009928
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             15540896Ki
  pods:               110
System Info:
  Machine ID:                 8c2faca657d440bb8ba32333b96faa8d
  System UUID:                7649A1D1-D329-FD8E-E0B2-2A16BED17A5A
  Boot ID:                    ca82184b-8f1d-423d-af1f-72ab7c63fb8e
  Kernel Version:             3.10.0-862.el7.x86_64
  OS Image:                   CentOS Linux 7 (Core)
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  docker://20.10.5
  Kubelet Version:            v1.21.0
  Kube-Proxy Version:         v1.21.0
PodCIDR:                      172.20.0.0/24
PodCIDRs:                     172.20.0.0/24
Non-terminated Pods:          (3 in total)
  Namespace                   Name                                         CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                         ------------  ----------  ---------------  -------------  ---
  kube-system                 kube-flannel-ds-amd64-d5rzz                  100m (1%)     100m (1%)   50Mi (0%)        50Mi (0%)      40d
  kube-system                 node-local-dns-d6xr5                         25m (0%)      0 (0%)      5Mi (0%)         0 (0%)         40d
  monitor                     prometheus-prometheus-node-exporter-86x9l    0 (0%)        0 (0%)      0 (0%)           0 (0%)         18d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests   Limits
  --------           --------   ------
  cpu                125m (1%)  100m (1%)
  memory             55Mi (0%)  50Mi (0%)
  ephemeral-storage  0 (0%)     0 (0%)
  hugepages-1Gi      0 (0%)     0 (0%)
  hugepages-2Mi      0 (0%)     0 (0%)
Events:              <none>

3.Pod

　　运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

　　Pod其实有两种类型：普通Pod和静态Pod，后者比较特殊，它并不存在Kubernetes的etcd存储中，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动。普通Pod一旦被创建，就会被放入etcd存储中，随后会被Kubernetes Master调度到摸个具体的Node上进行绑定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器冰启动起来，在。在默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问起并且重启这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。

4.Replication Controller

　　Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

5.Service

　　Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行。

外部系统访问Service的问题

　　首先需要弄明白Kubernetes的三种IP这个问题

　　　　Node IP：Node节点的IP地址

　　　　Pod IP： Pod的IP地址

　　　　Cluster IP：Service的IP地址

　　首先,Node IP是Kubernetes集群中节点的物理网卡IP地址，所有属于这个网络的服务器之间都能通过这个网络直接通信。这也表明Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务的时候，必须通过Node IP进行通信

　　其次，Pod IP是每个Pod的IP地址，他是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络。

　　最后Cluster IP是一个虚拟的IP，但更像是一个伪造的IP网络，原因有以下几点

• Cluster IP仅仅作用于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址
• Cluster IP无法被ping，他没有一个“实体网络对象”来响应
• Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备通信的基础，并且他们属于Kubernetes集群这样一个封闭的空间。

Kubernetes集群之内，Node IP网、Pod IP网于Cluster IP网之间的通信，采用的是Kubernetes自己设计的一种编程方式的特殊路由规则。

6.Label

　Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key于value由用户自己指定。Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。

我们可以通过给指定的资源对象捆绑一个或者多个不同的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就相当于给它大了一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制

　Label Selector在Kubernetes中重要使用场景如下:

• • 　kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现副本数量始终符合预期设定的全自动控制流程
  • 　　kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service岛对应Pod的请求转发路由表，从而实现Service的智能负载均衡
  • 　　通过对某些Node定义特定的Label，并且在Pod定义文件中使用Nodeselector这种标签调度策略，kuber-scheduler进程可以实现Pod”定向调度“的特性

•Kubernetes架构和组件

Kubernetes 组件:

　　Kubernetes Master控制组件，调度管理整个系统（集群），包含如下组件:

　　1.Kubernetes API Server

　　　　作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以RESTful API接口方式提供给外部客户和内部组件调用。维护的REST对象持久化到Etcd中存储。

　　2.Kubernetes Scheduler

　　　　为新建立的Pod进行节点(node)选择(即分配机器)，负责集群的资源调度。组件抽离，可以方便替换成其他调度器。

　　3.Kubernetes Controller

　　　　负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常运行。

　　4. Replication Controller

　　　　管理维护Replication Controller，关联Replication Controller和Pod，保证Replication Controller定义的副本数量与实际运行Pod数量一致。

　　5. Node Controller

　　　　管理维护Node，定期检查Node的健康状态，标识出(失效|未失效)的Node节点。

　　6. Namespace Controller

　　　　管理维护Namespace，定期清理无效的Namespace，包括Namesapce下的API对象，比如Pod、Service等。

　　7. Service Controller

　　　　管理维护Service，提供负载以及服务代理。

　　8.EndPoints Controller

　　　　管理维护Endpoints，关联Service和Pod，创建Endpoints为Service的后端，当Pod发生变化时，实时更新Endpoints。

　　9. Service Account Controller

　　　　管理维护Service Account，为每个Namespace创建默认的Service Account，同时为Service Account创建Service Account Secret。

　　10. Persistent Volume Controller

　　　　管理维护Persistent Volume和Persistent Volume Claim，为新的Persistent Volume Claim分配Persistent Volume进行绑定，为释放的Persistent Volume执行清理回收。

　　11. Daemon Set Controller

　　　　管理维护Daemon Set，负责创建Daemon Pod，保证指定的Node上正常的运行Daemon Pod。

　　12. Deployment Controller

　　　　管理维护Deployment，关联Deployment和Replication Controller，保证运行指定数量的Pod。当Deployment更新时，控制实现Replication Controller和　Pod的更新。

　　13.Job Controller

　　　　管理维护Job，为Jod创建一次性任务Pod，保证完成Job指定完成的任务数目

　　14. Pod Autoscaler Controller

　　　　实现Pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行Pod的伸缩动作。

 Kubernetes Node运行节点，运行管理业务容器，包含如下组件:

　　1.Kubelet

　　　　负责管控容器，Kubelet会从Kubernetes API Server接收Pod的创建请求，启动和停止容器，监控容器运行状态并汇报给Kubernetes API Server。

　　2.Kubernetes Proxy

　　　　负责为Pod创建代理服务，Kubernetes Proxy会从Kubernetes API Server获取所有的Service信息，并根据Service的信息创建代理服务，实现Service到Pod的请求路由和转发，从而实现Kubernetes层级的虚拟转发网络。

　　3.Docker

　　　　Node上需要运行容器服务