k8s的pod分类、核心组件、网络模型

k8s的pod分类、核心组件、网络模型

k8s的pod分类

• 自主式Pod
  这种Pod本身是不能自我修复的，当Pod被创建后(不论是由你直接创建还是被其他Controller)，都会被Kuberentes调度到集群的Node上
  。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。Pod不会自愈。如果Pod
  运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱
  逐

• 控制器管理的Pod
  Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。Controller可 以创建和管理多个Pod，提供副本管理、滚动升级和集
  群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod,
  但是在Kubernetes中通常是使用Controller来管理Pod的

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

核心组件

HPA

我们知道，当访问量或资源需求过高时，使用：kubectl scale命令可以实现对pod的快速伸缩功能
但是我们平时工作中我们并不能提前预知访问量有多少，资源需求多少。
这就很麻烦了，总不能为了需求总是把pod设置为最多状态，这样太浪费资源；也不能当请求量上来以后再去伸缩pod，这样会有好多请求不成功。
k8s既然是云原生时代的产品，当然得有智能，自动这些特性。
所以现在引入一个新的概念：
HPA（Horizontal Pod Autoscaler ）

• 噪声处理
  通过上面的公式可以发现，Target的数目很大程度上会影响最终的结果，而在Kubernetes中，无论是变更或者升级，都更倾向于使用Recreate而不是Restart的方式进行处理。这就导致了在Deployment的生命周期中，可能会出现某一个时间，Target会由于计算了Starting或者Stopping的的Pod而变得很大。这就会给HPA的计算带来非常大的噪声，在HPA Controller的计算中，如果发现当前的对象存在Starting或者Stopping的Pod会直接跳过当前的计算周期，等待状态都变为Running再进行计算。

• 冷却周期
  在弹性伸缩中，冷却周期是不能逃避的一个话题，很多时候我们期望快速弹出与快速回收，而另一方面，我们又不希望集群震荡，所以一个弹性伸缩活动冷却周期的具体数值是多少，一直被开发者所挑战。在HPA中，默认的扩容冷却周期是3分钟，缩容冷却周期是5分钟。

• 边界值计算
  我们回到刚才的计算公式，第一次我们算出需要弹出的容器数目是5，此时扩容后整体的负载是42%，但是我们似乎忽略了一个问题，一个全新的Pod启动会不会自己就占用了部分资源？此外，8%的缓冲区是否就能够缓解整体的负载情况，要知道当一次弹性扩容完成后，下一次扩容要最少等待3分钟才可以继续扩容。为了解决这些问题，HPA引入了边界值△，目前在计算边界条件时，会自动加入10%的缓冲，这也是为什么在刚才的例子中最终的计算结果为6的原因。

有了HPA，我们就不用为上面的问题而烦恼，HPA会帮我们自动完成pod的扩缩容。
当资源需求过高时，会自动创建出pod副本；当资源需求低时，会自动收缩pod副本数。
注意：首先必须确保集群中已经安装metrics-server的组件，否则无法获取集群内资源数据，无法进行以下操作。

具体这个组件不细讲了，可以看我前面文章的介绍

在 Kubernetes 中，有两个核心的监控组件 Heapster 与 Metrics Server。Heapster 是早期 Kubernetes 社区中唯一的监控组件，它所包含的功能很强大，
通过采集 kubelet 提供的 metrics 接口，并支持监控数据的离线与归档。目前已经由metrics server 取代

接下来我们解析一下三种不同的 Metrics 与使用的场景：
Resource metrics.k8s.io Pod的资源指标，计算的时要除以Pod数目再对比阈值进行判断
Custom custom.metrics.k8s.io Object： CRD等对象的监控指标，直接计算指标比对阈值
Pods 每个Pod的自定义指标，计算时要除以Pods的数目
External external.metrics.k8s.io External：集群指标的监控指标，通常由云厂商实现


原理：
通过集群内的资源监控系统（metrics-server），来获取集群中资源的使用状态。
根据CPU、内存、以及用户自定义的资源指标数据的使用量或连接数为参考依据，来制定一个临界点，一旦超出这个点，HPA就会自动创建出pod副本，如下图

HPA通过定期（定期轮询的时间通过–horizontal-pod-autoscaler-sync-period选项来设置，默认的时间为30秒）通过Status.PodSelector来查询pods的状态，获得pod的CPU使用率。然后，通过现有pods的CPU使用率的平均值（计算方式是最近的pod使用量（最近一分钟的平均值，从metrics-serve中获得）

