Kubernetes连载之09 Rolling Updates Scalability and Quotas

[andy2046]

Horizontal pod autoscaling

Kubernetes可以监视你的pods，并在CPU使用率或其他指标超过阈值时对其进行缩放。自动调节资源指定细节（CPU的百分比，检查频率），如果需要，相应的自动调节控制器会调整副本的数量。

pod自动调节器不会直接创建或销毁pod。它依赖于replication controller或deployment。这非常聪明，因为你不需要处理自动调节与复制控制器相冲突的情况，或者deployments尝试扩展容器数量，而不知道自动调节器的影响。

自动调节器自动完成我们以前必须做的事情。如果没有自动调节器，如果我们有一个复制控制器，副本设置为3，但我们根据平均CPU利用率确定实际需要4，然后我们将复制控制器从3更新到4，并手动监控pods CPU利用率。autoscaler会为我们做这些。

Declaring horizontal pod autoscaler

要声明水平pod自动调节器，我们需要复制控制器或部署以及自动调节资源。这里是一个简单的复制控制器，用于维护3个nginx pod：

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
  namespace: default
spec:
  maxReplicas: 4
  minReplicas: 2
  targetCPUUtilizationPercentage: 90
  scaleTargetRef:
    apiVersion: v1
    kind: ReplicationController
    name: nginx

minReplicas和maxReplicas指定缩放范围。这是为了避免由于某些问题而可能发生的失控情况。想象一下，由于一些错误，无论实际负载如何，每个pod立即使用100％的CPU。没有maxReplicas限制，Kubernetes将继续创造更多pod直到所有群集资源耗尽为止。如果我们在虚拟机自动缩放的云环境中运行，那么我们将承担相当大的成本。这个问题的另一方面是，如果没有minReplicas并且活动暂停，那么所有的Pod可能会被终止，并且当新的请求进入时，所有的Pod将不得不被重新创建。如果存在这种经常开启和关闭活动的模式，则该循环可以重复多次。保持最小的副本运行可以平滑这种现象。在前面的示例中，minReplicas设置为2，maxReplicas设置为4.Kubernetes将确保总是有2到4个Nginx实例在运行。

目标CPU使用率百分比很难描述。我们将其缩写为TCUP。你指定单个号码，但Kubernetes在跨越阈值时不会立即开始放大或缩小。这可能会导致不断的颠簸如果TCUP在平均负载周围徘徊。相反，Kubernetes有一个容差，目前（Kubernetes 1.5）硬编码为0.1。这意味着，如果TCUP为90％，那么只有在平均CPU利用率超过99％（90 + 0.1 * 90）时才会进行扩展，并且只有平均CPU利用率低于81％时才会出现缩小比例。

Custom metrics

CPU利用率是一个重要指标，可以用来衡量受到太多请求轰炸的pod是否应该放大，或者它们大多是空闲的时候是否可以缩小。但CPU并不是唯一的，有时甚至不是追踪的最佳指标。内存可能是限制因素，或者甚至是更专业化的度量标准，例如Pod的内部磁盘队列深度，请求的平均延迟时间或平均服务超时数。

pod自定义指标是1.2版中添加的alpha扩展。当启动集群以启用自定义指标时，必须将ENABLE_CUSTOM_METRICS环境变量设置为true。由于它是一个alpha特征，它在autoscaler规范中被指定为注释。

Kubernetes要求自定义指标有一个cAdvisor端点配置。这是Kubernetes能理解的标准接口。当你将应用程序度量标准公布为cAdvisor度量标准端点时，Kubernetes可以像处理其自身的内置度量标准一样使用你的度量标准。配置自定义度量标准端点的机制是创建一个带有definition.json文件的ConfigMap，该文件将作为挂载在/etc/custom-metrics的卷使用。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-config
data:
  definition.json: "{\"endpoint\": \"http://localhost:8080/metrics\"}"

由于cAdvisor在节点级别运行，localhost端点是一个节点端点，需要pod内的容器请求主机端口和容器端口：

ports:
- hostPort: 8080
  containerPort: 8080

