kubernetes设计解读

àì夳堔傛蜴生んèń 2022-03-08 12:40 312阅读 0赞

#### pod设计解读 ####

在Kubernetes中，能够被创建、调度和管理的最小单元是pod，而非单个容器。前面已经说过，一个pod是由若干个Docker容器构成的容器组(pod意为豆荚，里面容纳了多个豆子，很形象)。这里需要强调的是，pod里的容器共享network namespace，并通过volume机制共享一部分存储。

*  pod是IP等网络资源的分配的基本单位，这个IP及其对应的network namespace是由pod里的容器共享的;
 *  pod内的所有容器也共享volume。当有一个volume被挂载在同属一个pod的多个Docker容器的文件系统上时，该volume可以被这些容器共享。

另外，从Linux namespace的角度看，同属一个pod的容器还共享以下namespace。

*  IPC namespace，即同一个pod内的应用容器能够使用System V IPC或POSIX消息队列进行通信。
 *  UTS namespace，即同一个pod内的应用容器共享主机名。

同一个pod里的容器有如下两个特性:

*  通过Kubernetes volume机制，在容器之间共享存储;
 *  可以通过localhost直接访问另一个容器。

**pod的使用**

使用Kubernetes的客户端工具kubectl来创建pod，该命令行工具支持对Kubernetes对象(pod,replication controller, service)的增、删、改、查操作以及其他对集群的管理操作。创建Kubernetes资源对象的一般方法如下所示。

$ kubectl create -f obj.json

其中obj.json可以是定义pod, replication controller, service等Kubernetes对象的JSON格式的资源配置文件。

下面是一个pod类型的json文件。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70]

以上配置信息描述了一个name为podtest的对象。而该配置信息的kind字段表明该对象是一个pod。 apiVersion字段表明客户端使用的服务端API版本是v1。  
 spec:containers字段描述了pod内的容器的属性，包括:容器名(name )、镜像(image )、端口映射(ports)等。

**如何编写一个pod的描述文件**

下面详细介绍一下pod资源文件(manifest)的各个字段的含义。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 1]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 2]

![在这里插入图片描述][20190315110821809.png]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 3]

![在这里插入图片描述][20190315110904644.png]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 4]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 5]

![在这里插入图片描述][20190315111037741.png]

#### replication controller设计解读（新版本已用seplicaSet替代） ####

Kubernetes中第二个重要的概念就是replication controller，它决定了一个pod有多少同时运行的副本，并保证这些副本的期望状态与当前状态一致。所以，如果创建了一个pod，并且在希望该pod是持续运行的应用时\[即仅适用于重启策略(RestartPolicy)为Always的pod \]，一般都推荐同时给pod创建一个replication controller，让这个controller一直守护pod，直到pod被删除。

replication controller在设计上依然体现出了“旁路控制”的思想，在Kubernetes中并没有像Cloud Foundry那样设置一个专门的健康检查组件，而是为每个pod“外挂”了一个控制器进程，从而避免了健康检查组件成为性能瓶颈;即使这个控制器进程失效，容器依然可以正常运行，pod和容器无需知道这个控制器，也不会把这个控制器作为依赖。

**pod的状态转换**

在Kubernetes中，pod的状态值(podStatus)的数量和定义是系统严格保留和规定的，如表8-7所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 6]

**replication controller的描述文件**

前面已经介绍过，replication controller是Kubernetes为解决“如何构造完全同质的pod副本”问题而引人的资源对象。与pod对象类似，Kubernetes使用一份JSON格式的资源配置文件来定义一个replication controlle树象。replication controller的资源配置文件主要邮个方面组成:一个用于创建pod的pod模板(pod template )、一个期望副本数和一个用于选择被控制的pod集合的label selector。replication controller会不断地监测控制的pod集合的数量并与期望的副本数量进行比较，根据实际情况进行创建和删除pod的操作。一份定义replication controller的资源配置文件示例如下所示，该replication controller例化了两个运行nginx的pod。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 7]

**replication controller的典型场景**

*  重调度。一旦当前的宿主机节点异常崩溃或pod运行终止Kubernetes就会进行相应pod重调度。
 *  弹性伸缩。不论是通过手动还是自动弹性伸缩控制代理来修改副本数(replicas)字段，replication controller都能轻松实现pod数量的弹性伸缩。
 *  滚动更新(灰度发布)。replication controller被设计成通过逐个替换pod的方式来进行副本增删操作，这使得容器的滚动更新会非常简单。
 *  应用多版本release追踪。在生产环境中一个已经发布的应用程序同时在线多个release版本是一个很普遍的现象。通过replica selector机制，我们能很方便地实现对一个应用的多版本release进行管理。

