Ingress Controller de NetScaler

Mejoras en el servicio de Kubernetes compatible con el tipo LoadBalancer en el NetScaler Ingress Controller

September 1, 2023

Contribución de:

El servicio de Kubernetes compatible con el tipo LoadBalancer en el NetScaler Ingress Controller se ha mejorado con las siguientes funciones:

Soporte de inyección de salud en ruta (RHI) BGP
Anunciar o recuperar direcciones IP (VIP) de equilibradores de carga en función de la disponibilidad de los pods del servicio en un conjunto de nodos (zonas) definidos por las etiquetas del nodo

Compatibilidad con la configuración automática de BGP RHI en NetScaler

La inyección de estado de ruta (RHI) permite que NetScaler anuncie la disponibilidad de una VIP como ruta de host en toda la red mediante BGP. Sin embargo, tenía que realizar la configuración manualmente en NetScaler para admitir RHI. Con los controladores NetScaler Ingress implementados en un entorno de Kubernetes, puede automatizar la configuración de NetScaler para anunciar a los VIP.

Cuando LoadBalancer se crea un servicio de este tipo, el Ingress Controller de NetScaler configura un VIP en NetScaler para el servicio. Si la compatibilidad con BGP RHI está habilitada para el controlador NetScaler Ingress, se configura automáticamente NetScaler para anunciar el VIP en la red BGP.

Anunciar y retirar VIP en función de la disponibilidad de los pods

En la topología, como se muestra en el siguiente diagrama, los nodos de un clúster de Kubernetes se distribuyen físicamente en tres racks diferentes. Se agrupan lógicamente en tres zonas. Cada zona tiene un NetScaler MPX como ADC de nivel 1 y un controlador NetScaler Ingress en la misma ubicación en el clúster de Kubernetes. Los controladores NetScaler Ingress de todas las zonas escuchan el mismo servidor API de Kubernetes. Por lo tanto, cada vez que LoadBalancer se crea un servicio de este tipo, todos los NetScalers del clúster anuncian la misma dirección IP en la estructura BGP. Incluso, si no hay carga de trabajo en una zona, el NetScaler de esa zona sigue anunciando la dirección IP.

Topología de ejemplo

NetScaler ofrece una solución para anunciar o retirar el VIP en función de la disponibilidad de pods en una zona. Debe etiquetar los nodos de cada zona para que el Ingress Controller de NetScaler pueda identificar los nodos que pertenecen a la misma zona. El controlador NetScaler Ingress de cada zona comprueba si hay pods en los nodos de la zona. Si hay pods en los nodos de la zona, anuncia el VIP. De lo contrario, revoca el anuncio de VIP de NetScaler en la zona.

Configuración de BGP RHI en NetScalers mediante el controlador NetScaler Ingress

En este tema se proporciona información sobre cómo configurar el RHI de BGP en NetScalers mediante el controlador NetScaler Ingress basándose en una topología de ejemplo. En esta topología, los nodos de un clúster de Kubernetes se implementan en dos zonas. Cada zona tiene un NetScaler VPX o MPX como ADC de nivel 1 y un controlador NetScaler Ingress para configurar el ADC en el clúster de Kubernetes. Los ADC se conectan mediante BGP con el enrutador ascendente.

Topología de ejemplo de configuración de BGP RHI

Requisitos previos

Debe configurar NetScaler MPX o VPX como par BGP con los enrutadores ascendentes.

Realice los siguientes pasos para configurar la compatibilidad con RHI de BGP en función de la topología de muestra.

Etiquete los nodos de cada zona con el siguiente comando:

Para la zona 1:

kubectl label nodes node1 rack=rack-1
kubectl label nodes node2 rack=rack-1

Para la zona 2:

kubectl label nodes node3 rack=rack-2
kubectl label nodes node4 rack=rack-2

Configure las siguientes variables de entorno en los archivos YAML de configuración del controlador NetScaler Ingress de la siguiente manera:

Para la zona 1:

- name: "NODE_LABELS"
  value: "rack-1"
- name: "BGP_ADVERTISEMENT"
  value: "True"

Para la zona 2:

 - name: "NODE_LABELS"
   value: "rack-2"
 - name: "BGP_ADVERTISEMENT"
   value: "True"

A continuación se proporciona un cic.yaml archivo de ejemplo para implementar el NetScaler Ingress Controller en la zona 1:

apiVersion: v1
kind: Pod
metadata:
  name: cic-k8s-ingress-controller-1
  labels:
    app: cic-k8s-ingress-controller-1