由于该功能的测试版状态，自定义指标被指定为注释。当自定义指标达到v1状态时，它们将作为常规字段添加。注释中的值被解释为在所有正在运行的pod上平均的目标度量值。例如，可以按如下方式添加每秒查询（qps）自定义指标：

annotations:
  alpha/target.custom-metrics.podautoscaler.kubernetes.io: '{"items":[{"name":"qps", "value": "10"}]}'

此时，自定义指标可以像内置CPU利用率百分比一样进行处理。如果所有pod的平均值超过目标值，则会添加更多pod直到最大限制。如果平均值降到目标值以下，那么pod会被摧毁到最低限制。当存在多个指标时，pod自动调节器将按比例扩大以满足最苛刻的要求。例如，如果度量A可以被三个pod满足并且度量B可以被四个pod满足，那么pod将被放大到四个副本。

默认情况下，目标CPU百分比为80.有时，你可能需要根据其他一些度量标准来调整你的pod。为了使CPU无关自动缩放决策，可以将其设置为永不会达到的荒谬值，例如999,999。现在，自动调节器将只考虑其他指标，因为CPU利用率总是低于目标CPU利用率。

Autoscaling with Kubectl

Kubectl可以使用接受配置文件的标准create命令创建一个自动缩放资源。但是Kubectl也有一个特殊的命令autoscale，它可以让你轻松地在一个命令中设置一个自动缩放器，而不需要特别的配置。

> kubectl get rc 
  NAME           DESIRED   CURRENT   READY     AGE
  bash-loop-rc   3         3         3         1m
> kubectl  autoscale rc bash-loop-rc --min=4 --max=6 --cpu-percent=50 
  replicationcontroller "bash-loop-rc" autoscaled
> kubectl get hpa
  NAME           REFERENCE    TARGET CURRENT MINPODS   MAXPODS   AGE
  bash-loop-rc   bash-loop-rc 50%    0%      4         6         7s
> kubectl get rc
  NAME           DESIRED   CURRENT   READY     AGE
  bash-loop-rc   4         4         4         7m
> kubectl  delete hpa bash-loop-rc
  horizontalpodautoscaler "bash-loop-rc" deleted

Performing rolling updates with autoscaling

滚动更新是管理大型集群的基石。Kubernetes支持replication controller或deployment级别的滚动更新。使用复制控制器滚动更新与pod autoscaler不兼容。原因在于，在滚动部署期间，会创建一个新的复制控制器，并且pod自动调节器保持绑定到旧的复制控制器。不幸的是，Kubectl rolling-update命令会触发复制控制器滚动更新。

由于滚动更新是如此重要的功能，我建议你始终将水平pod自动缩放器绑定到deployment对象，而不是replication controller或replica set。当水平pod自动调整程序绑定到deployment时，它可以在deployment规范中设置副本，并让deployment负责必要的基础滚动更新和复制。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hue-reminders
spec:
  replicas: 2
  template:
    metadata:
      name: hue-reminders
      labels:
        app: hue-reminders
    spec:
      containers:
      - name: hue-reminders
        image: g1g1/hue-reminders:v2.2
        ports:
        - containerPort: 80

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hue-reminders
  namespace: default
spec:
  maxReplicas: 15
  minReplicas: 10
  targetCPUUtilizationPercentage: 90
  scaleTargetRef:
    apiVersion: v1
    kind: Deployment
    name: hue-reminders

Alternatively, we can use the kubectl autoscale command:

> kubectl autoscale deployment hue-reminders --min=10--max=15 --cpu-percent=90

Handling scarce resources with limits and quotas

随着水平pod自动调节器即时创建pod，我们需要考虑管理我们的资源。调度可能很容易失控，资源的无效使用是一个真正的问题。有几个因素可以以微妙的方式相互影响：

• 整体集群容量
• 每个节点的资源粒度
• 每个命名空间的工作负载分区
• Daemon sets
• Stateful sets

首先，让我们了解核心问题。Kubernetes调度程序在安排pod时必须考虑所有这些因素。如果存在冲突或者有很多重叠的要求，那么Kubernetes可能会在安排新的pod时遇到问题。例如，一个非常极端但简单的情况是，DaemonSet在每个节点上运行一个需要50％可用内存的pod。现在，由于DaemonSet pod优先，Kubernetes无法安排需要超过50％内存的任何pod。即使你置备新节点，DaemonSet也会立即占用一半内存。

