objeto de recurso de Kubernetes

En K8S Todos los objetos se denominan recursos, tales como: vaina, servicio, etc.

recursos vaina

envase vaina es la unidad más pequeña en K8S delante mencionan, K8S son compatibles con funciones avanzadas de auto-sanación, expansión flexible y así sucesivamente, docker negocio así que si usted sólo tiene que ejecutar en el nodo K8S hay manera de apoyar estas funciones avanzadas, tiene que ser personalizado es, entonces, esta vaina funcionarios han personalizado un buen soportes de contenedor características avanzadas, cuando se inicia una vaina, habrá al menos dos recipientes pod容器``和业务容器, el tráfico de contenedores compartirá más de un recipiente de vaina (un recipiente de recogida), entonces Pod en un contenedor de espacio de nombres de red compartida,

clasificación recipiente Pod

• Container Infraestructura: recipiente de base, el mantenimiento de todo el espacio de la red Pod
• InitContainers: contenedor de inicialización, antes de que comenzara el negocio de contenedores
• Contenedores: negocio de contenedores, iniciadas en paralelo

El significado de la existencia de la vaina: Existen aplicaciones para cerrar

• la interacción de archivos entre las dos aplicaciones
• Dos aplicaciones requieren la comunicación a través 127.0.0.1 o socker
• Dos aplicaciones requieren frecuente aparición de llamada

estrategia tirando espejo

imagePullPolicy
1、ifNotPresent：默认值，镜像在宿主机上不存在时才拉取
2、Always：每次创建Pod都会重新拉取一次镜像
3、Never：Pod永远不会主动拉取这个镜像 

1.pod operaciones básicas

// 指定yaml文件创建pod
kubectl create -f [yaml文件路径]

// 查看pod基本信息
kubectl get pods

// 查看pod详细信息
kubectl describe pod [pod名]

// 更新pod（修改了yaml内容）
kubectl apply -f [yaml文件路径]

// 删除指定pod
kubectl delete pod [pod名]

// 强制删除指定pod
kubectl delete pod [pod名] --foce --grace-period=0

perfil 2.pod yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx01
  labels:
    app: web
spec:
  containers:
    - name: nginx01
      image: reg.betensh.com/docker_case/nginx:1.13
      ports:
        - containerPort: 80

Pod de las relaciones con los controladores

• controladores: gestión de objetos y el funcionamiento del recipiente en un clúster
• por label-selectorasociada
• Pod aplicado por el controlador para lograr un funcionamiento y mantenimiento, como el estiramiento, actualización sucesiva.

controlador de copia RC

Replicación del controlador de controlador de copia, alojamiento de aplicaciones después de Kubernetes, Kubernetes necesidad de garantizar que las aplicaciones puedan seguir funcionando, este es el contenido del trabajo de RC, se asegurará de que cualquier Kubernetes tiempo tanto en un número determinado de vaina se está ejecutando. Sobre esta base, RC también ofrece algunas características avanzadas, tales como una actualización, rollback actualización sucesiva y así sucesivamente.

ReplicaSet recomendada (denominado RS) en la nueva versión de Kubernetes en lugar de ReplicationController

1. Crear un rc

apiVersion: v1
kind: ReplicationController
metadata:
  name: myweb
spec:
  replicas: 2
  selector:
    app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      containers:
      - name: nginx01
        image: reg.betensh.com/docker_case/nginx:1.13
        ports:
          - containerPort: 80

Por defecto, pod名que se rc名+随机值compone de la siguiente manera:

[root@k8s-master01 rc]# kubectl get pods
NAME          READY     STATUS    RESTARTS   AGE
myweb-0lp57   1/1       Running   0          45s
myweb-zgfcf   1/1       Running   0          45s

RC para controlar la vaina por selector de etiquetas (etiquetas), el nombre RC debe ser el mismo nombre y el selector de etiquetas