spec:
  serviceAccountName: cic-k8s-role
  containers:
  - name: cic-k8s-ingress-controller
    image: "quay.io/citrix/citrix-k8s-ingress-controller:1.34.16"

    env:
    # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
    - name: "NS_IP"
      value: "10.217.212.24"
   # Set username for Nitro
    - name: "NS_USER"
      valueFrom:
        secretKeyRef:
          name: nslogin
          key: username
   # Set user password for Nitro
    - name: "NS_PASSWORD"
      valueFrom:
        secretKeyRef:
        name: nslogin
        key: password        
    - name: "EULA"
      value: "yes"
    - name: "NODE_LABELS"
      value: "rack=rack-1"
    - name: "BGP_ADVERTISEMENT"
      value: "True"
args:
  - --ipam 
    citrix-ipam-controller
imagePullPolicy: Always

Implemente el controlador NetScaler Ingress mediante el siguiente comando.

Nota:

Debe implementar el NetScaler Ingress Controller en ambos racks (por zona).
```
Kubectl create -f cic.yaml
```

Implemente una aplicación de ejemplo con el archivo web-frontend-lb.yaml.

Kubectl crea -f web-frontend-lb.yaml

El contenido de web-frontend-lb.yaml es el siguiente:

apiVersion: v1
kind: Deployment
metadata:
  name: web-frontend
spec:
  selector:
    matchLabels:
      app: web-frontend
  replicas: 4
  template:
    metadata:
      labels:
        app: web-frontend
    spec:
      containers:
      - name: web-frontend
        image: 10.217.6.101:5000/web-test:latest
        ports:
          - containerPort: 80
        imagePullPolicy: Always

Cree un servicio de tipo LoadBalancer para exponer la aplicación.

Kubectl create -f web-frontend-lb-service.yaml

El contenido de web-frontend-lb-service.yaml es el siguiente:

apiVersion: v1
kind: Service
metadata:
  name: web-frontend
  labels:
    app: web-frontend
spec:
  type: LoadBalancer
  ports:
  - port: 80
    protocol: TCP
    name: http
  selector:
    app: web-frontend

Compruebe la creación del grupo de servicios en NetScalers mediante el siguiente comando.

show servicegroup <service-group-name>

A continuación se muestra un ejemplo de salida del comando.

#  show servicegroup k8s-web-frontend_default_80_svc_k8s-web-frontend_default_80_svc
   
k8s-web-frontend_default_80_svc_k8s-web-frontend_default_80_svc - TCP
State: ENABLED Effective State: UP Monitor Threshold : 0
Max Conn: 0 Max Req: 0 Max Bandwidth: 0 kbits
Use Source IP: NO
Client Keepalive(CKA): NO
TCP Buffering(TCPB): NO
HTTP Compression(CMP): NO
Idle timeout: Client: 9000 sec Server: 9000 sec
Client IP: DISABLED 
Cacheable: NO
SC: OFF
SP: OFF
Down state flush: ENABLED
Monitor Connection Close : NONE
Appflow logging: ENABLED
ContentInspection profile name: ???
Process Local: DISABLED
Traffic Domain: 0


1)   10.217.212.23:30126 State: UP Server Name: 10.217.212.23 Server ID: None Weight: 1
  Last state change was at Wed Jan 22 23:35:11 2020 
  Time since last state change: 5 days, 00:45:09.760

  Monitor Name: tcp-default  State: UP Passive: 0
  Probes: 86941 Failed [Total: 0 Current: 0]
  Last response: Success - TCP syn+ack received.
  Response Time: 0 millisec

2)   10.217.212.22:30126 State: UP Server Name: 10.217.212.22 Server ID: None Weight: 1
  Last state change was at Wed Jan 22 23:35:11 2020 
  Time since last state change: 5 days, 00:45:09.790

  Monitor Name: tcp-default State: UP Passive: 0
  Probes: 86941 Failed [Total: 0 Current: 0]
  Last response: Success - TCP syn+ack received.

Verifique el anuncio VIP en el enrutador BGP mediante el siguiente comando.

 >VTYSH
# show ip route bgp
  B       172.29.46.78/32   [200/0] via 2.2.2.100, vlan20, 1d00h35m
                            [200/0] via 2.2.2.101, vlan20, 1d00h35m
  Gateway of last resort is not set

La versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Cloud Software Group solo tiene traducción automática. Cloud Software Group no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Cloud Software Group se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Cloud Software Group, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Cloud Software Group no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

¿Le ha resultado útil?

Mejoras en el servicio de Kubernetes compatible con el tipo LoadBalancer en el NetScaler Ingress Controller

September 1, 2023

Contribución de:

September 1, 2023

Contribución de:

En este artículo

Compatibilidad con la configuración automática de BGP RHI en NetScaler
Anunciar y retirar VIP en función de la disponibilidad de los pods
Configuración de BGP RHI en NetScalers mediante el controlador NetScaler Ingress

¿Le ha resultado útil?