Stateful set与DaemonSet类似，因为它们需要扩展新节点。向Stateful sets添加新成员的触发器是数据增长，但影响是需要从Kubernetes可用池中获取资源以安排其他成员。在多租户的情况下，这个问题可能在供应或资源分配环境中发生。你可以在命名空间中精确地规划不同Pod和资源需求之间的精确比例，但是你可以与其他命名空间中的邻居共享实际节点，而这些命名空间甚至可能不具有可见性。

通过审慎地使用命名空间资源配额以及跨多种资源类型（如CPU，内存和存储）仔细管理集群容量，可以缓解大多数问题。

Enabling resource quotas

大多数Kubernetes发行版都支持资源配额。API服务器的--admission-control必须具有ResourceQuota作为其参数之一。你还必须创建一个ResourceQuota对象来执行它。请注意，每个命名空间最多可以有一个ResourceQuota对象来防止潜在的冲突。这由Kubernetes强制执行。

Resource quota types

我们可以管理和控制不同类型的配额。类别🈶️计算，存储和对象。

Compute resource quota

计算资源包括CPU和内存。对于每一个，你都可以指定一个限制或请求一定的数额。以下是计算相关字段的列表。请注意，requests.cpu只能指定为cpu，requests.memory只可以指定为内存：

• limits.cpu：在非终止状态下的所有pod中，CPU限制总和不能超过此值
• limits.memory：在非终止状态下的所有pod中，内存限制总和不能超过此值
• requests.cpu：在非终止状态下的所有pod中，CPU请求总数不能超过此值
• requests.memory：在非终止状态下的所有pod中，内存请求总数不能超过此值

Storage resource quota

存储资源配额类型稍微复杂一些。每个命名空间可以限制两个实体：存储量和持久volume声明的数量。但是，除了全局设置的总存储空间配额或持久volume声明总数之外，你还可以为每个存储类设置配额。

• requests.storage：在所有持久性卷声明中，存储请求总和不能超过此值
• persistentvolumeclaims：命名空间中可以存在的持久性卷声明的总数
• .storageclass.storage.k8s.io/requests.storage：在与存储类名关联的所有持久性卷声明中，存储请求总数不能超过此值
• .storageclass.storage.k8s.io/persistentvolumeclaims：在与存储类名关联的所有持久性卷声明中，这是可以存在于命名空间中的持久性卷声明的总数

Object count quota

Kubernetes还有另一类资源配额，即API对象。目标是保护Kubernetes API服务器免于管理太多对象。请记住，Kubernetes在底层做了很多工作。它通常需要查询多个对象进行身份验证，授权和确保操作不违反任何可能存在的许多策略。一个简单的例子是基于复制控制器的pod调度。假设您拥有1,000,000,000个复制控制器对象。也许你只有三个pod，大多数复制控制器都有零个副本。尽管如此，Kubernetes仍将花费所有时间来验证所有这些十亿个复制控制器都没有pod模板的副本，并且他们不需要杀死任何pod。这是一个极端的例子，但这个概念适用。太多的API对象对于Kubernetes来说意味着很多工作。

可以限制的多余objects有点多。例如，可以限制复制控制器的数量，但不限制副本集，这几乎是复制控制器的改进版本，但是如果副本集中有太多副本也会有相同的问题。

最明显的遗漏是命名空间。命名空间的数量没有限制。由于所有限制都是每个命名空间，因此你可以通过创建太多命名空间轻松压倒Kubernetes，其中每个命名空间只有少量的API对象。以下是所有支持的对象：

• ConfigMaps：命名空间中可以存在的配置映射的总数
• PersistentVolumeClaims：命名空间中可以存在的持久性卷声明的总数
• Pods：可以存在于命名空间中的非终止状态的Pod的总数。如果status.phase in (Failed, Succeeded)为真，则pod处于终止状态
• ReplicationControllers：命名空间中可以存在的复制控制器的总数
• ResourceQuotas：命名空间中可以存在的资源配额总数
• 服务：命名空间中可以存在的服务总数
• Services.LoadBalancers：命名空间中可以存在的负载均衡器服务的总数
• Services.NodePorts：命名空间中可以存在的节点端口服务的总数
• secrets：命名空间中可以存在的secret总数