[root@k8s-master01 rc]# kubectl get rc -o wide
NAME      DESIRED   CURRENT   READY     AGE       CONTAINER(S)   IMAGE(S)                                 SELECTOR
myweb     2         2         2         12m       nginx01        reg.betensh.com/docker_case/nginx:1.13   app=myweb

2.RC rodadura mejor categoría
Ya hemos creado una versión v1 del servidor HTTP de la vaina en el entorno K8S, cómo hacerlo si queremos hacer una versión de actualización de ella? Se detuvo la vaina original, y luego usar la nueva imagen de levantar una nueva vaina, esto sería claramente inadecuado.

kubectl rolling-update myweb -f nginx_rc_v2.yaml  --update-period=30s

3.RC rodando repliegue
Supongamos ahora actualizar myweb a myweb2, aparecido errores, entonces obligado a interrumpir la actualización

kubectl  rolling-update myweb -f nginx_rc_v2.yaml --update-period=50s

Luego de vuelta a la versión rollo myweb myweb2

kubectl  rolling-update  myweb myweb2 --rollback 

despliegue de recursos

implementación es también una manera de mantener la vaina de alta disponibilidad, es evidente que el despliegue qué RC también introdujo de ella?
Debido a que las resuelve un punto de implementación de la RC, cuando el contenedor de actualización de la versión RC, la etiqueta cambiará, por lo que la etiqueta SVC o el original, por lo que es necesario modificar manualmente los archivos de configuración de SVC dolor.

Despliegue de Pody ReplicaSetanteriormente, para proporcionar un comunicado definido método fórmula (declarativa) en, previamente utilizado en lugar ReplicationControllerde facilitar la aplicación de gestión.
Sólo es necesario Deploymentdescribir desea 目标状态lo que es que Deployment controllerle ayudará Pody ReplicaSetel estado real de cambio en su 目标状态. Se puede definir una nueva Deployment, al crear ReplicaSeto eliminar existente Deploymenty crear uno nuevo para reemplazar. Eso Deploymentes 管理多个ReplicaSet, como se muestra a continuación:

Aunque replicaSet se puede utilizar de forma independiente, pero se recomienda el uso de despliegue para gestionar automáticamente replicaSet, así que no hay necesidad de preocuparse por incompatibilidades con otros mecanismos

1. Crear un despliegue

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

// 启动
[root@k8s-master01 deploy]# kubectl create -f nginx_deploy.yaml

Ver estado de inicio de implementación

despliegue primero iniciar una RS, a continuación, iniciar la vaina

[root@k8s-master01 deploy]# kubectl get all
NAME                                   READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-fcfcc984f-t2bk4   1/1     Running   0          33s
pod/nginx-deployment-fcfcc984f-vg7qt   1/1     Running   0          33s
pod/nginx-deployment-fcfcc984f-zhwxg   1/1     Running   0          33s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   16h

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           33s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-fcfcc984f   3         3         3       33s

2. servicio asociado

kubectl expose deployment nginx-deployment --port=80 --type=NodePort

Ver SVC

[root@k8s-master01 deploy]# kubectl  get svc
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes         ClusterIP   10.96.0.1       <none>        443/TCP        16h
nginx-deployment   NodePort    10.96.171.141   <none>        80:31873/TCP   25s

dirección de SVC y el acceso al puerto

[root@k8s-master01 deploy]# curl -I 10.0.0.33:31873
HTTP/1.1 200 OK
Server: nginx/1.13.12
Date: Thu, 14 Nov 2019 05:44:51 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 09 Apr 2018 16:01:09 GMT
Connection: keep-alive
ETag: "5acb8e45-264"
Accept-Ranges: bytes

actualización 3.deployment

// 直接编辑对应deployment，并修改镜像版本
kubectl edit deployment nginx-deployment

// 通过 set image 发布新的镜像
kubectl set image deploy nginx-deployment nginx-deployment=nginx:1.17

4.deployment rollback

// 回滚到上一级版本
kubectl  rollout undo deployment nginx-deployment