除以设定的每个Pod的CPU使用率限额）跟目标使用率进行比较，并且在扩容时，还要遵循预先设定的副本数限制：MinReplicas <= Replicas <= MaxReplicas。

计算扩容后Pod的个数：sum(最近一分钟内某个Pod的CPU使用率/量的平均值)/CPU使用上限的整数+1

流程
1、创建HPA资源，设定目标CPU使用率限额，以及最大、最小实例数
2、收集一组中（PodSelector）每个Pod最近一分钟内的CPU使用率，并计算平均值
3、读取HPA中设定的CPU使用限额
4、计算：平均值之和/限额，求出目标调整的实例个数
5、目标调整的实例数不能超过1中设定的最大、最小实例数，如果没有超过，则扩容；超过，则扩容至最大的实例个数
6、回到2，不断循环

service

Kubernetes Service概念

Service是kubernetes最核心的概念，通过创建Service，可以为一组具有相同功能的POD应用提供统一的访问入口，并且将请求进行负载分发到后端的各个容器应用上。

   在Kubernetes中，在受到RC调控的时候，Pod副本是变化的，对于的虚拟IP也是变化的，比如发生迁移或者伸缩的时候。这对于Pod的访问者来说是不可接受的。

   Kubernetes中的Service是一种抽象概念，它定义了一个Pod逻辑集合以及访问它们的策略，Service同Pod的关联同样是居于Label来完成的。Service的目标是提供一种桥梁， 它会为访问者提供一个固定访问地址，用于在访问时重定向到相应的后端，这使得非 Kubernetes原生应用程序，在无须为Kubemces编写特定代码的前提下，轻松访问后端。

   Service同RC一样，都是通过Label来关联Pod的。当你在Service的yaml文件中定义了该Service的selector中的label为app:my-web，那么这个Service会将Pod-->metadata-->labeks中label为app:my-web的Pod作为分发请求的后端。

  当Pod发生变化时（增加、减少、重建等），Service会及时更新。这样一来，Service就可以作为Pod的访问入口，起到代理服务器的作用，而对于访问者来说，通过Service进行访问，无需直接感知Pod。

Kubernetes Service实现方式

Kubernetes分配给Service的固定IP是一个虚拟IP，并不是一个真实的IP，在外部是无法寻址的。在真实的系统实现上，Kubernetes是通过Kube-proxy组件来实现的虚拟IP路由及转发。所以在之前集群部署的环节上，我们在每个Node上均部署了Proxy这个组件，从而实现了Kubernetes层级的虚拟转发网络。

Kubernetes通过为每个service分配一个唯一的ClusterIP，所以当使用ClusterIP：port的组合访问一个service的时候，不管port是什么，这个组合是一定不会发生重复的。另一方面，kube-proxy为每个service真正打开的是一个绝对不会重复的随机端口，用户在service描述文件中指定的访问端口会被映射到这个随机端口上。这就是为什么用户可以在创建service时随意指定访问端口。

K8S集群中，Pod的IP是在docker0网段动态分配的，当发生重启，扩容等操作时，IP地址会随之变化。当某个Pod(frontend)需要去访问其依赖的另外一组Pod(backend)时，如果backend的IP发生变化时，如何保证fronted到backend的正常通信变的非常重要，此时需要借助Service实现统一访问。

Service的Virtual VIP是由Kubernetes虚拟出来的内部网络，外部是无法寻址到的。但是有些服务又需要被外部访问到，例如web前段。这时候就需要加一层网络转发，即外网到内网的转发。Kubernetes提供了NodePort、LoadBalancer、Ingress三种方式：

• NodePort，原理是Kubernetes会在每一个Node上暴露出一个端口：nodePort，外部网络可以通过（任一Node）[NodeIP]:[NodePort]访问到后端的Service。
• LoadBalancer，在NodePort基础上，Kubernetes可以请求底层云平台创建一个负载均衡器，将每个Node作为后端，进行服务分发。该模式需要底层云平台（例如GCE）支持。
• Ingress，是一种HTTP方式的路由转发机制，由Ingress Controller和HTTP代理服务器组合而成。Ingress Controller实时监控Kubernetes API，实时更新HTTP代理服务器的转发规则。HTTP代理服务器有GCE Load-Balancer、HaProxy、Nginx等开源方案。