Quota scopes

某些资源（如pods）可能处于不同的状态，对这些不同的状态配置不同的配额很有用。例如，如果有多个正在终止的Pod（这在滚动更新期间会发生），那么即使总数超过配额，也可以创建更多Pod。这可以通过仅将pod对象数量配额应用于非终止pod来实现。这里是现有的范围：

• Terminating：匹配spec.activeDeadlineSeconds >= 0的pod
• NotTerminating：匹配spec.activeDeadlineSeconds为nil的pod
• BestEffort：匹配具有best effort quality of service的Pod
• NotBestEffort：匹配没有best effort quality of service的Pod

尽管BestEffort范围仅适用于pod，但Terminating，NotTerminating和NotBestEffort范围也适用于CPU和内存。这很有趣，因为资源配额限制可以阻止pod终止。以下是支持的对象：

• cpu
• limits.cpu
• limits.memory
• memory
• pod
• requests.cpu
• requests.memory

Requests and limits

资源配额上下文中的请求和限制的含义是它要求容器明确指定目标属性。这样，Kubernetes可以管理总配额，因为它确切知道为每个容器分配的资源范围。

Working with quotas

> kubectl create namespace ns
  namespace "ns" created

Using namespace-specific context

当使用非默认空间时，我喜欢使用上下文，所以我不必为每个命令都输入--namespace = ns

> kubctl config set-context ns –cluster=minikube –user=minikube –namespace=ns
  Context "ns" set.
> kubectl config use-context ns 
  Switched to context "ns".

Creating quotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quote
spec:
  hard:
    pods: "2"
    requests.cpu: "1"
    requests.memory: 20Mi
    limits.cpu: "2"
    limits.memory: 2Gi

> kubectl create -f compute-quota.
  resourcequota "compute-quota" created

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts-quota
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"

> kubectl create -f .\object-count-quota.yaml
  resourcequota "object-counts" created
> kubectl get quota
  NAME                AGE
  compute-resources   16m
  object-counts       3m
> kubectl run nginx \
  --image=nginx \
  --replicas=1 \
  --requests=cpu=100m,memory=4Mi \
  --limits=cpu=200m,memory=8Mi \
  --namespace=ns

Using limit ranges for default compute quotas

更好的方法是指定默认计算限制。输入限制范围。

apiVersion: v1
kind: LimitRange
metadata:
  name: limits
spec:
  limits:
  - default:
      cpu: 200m
      memory: 6Mi
    defaultRequest:
      cpu: 100m
      memory: 5Mi
    type: Container

> kubectl create -f limits.yaml
  limitrange "limits" created
> kubectl describe limits limits
  Name:       limits
  Namespace:  quota-example

Choosing and managing the cluster capacity

借助Kubernetes的水平pod自动缩放，DaemonSets，stateful sets和配额，我们可以扩展和控制我们的pods，存储和其他对象。但是，最终我们受到Kubernetes集群可用的物理（虚拟）资源的限制。如果所有节点都以100％的容量运行，则需要向集群添加更多节点。没有其他办法。Kubernetes将无法扩展。另一方面，如果你有非常动态的工作负载，那么Kubernetes可以缩小你的pods，但是如果你没有相应地缩小你的节点，你仍然会支付过剩的容量。在云中，你可以停止并启动实例。

Choosing your node types

最简单的解决方案是选择具有已知数量的CPU，内存和本地存储的单个节点类型。但这通常不是最有效和最具成本效益的解决方案。它使容量规划变得简单，因为唯一的问题是需要多少个节点。无论何时添加节点，都会向集群添加已知数量的CPU和内存，但集群中的大多数Kubernetes集群和组件可处理不同的工作负载。我们可能有一个流处理管道，其中许多pod接收一些数据并在一个地方处理它。这个工作负载很重，可能需要或不需要太多的内存。其他组件（如分布式内存缓存）需要大量内存，但CPU很少。其他组件（如Cassandra集群）需要将多个SSD磁盘连接到每个节点。