// 回滚到指定版本
kubectl rollout undo deployment nginx-deployment --to-revision=1

// 查看当前deploy历史版本
kubectl rollout history deployment nginx-deployment

La versión de línea de comandos para lograr la liberación

# kubectl  run nginx --image=nginx:1.13 --replicas=3 --record 
# kubectl  rollout history deployment nginx
deployment.extensions/nginx 
# kubectl set image deployment nginx nginx=nginx:1.15                                           

Servicio sin cabeza

En K8S, la forma en que quieren acceder al servicio a través de un nombre que es Deploymentañadir una capa en la parte superior de Service, por lo que podemos Service nameacceder al servicio, y lo que es el principio y CoreDNSrelevante, se Service nameanaliza en Cluster IP, así que visitamos Cluster IPcuando en por IP del clúster para equilibrar la carga del tráfico a través de 各个PODla parte superior. Creo que la pregunta es CoreDNSsi va a resolver directamente el nombre de POD, el servicio en el servicio, no es posible porque hay servicio IP del clúster, directamente CoreDNS resuelto, entonces ¿cómo puede hacer para resolver POD, un ganado grande plantearon se puede utilizar Headless Service, por lo que tenemos que explorar lo que es Headless Service.

Headless ServiceEs una especie de Service, excepto que define spec:clusterIP: None, es decir, no necesitan Cluster IP的Service.

En primer lugar, pensamos Service的Cluster IPde las obras: una Servicepuede corresponder a múltiples EndPoint(Pod), clientel acceso es Cluster IPa través de iptableslas reglas van Real Server, a fin de lograr el equilibrio de carga. funcionamiento específico es como sigue:

1, web-demo.yaml

#deploy
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web-demo
  namespace: dev
spec:
  # 指定svc名称
  serviceName: web-demo-svc
  replicas: 3
  template:
    metadata:
      labels:
        app: web-demo
    spec:
      containers:
      - name: web-demo
        image: 10.0.0.33/base_images/web-demo:v1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: 1024Mi
            cpu: 500m
          limits:
            memory: 2048Mi
            cpu: 2000m
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 10
          failureThreshold: 3
          successThreshold: 1
          timeoutSeconds: 5
        readinessProbe:
          httpGet:
            path: /hello
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 20
          periodSeconds: 10
          failureThreshold: 1
          successThreshold: 1
          timeoutSeconds: 5
---
#service
apiVersion: v1
kind: Service
metadata:
  name: web-demo-svc
  namespace: dev
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  clusterIP: None
  selector:
    app: web-demo

Ver SVC, que se encuentra ClusterIPcomoNone

$ kubectl get svc -n dev | grep "web-demo-svc"
web-demo-svc   ClusterIP   None          <none>        80/TCP         12s

vaina crea orden

$ kubectl get pod -n dev
NAME                         READY   STATUS    RESTARTS   AGE
web-demo-0                   1/1     Running   0          7m2s
web-demo-1                   1/1     Running   0          6m39s
web-demo-2                   1/1     Running   0          6m15s

Iniciar sesión en el interior de la vaina Cluster

$ kubectl exec -it web-demo-0 sh -n dev
/ # nslookup web-demo-svc

Name:      web-demo-svc
Address 1: 10.244.2.67 web-demo-0.web-demo-svc.dev.svc.cluster.local
Address 2: 10.244.3.12 web-demo-2.web-demo-svc.dev.svc.cluster.local
Address 3: 10.244.1.214 web-demo-1.web-demo-svc.dev.svc.cluster.local

Resumen: dns acceder a través de, devuelve una lista de las vainas de back-end

StatefulSet

En primer lugar, Deploymentel fin de la vaina solamente un servicio sin estado, y no hay indiferenciadas, el orden entre el soporte StatefulSet pluralidad Pod, para cada vaina tiene su propio número, acceso necesidad el uno al otro y para distinguir entre el almacenamiento persistente

Pod secuencial