#### service设计解读 ####

service这个概念存在的意义颇为重要，首先由于重新调度等原因，pod在Kubernetes中的IP地址不是固定的，因此需要一个代理来确保需要使用pod的应用不需要知晓pod的真实IP地址。另一个原因是当使用replication controller创建了多个pod的副本时，需要一个代理来为这些pod做负载均衡。

service主要由一个IP地址和一个label selector组成。在创建之初，每个service便被分配了一个独一无二的IP地址，该IP地址与service的生命周期相同且不再更改(pod IP地址与此不同，会随着pod的生命周期产生及消亡)。

**如何定义一个service**

和pod一样，service也是一个Kubernetes REST对象，客户端可以通过向APIServe泼送一个http POST请求来创建一个新的service实例。假设有一个pod集，该pod集中所有pod均被贴上labels\{“app”: “MyApp”\}，且所有容器均对外暴露TCP 9376端口。那么以下配置信息指定新创建一个名为myapp的service对象。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 8]

该service会将外部流量转发到所有label匹配\{“app” : “MyApp”\}的pod的9376 TCP端口上。每个service会由系统分配一个虚拟IP地址作为service的人口IP地址(cluster IP )，然后监听上述文件中的port指定的端口(比如上述的80端口)。上述虚拟IP地址和port的组合称为service入口。而当名为my-service的service对象被创建后，系统就会随之创建一个同样名为my-service的Endpoints对象，该对象即保存了所有匹配label selector端pod的IP地址和端口。

**使用service来代理遗留系统**

需要注意的是，与replication controller不同，service对象的.spec.selector属性是可选项，即允许存在没有label selector的service。这类service有什么作用呢?它们是为了让用户能够使用service代理一些并非pod，或者得不到label的资源，比如:

*  访问Kubernetes集群外部的一个数据库;
 *  访问其他namespace或者其他集群的service;
 *  任何其他类型的外部遗留系统。

在上面提到的那些场景中，可以定义一个没有selector属性的service对象，如下所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 9]

注意，因为该service没有selector属性，所以系统不会自动创建Endpoints对象。此时，可以通过自定义一个Endpoints对象，显式地将上述service对象映射到一个或多个后端(例如被代理的遗留系统地址)，如下所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 10]

这时访问该service，流量将会被分发给用户自定义的endpoints，在上面的例子中即1.2.3.4:9376。

**service的自发现机制**

Kubernetes中有一个很重要的服务自发现特性。一旦一个service被创建，该service的service IP和service port等信息都可以被注人到pod中供它们使用。Kubernetes主要支持两种service发现机制:环境变量和DNS，这与etcd集群启动时的自发现方法类似，现逐一分析如下。

*  环境变量方式
    
     kubelet创建pod时会自动添加所有可用的service环境变量到该pod中，如有需要，这些环境变量就被注人pod内的容器里。这些环境变量是诸如\{SVCNAME\}*SERVICE\_HOS下和\{SVCNAME\}* SERVICE\_PORT这样的变量，其中\{SVCNAME\}部分将service名字全部替换成大写且将破折号(-)替换成下划线(\_)。
 *  DNS方式
    
     Kubernetes集群现在支持增加一个可选的组件—DNS服务器。这个DNS服务器使用Kubernetes的watchAPI，不间断地监测新service的创建并为每个service新建一个DNS记录。如果DNS在整个集群范围内都可用，那么所有pod都能够自动解析service的域名。

**service外部可路由性设计**

为了实现service从外部可以路由，有以下3种常见的解决方案。

*  NodePort
    
     service通常分为3种类型，分别为ClusterIP, NodePort和LoadBalancer。其中，ClusterIP是最基本的类型，即在默认情况下只能在集群内部进行访问;另外两种则与实现从集群外部路由有着密不可分的联系。
    
     如果将service的类型设为NodePort，那么系统会从service-node-port-range范围中为其分配一个端口，并且在每个工作节点上都打开该端口，使得访问该端口(.spec.ports.nodesPort)即可访问到这个service。当然，用户也可以选择自定义该端口，则需要自行解决潜在的端口冲突的问题。  
     特别地，此时在集群外部使用<NodeIP>:spec.ports\[\*\].nodePort或在集群内部spec.clusterIp:spec.ports\[\*\].port均可访问到该service。
 *  loadBalancer
    
     类型为LoadBalance:的service较为特别，实际上它并不由Kubernetes集群维护，而需要云服务提供商的支持。如何将从外部loadbalancer接入的流量导到后端pod中的实现逻辑，也完全取决于具体的云服务提供商。  
     用户可以在manifest中自行定义spec.loadBalancerIP，如果运行的云服务商平台支持这一功能，则在创建loadbalancer时会依据这一字段分配IP，否则，该字段会被忽略。
 *  external IP
    
     在这个场景中，用户需要维护一个外部IP地址池(external工Ps)，并且在service的描述文件中添加externalIPs字段。注意，Kubernetes并不负责维护externalIPs的路由，而需要由集群admin或者IaaS平台等负责维护。external工Ps可以与任何service类型一起使用。