对于每种类型的节点，你应该考虑适当的标签并确保Kubernetes调度被设计在该节点类型上运行的Pod。

Choosing your storage solutions

存储是扩展集群的一个重要因素。有三类可扩展存储解决方案：

• 你自给自足
• 使用你的云平台存储解决方案
• 使用集群外解决方案

当你使用自己的卷时，你可以在Kubernetes集群中安装某种类型的存储解决方案。好处是灵活性和完全控制，但你必须自己管理和扩展它。

当你使用云平台存储解决方案时，你会获得很多开箱即用的功能，但你失去了控制权，你通常会支付更多费用，你可能被锁定到该提供商的服务。

当你使用集群外解决方案时，数据传输的性能和成本可能会更高。如果你需要与现有系统集成，通常使用此选项。

大型集群可能有来自所有类别的多个数据存储。这是你必须做出的最重要决定之一，并且你的存储需求可能会随着时间的推移而发生变化和演变。

Trading off cost and response time

如果钱不是问题，你可以过度配置群集。每个节点将拥有最好的硬件配置，你将拥有比处理工作负载所需节点更多的节点，并且你将拥有大量的可用存储空间。钱永远是一个问题！

当你刚刚开始并且你的集群不能处理很多流量时，你可能会过度配置。即使两个节点大部分时间都足够用，你也可以运行五个节点。如果你有成千上万的空闲机器和PB数量的空存储，所有东西都乘以1000，有人会问为什么。因此，你要仔细衡量和优化，并且你可以获得每种资源99.99999％的利用率。恭喜，你刚刚创建了一个系统，如果没有删除请求或延迟响应，该系统无法处理额外的负载或单个节点的故障。

你需要找到中间立场。了解你的工作负载的典型波动，并考虑具有过量容量与减少响应时间或处理能力的成本/收益比。有时，如果你有严格的可用性和可靠性要求，则可以在系统中构建冗余，然后通过设计进行过度配置。例如，你希望能够在没有停机和无明显影响的情况下热插拔发生故障的组件。也许你甚至不会失去一次交易。在这种情况下，你将拥有所有关键组件的实时备份，并且可以使用额外的容量来缓解临时性的错误，而无需采取任何特殊措施。

Using effectively multiple node configurations

有效的容量规划要求你了解系统的使用模式以及每个组件可以处理的负载。这可能包括系统内部生成的大量数据流。当你对典型工作负载有深入的了解时，你可以查看工作流程以及哪些组件处理负载的哪些部分。然后，你可以计算Pod和其资源需求的数量。根据我的经验，有一些相对固定的工作负载，也有某些工作负载可能会发生可预测性变化，然后你的工作负载会非常疯狂并且行为异常。你必须根据每个工作负载进行规划，并且可以设计几个可用于安排与特定工作负载匹配的Pod的节点配置系列。

Benefiting from elastic cloud resources

Autoscaling instances

所有大型云提供商都有实例自动调节功能。不同供应商有一些差异，但基于CPU利用率的向上和向下放大总是可用的，有时还会提供自定义度量标准，有时候也会提供负载均衡。正如你所看到的，这里与Kubernetes有一些重叠。 如果你的云提供商没有足够的自动调节功能，那么自行调整相对容易，你可以监控集群资源使用情况并调用云API以添加或移除实例。你可以从Kubernetes中提取指标。

Mind your cloud quotas

在与云提供商合作时，一些最烦人的事情是配额。偶曾与四个不同的云提供商（AWS，GCP，Azure和阿里云）合作，并且在某个时候我总是被配额困扰。配额的存在让云提供商可以自己进行容量规划，但从你的角度来看，还有一件事可能会让你感到不安。想象一下，你建立了一个美丽的自动缩放系统，其功能如同魔术般突然出现，当你击中100个节点时，系统突然不会缩放。你很快就会发现你仅限于100个节点，并且你申请配额以增加支持。但是必须有人批准配额请求，这可能需要一两天的时间。同时，你的系统已经无法处理负载。

Manage regions carefully