1, sin cabeza-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: springboot-web-svc
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  clusterIP: None
  selector:
    app: springboot-web

2, statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: springboot-web
spec:
  # serviceName 该字段是告诉statefulSet用那个headless server去保证每个的解析
  serviceName: springboot-web-svc
  replicas: 2
  selector:
    matchLabels:
      app: springboot-web
  template:
    metadata:
      labels:
        app: springboot-web
    spec:
      containers:
      - name: springboot-web
        image: 10.0.0.33/base_images/web-demo:v1.0
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 10
          failureThreshold: 3
          successThreshold: 1
          timeoutSeconds: 5

Ver vaina

$ kubectl get pod
NAME               READY   STATUS    RESTARTS   AGE
springboot-web-0   1/1     Running   0          118s
springboot-web-1   1/1     Running   0          116s

Introducir una vaina, y visitar otra vaina por su nombre vaina

$ kubectl exec -it springboot-web-0 sh
/ # ping springboot-web-1.springboot-web-svc
PING springboot-web-1.springboot-web-svc (10.244.2.68): 56 data bytes
64 bytes from 10.244.2.68: seq=0 ttl=62 time=1.114 ms
64 bytes from 10.244.2.68: seq=1 ttl=62 time=0.698 ms

almacenamiento persistente
es automáticamente creado en base a la vaina de PVC

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-demo
spec:
  serviceName: springboot-web-svc
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: springboot-web
    spec:
      containers:
      - name: springboot-web
        image:  10.0.0.33/base_images/nginx:1.13
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: data
          mountPath: /
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: glusterfs-storage-class
      resources:
        requests:
          storage: 1Gi

DaemonSet

DaemonSet en Kubernetes1.2 nueva versión de un objetos de recursos

DaemonSetPermite 所有（或者一些特定）的Nodenodos 仅运行一份Pod. Cuando se añade un nodo de clúster a los kubernetes, Pod será (DaemonSet) programado para ejecutarse en el nodo, cuando el nodo se elimina del clúster se kubernetes (DaemonSet) programado Pod será eliminado si elimina DaemonSet, con todo esto se eliminarán DaemonSet vainas relacionados.

Cuando para ejecutar la aplicación usando kubernetes, necesitamos una gran cantidad de tiempo 区域（zone）o 所有Nodecorrer 同一个守护进程（pod）, por ejemplo, la siguiente escena:

• Cada nodo se ejecuta en un demonios de almacenamiento distribuidos, tales como glusterd, cef
• colector Run Log en cada nodo, por ejemplo fluentd, logstash
• operación de adquisición seguimiento de terminal en cada nodo, por ejemplo prometheus nodo exportador, collectd etc.

Pod DaemonSet de expedición y RC es similar, excepto que el algoritmo de planificación del sistema construido en cada programación de nodo, o pueden ser utilizados NodeSelector NodeAffinity Pod en la definición para especificar un intervalo que satisface la condición de nodo programación

Formato de archivo de recursos DaemonSet

apiVersion: extensions/v1beta1
kind: DaemonSet
  metadata:

Los siguientes ejemplos se definen como al comienzo de cada nodo en una filebeatrecipiente, en el que los montajes de acogida el directorio "/ var / log / messages"

$ vi k8s-log-filebeat.yaml
apiVersion: v1
kind: ConfigMap # 定义一个config文件内容
metadata:
  name: k8s-logs-filebeat-config
  namespace: kube-system
data:
  # 填写filebeat读取日志相关信息
  filebeat.yml: |-
    filebeat.prospectors:
      - type: log
        paths:
          - /messages
        fields:
          app: k8s
          type: module
        fields_under_root: true
    output.logstash:
      # specified logstash port (by default 5044)
      hosts: ['10.0.0.100:5044']
---
apiVersion: apps/v1
kind: DaemonSet  # DaemonSet 对象，保证在每个node节点运行一个副本
metadata:
  name: k8s-logs
  namespace: kube-system