**service数据结构各属性含义**

常见的service数据结构各属性含义如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 11]

#### Deployment设计解读 ####

Deployment多用于为pod和replica set提供更新，并且可以方便地跟踪观察其所属的replica set或者pod数量以及状态的变化。换言之，Deployment是为了应用的更新而设计的。

熟悉kubectl的读者可能会产生这样的疑惑:kubectl rolling-update不是也有类似的功能吗?为什么我们需要一个独立的resource来解决这一问题呢?原因在于，kubectl rolling-update是由命令行工具(类似于前端)本身实现更新逻辑，而Deployment则将这一负担移到了服务器端(类似于后端)，由专门的controller来负责这部分工作。不仅在使用场景下得到了扩展，并且其健壮性也有了更好的保障。

**Deployment使用样例**

Deployment典型的应用场景包括：

*  定义Deployment来创建Pod和ReplicaSet
 *  滚动升级和回滚应用
 *  扩容和缩容
 *  暂停和继续Deployment

比如一个简单的nginx应用可以定义为

apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      replicas: 3
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.7.9
            ports:
            - containerPort: 80

#### DaemonSet设计解读 ####

在生产环境中，我们可能会希望在每个工作节点上都运行某个相同的pod副本，如下所示。

*  在每个工作节点上运行一个存储daemon，如glusterd, ceph等。
 *  在每个工作节点上运行一个日志收集daemon，如fluentd, logstash等。
 *  在每个工作节点上运行一个监控daemon，如collectd, New Relic agant, Ganglia gmond等。
    
    此时，我们当然可以在每个工作节点注册到集群时手动将pod绑定到节点上，或者采用其他daemon进程(如init, upstart或systemd等)直接进行管理，但是我们希望部署流程能够尽量地简单化。DaemonSet就提供这样的服务，每当一个新的工作节点加入到集群中，系统就会按照DaemonSet的配置在节点上运行相应的pod，负责这部分工作的是DaemonSet controller。

#### ConfigMap设计解读 ####

很多生产环境中的应用程序配置较为复杂，可能需要多个config文件、命令行参数和环境量的组合。并且，这些配置信息应该从应用程序镜像中解耦出来，以保证镜像的可移植性以及配置信息不被泄露。社区引入了ConfigMap这个API资源来满足这一需求。  
 ConfigMap包含了一系列的键值对，用于存储被pod或者系统组件(如controller等)访问的信息。这与Secret的设计理念有异曲同工之妙，它们的主要区别在于ConfigMap通常不用于存储敏感信息，而只存储简单的文本信息。

**创建ConfigMap**

此时，可以通过如下命令创建包含该目录下所有文件内容的ConfigMap, from-file的参数是包含文件的目录。

$ kubectl create configmap game_config --from-file=configmap
    # game_config是要创建的ConfigMap的名字
    # --from-file参数是指定数据模板文件，也可以是文件内的键值对

**使用ConfigMap中的信息**

在创建完ConfigMap后，如何使用存储在其中的信息呢?在这里介绍3种主要的方式。

*  通过环境变量调用
 *  设置命令行参数
 *  volume plugin

#### Job设计解读 ####

在Kubernetes诞生之初，其预设的服务场景基本上围绕long-running service，例如web service等。因此replication controller一开始获得了大多数用户的关注，它用来管理那些restart policy是Always的应用。  
 现在，Kubernetes已经有了专门支持batch job的资源—Job，我们可以简单地将其理解为run to completion的任务，它对应restart policy为OnFailure或者Never的应用。

**Job的类型**

根据Job中pod的数量和并发关系，我们主要将其分为3种类型。另外，在Job的定义中，有两个比较重要的参数会根据Job的不同类型有不同的配置要求，分别为.spec.completions和.spec.parallelism，也会在下文的介绍中一并展开。  
 Job的第一个适用场景非常容易想到，用户可以使用Job创建单个pod，一旦pod完成工作退出，则认为这个Job也就成功结束了。这样的Job被称为non-parellel job。对于这个类型的Job, .spec.completions和.spec.parallelism都可以不做设定，系统会默认将其设为1.  
 对于parallel job，则具体细分成两种类型，分别是有固定completion数值的parallel Job，以及有work queue的Parallel Job。