云平台按区域和可用区进行组织。一些服务和机器配置仅在某些地区提供。云配额也在区域级进行管理。区域内数据传输的性能和成本远低于跨区域。在规划集群时，你应该仔细考虑地理分布策略。如果你需要在多个地区运行集群，则可能需要做出有关冗余，可用性，性能和成本的艰难决策。

Pushing the envelope with Kubernetes

Improving the performance and scalability of Kubernetes

Caching reads in the API server

Kubernetes在etcd中保持系统的状态，这是非常可靠的，但不是非常快。各种Kubernetes组件在该状态的快照上运行，并且不依赖于实时更新。该事实允许一些延迟以获得交易吞吐量。现在，API服务器具有用于更新状态快照的内存中读缓存。内存读缓存由etcd watches更新。这些方案显着减少了etcd的负载，并增加了API服务器的整体吞吐量。

The pod lifecycle event generator

增加集群中节点的数量对于水平可扩展性至关重要，但集群密度也非常重要。Pod密度是Kubelet可以在一个节点上有效管理的Pod数量。如果pod密度较低，则无法在一个节点上运行太多pod。这意味着你可能无法从更强大的节点中受益（每个节点的CPU和内存更多），因为Kubelet无法管理更多Pod。

Kubelet用于在其自己的goroutine中持续轮询每个pod的容器运行时间。这给容器运行时带来了很大的压力，即在性能峰值期间存在可靠性问题，尤其是CPU利用率。解决方案是Pod生命周期事件生成器（PLEG）。PLEG的工作方式是列出所有pod和容器的状态，并将其与以前的状态进行比较。这对所有的pod和容器都要进行一次。然后，通过将状态与先前的状态进行比较，PLEG知道哪个pod需要再次同步并仅调用那些pod。这一变化导致Kubelet和容器运行时显着降低4倍的CPU使用率。它还缩短了轮询时间，提高了响应速度。

Serializing API objects with protocol buffers

API服务器有一个REST API。REST API通常使用JSON作为其序列化格式，而Kubernetes API服务器也不例外。但是，JSON序列化意味着将JSON封装和解包到本地数据结构。这是一项昂贵的操作。在大型Kubernetes集群中，很多组件需要频繁查询或更新API服务器。所有JSON解析和合成的成本很快叠加起来。在Kubernetes 1.3中，Kubernetes团队添加了一个有效的协议缓冲区序列化格式。JSON格式仍然存在，但Kubernetes组件之间的所有内部通信都使用协议缓冲区序列化格式。

Measuring the performance and scalability of Kubernetes

The Kubernetes SLOs

Kubernetes具有服务级别目标（SLO）。在尝试提高性能和可扩展性时，必须遵守这些保证。Kubernetes对API调用的响应时间为1秒。这是1000毫秒。在大多数情况下，它的响应时间实际上达到快了一个数量级。

Measuring API responsiveness

API有许多不同的端点。没有简单的API响应数量，每个都必须单独测量。另外，由于系统的复杂性和分布性，结果可能会有很大的波动。一种可靠的方法是将API测量分解为单独的终点，然后随着时间的推移进行大量测试并查看百分位（这是标准实践）。

Measuring end to end pod startup time

大型动态集群最重要的性能特征之一是端到端的Pod启动时间。Kubernetes在任何时候都会创造，销毁和重组pod。你可以说Kubernetes的主要功能是安排pod。

Testing Kubernetes at scale

Kubemark是一个Kubernetes集群，运行模拟节点，称为空心节点，用于在大规模（空心）集群上运行轻量级基准测试。一些真实节点上可用的Kubernetes组件（例如Kubelet）将替换为空心的Kubelet。空心的Kubelet伪造了很多一个真正的Kubelet的功能。一个空心的Kubelet实际上并没有启动任何容器，也没有安装任何卷。但是从Kubernetes集群的角度来看，存储在etcd中的状态对象都存在，你可以查询API服务器。空洞的Kubelet实际上是一个注入了模拟Docker客户端的真正的Kubelet，它不会做任何事情。

另一个重要的中空组件是hollow-proxy，它模仿Kubeproxy组件。它再次使用真正的Kubeproxy代码和一个模拟的proxier接口，它什么都不做，并且避免改动iptables。