spec:
  selector:
    matchLabels:
      project: k8s
      app: filebeat
  template:
    metadata:
      labels:
        project: k8s
        app: filebeat
    spec:
      containers:
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:6.8.1
        args: [
          "-c", "/etc/filebeat.yml",
          "-e",
        ]
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 500m
            memory: 500Mi
        securityContext:
          runAsUser: 0
        # 进行实际挂载操作
        volumeMounts:
        # 将configmap里的配置挂载到 /etc/filebeat.yml 文件中
        - name: filebeat-config
          mountPath: /etc/filebeat.yml
          subPath: filebeat.yml

        # 将宿主机  /var/log/messages 路径挂载到 /messages中
        - name: k8s-logs
          mountPath: /messages
      # 定义卷
      volumes:
      - name: k8s-logs
        hostPath:
          path: /var/log/messages
          type: File
      - name: filebeat-config
        configMap:
          name: k8s-logs-filebeat-config

El DeamonSet creado utilizando kubectl mandato de creación

$ kubectl create -f  k8s-log-filebeat.yaml
configmap/k8s-logs-filebeat-config created
daemonset.apps/k8s-logs created

Compruebe el creado DeamonSet y la vaina, se puede ver en cada nodo crea una vaina

$ kubectl get ds -n kube-system | grep "k8s-logs"
NAME                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
k8s-logs                  2         2         0       2            0           <none>                        2m15s

$ kubectl get pods -n kube-system -o wide | grep "k8s-logs"  
k8s-logs-gw4bs                         0/1     Running   0          87s     <none>        k8s-node01     <none>           <none>
k8s-logs-p6r6t                         0/1     Running   0          87s     <none>        k8s-node02     <none>           <none>

En la versión 1.6 más adelante en kubernetes, DaemonSet puede realizar una actualización sucesiva, que se actualizan una plantilla DaemonSet cuando se borrará automáticamente la copia antigua de la vaina, mientras que la nueva copia de la vaina se crea automáticamente, esta vez la estrategia de actualización DaemonSet (updateStrategy) es RollingUpdate, como sigue:

apiVersion: apps/v1
kind: DaemonSet 
metadata:
  name: k8s-logs
  namespace: kube-system
spec:
  updateStrategy:
    type: RollingUpdate

updateStrategy Otro valor es OnDelete, es decir, sólo cuando elimine manualmente el Pod copiar DaemonSet creado una nueva copia de la vaina se creará a cabo, si no se establece el valor updateStrategy, a continuación, en versiones posteriores de 1,6 kubernetes será la configuración por defecto RollingUpdate (actualización sucesiva).

Recursos de Servicio

Todos sabemos que en kubernetes a Pod unidad mínima de programación, y su característica es la incertidumbre, que será destruido en cualquier momento y volver a crear incertidumbre conducirá cada vaina se implementará en diferentes N por el planificador un nodo de nodo, esto hará que la dirección Pod ip cambiará;

Por ejemplo, la escena web se divide en back-end front-end, las necesidades de front-end a los recursos de llamada de back-end, si el back-end de la vaina nacido de incertidumbre conduce a una dirección IP diferente, por lo que el frente es, sin duda no lo hacen dirección IP para el cambio automático de back-end de conexión, por lo que es necesario descubrir a través de la vaina de servicio y obtener su dirección IP.

Pod relación con el Servicio

• Pod prevenir el contacto perdido., Pod obtener información (a través de la etiqueta-selector asociado)
• Pod define un conjunto de políticas de acceso (equilibrio de carga TCP / UDP 4 capas)
• Apoyar ClusterIP, NodePort y LoadBalancer tres tipos
• implementaciones de servidor subyacente iptables y hay dos tipos de modos de red IPVS

Cada aplicación está asociada con un servicio

Tipo de servicio

• ClusterIP: Por defecto, una distribución dentro de la agrupación puede acceder a la IP virtual (VIP)
• NodePort: asignar un puerto como una entrada en cada nodo de acceso externo
• LoadBalancer: trabajo en una nube proveedor específico, como la nube de Google, AWS, OpenStack