在前者中，Job成功的标志是有completion数量的pod运行成功并退出，用户需要指定.spec.completions字段。对于这种情况，用户可以指定.spec.parallelism，同样也可以不做设定，使用默认值1。

后者则是同时运行多个pod，其中任意一个pod成功停止，则说明该Job成功完成。所谓的work queue的含义在于，首先成功完成的pod对于Job的运行结果起着决定作用，而一旦有一个pod成功完成，系统不会再为这个Job试图创建新的pod。用户需要指定.spec.parallelism字段，表示在任一时刻同时运行的pod数目。如果该值被设为0，该Job不会被启动，直到该值被设为一个正值。注意，在Job的实际运行过程中，并发的pod数量可能会少于.spec.parallelism字段指定的数值。

#### Horizontal Pod Autoscaler设计解读 ####

自动扩展主要分为两种，其一为水平扩展，即本节中即将详细介绍的内容，针对于实例数目的增减;其二为垂直扩展，即单个实例可以使用的资源的增减。Horizontal Pod Autoscaling ( HPA )属于前者。

**Horizontal Pod Autoscaling如何工作**

Horizontal Pod Autoscaling的操作对象是ReplicationController, ReplicaSet或Deployment对应的pod，根据观察到的CPU实际使用量与用户的期望值进行比对，做出是否需要增减实例数量的决策。  
 controller目前使用heapster来检测CPU使用量，检测周期可以通过horizontal-pod-autoscaler-sync-period参数进行调节，默认情况下是30秒。

**Horizontal Pod Autoscaling的决策策略**

在HPA controller测到CPU的实际使用量之后，会求出当前的CPU使用率(实际使用量与pod请求量的比率)。然后，HPA controller会对比该CPU使用率和.spec.cpuUtilization.targetPercentage，并且通过调整副本数量使得CPU使用率尽量向期望值靠近，副本数的允许范围是用户设定的\[minReplicas,maxR即licas\]之间的数值，期望副本数目下argetNumOfPods通过以下计算公式求得:

TargetNumofPods=ceil(sum(CurrentPodsCPUUtilization)/Target)

其中，Target是用户在HPA的manifest中设定的.spec.cpuUtilization.targetPercentage，表示用户期望的CPU使用率，CurrentPodsCPUUtilization表示当前的CPU使用率，是HPA调节对象(可能是replication controller, deployment或者replicaSet)对应的所有的pod的平均CPU使用率。  
另外，考虑到自动扩展的决策可能需要一段时间才会生效，甚至在短时间内会引人一些噪声，例如当pod所需要的CPU负荷过大，从而运行一个新的pod进行分流，在创建的过程中，系统的CPU使用量可能会有一个攀升的过程。所以，在每一次作出决策后的一段时间内，将不再进行扩展决策。对于scale up而言，这个时间段为3分钟， scale down为5分钟。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70]: /images/20220308/2819257114ed42daa3c1862bd8e45b76.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 1]: /images/20220308/fca2dfbeeb784f8d82e953223157a368.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 2]: /images/20220308/44b7768d258947fea475b8a9678eaa77.png
[20190315110821809.png]: /images/20220308/5e1ca45e4aef435096c36980e3b4e083.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 3]: /images/20220308/2be5f5147a12430483aed9705f8c58d5.png
[20190315110904644.png]: /images/20220308/6825c29499094131a8131bdba9addbd4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 4]: /images/20220308/3b0ffb21cfb34212880c7067ee243777.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 5]: /images/20220308/1c01c6e907f84115885eff592155e7d6.png
[20190315111037741.png]: /images/20220308/1d20a8d38b9446559e66a40364c63be7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 6]: /images/20220308/64141a96689c47ca8dd1b23a46b9597f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 7]: /images/20220308/0347b03b4dab459aba52131fe5323983.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 8]: /images/20220308/a6638a68e683412a8937322b4b721fa6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 9]: /images/20220308/3e6a9605aa5a41f29ac76f30308b7e10.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 10]: /images/20220308/96e3b6f6a585499cbf141760e0a86cda.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5X2xvbmc_size_16_color_FFFFFF_t_70 11]: /images/20220308/a2ca4dfcaec6486ebc9ddf098faddb93.png