Detalla 1.Cluster IP:

IP del clúster, también conocido como VIP, el principal logro de visitas entre diferentes Pod

type: NodePort  
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

Abrir el acceso de proxy
proxy de kubectl para permitir el acceso a la red externa K8S servicio de ClusterIP

kubectl proxy --address='0.0.0.0'  --accept-hosts='^*$' --port=8009

http://[k8s-master]:8009/api/v1/namespaces/[namespace-name]/services/[service-name]/proxy

Detalles: https: //blog.csdn.net/zwqjoy/article/details/87865283

Detalla 2.Node puerto:

Los usuarios externos pueden acceder nodo implementados Node, nodo Nodo fluirá hacia adelante en el interior del mismo Pod

Proceso de acceso: Usuarios -> Dominio -> equilibrador de carga -> NodeIP: Port -> PodIP: Puerto

También se puede implementar en frente de un equilibrio de carga de nodo LB directamente, como se muestra:

type: NodePort
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30008
      protocol: TCP

Descripción del parámetro

spec.ports.port：vip端口（cluster ip）
spec.ports.nodePort：映射到宿主机的端口，即提供外部访问的端口
spec.ports.targetPort：pod 端口
spec.selector: 标签选择器

Creación de un tipo nodePort de tiempo se le asignará un IP del clúster, proporciona un cómodo acceso a entre Pod

3, LoadBalancer Comentarios:
Proceso de acceso: Usuarios -> Dominio -> equilibrador de carga -> NodeIP: Port -> PodIP : Puerto

Convencionales escenarios de mapeo ventana acoplable:

Acceso -> nodo IP: 10.0.0.12 -> contenedor ventana acoplable: 172.16.48.2

Si colgado cuando estibador, un estibador, cambio de dirección IP contenedor se produce en el reinicio, antes de hacerlo y mapeo de los ganglios ventana acoplable no es válida, es necesario modificar manualmente el mapa, por lo que es muy molesto

Por lo tanto, añaden en K8S en el IP del clúster, 10.254.0.0/16,series segmento de la red automáticamente crear el clúster IP, también conocida como vip, cuando la vaina se crea automáticamente registrado en el servicio, y el equilibrio de carga (la regla por defecto como rr), si una vaina colgó, será automáticamente rechazada

Acceso -> nodo IP: 10.0.0.13 -> IP del clúster: 10.254.0.0/16 (servicio) -> la vaina IP: 172.16.48.2

Crear un servicio

apiVersion: v1
kind: Service
metadata:
  name: myweb
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30000
    targetPort: 80
  selector:
    app: myweb               

// 启动
kubectl create -f nginx-svc.yaml

Servicio para hacerse cargo de la vaina para ver si los servicios normales de la red:

[root@k8s-master01 svc]# kubectl get endpoints
NAME         ENDPOINTS                       AGE
kubernetes   10.0.0.31:6443                  2d
myweb        172.16.12.2:80,172.16.15.4:80   2m

IPVS y obras de iptables

servicio de reenvío de tráfico subyacente y balanceo de carga para lograr:

• iptables
• IPVS

1, un servicio va a crear una gran cantidad de reglas de iptables (actualización, no incrementales)
2, iptables reglas se corresponden uno a uno de arriba a abajo (gran retraso).

Salvador: IPVS (modo kernel)

carga LVS Módulo de Balanceo planificador IPVS núcleo implementado, tales como: el SLB Ali nube, basado en cuatro LVS lograr el equilibrio de carga.

iptables:

• Flexible, potente (el paquete puede operar en diferentes etapas del paquete)
• Y el recorrido actualizar las normas partido, un retardo lineal

IPVS:

• Trabajar en modo kernel, un mejor rendimiento
• algoritmos de planificación ricos: rr, WRR, lc, wlc, picadillo IP ....