Lab 4.1 - Configure F5 IngressLink with Kubernetes

BIG-IP Setup

When we configure CIS below, NGINX requires “Proxy-Protocol” to provide the application POD with the original client IP. BIG IP will pass the original client IP to NGINX via PROXY PROTOCOL, and NGINX will pass the client IP to the application POD via X-Real-IP HTTP header. The following iRule provides the necessary header with IP information.

1. Go back to the TMUI session you opened in a previous task. If you need to open a new session go back to the Deployment tab of your UDF lab session at https://udf.f5.com and connect to BIG-IP1 using the TMUI access method (username: admin and password: admin)

   

2. On the Main tab go to Local Traffic ‣ iRules

3. Click Create.

4. In the Name field, type name as “Proxy_Protocol_iRule”.

   Important

   Be sure to use the name as shown. The IngressLink Resource will reference that specific name.

5. In the Definition field, Copy the following definition

   Proxy_Protocol_iRule

   # PROXY Protocol Receiver iRule
   # iRule used for F5 IngressLink
   # Layer 4 irule since BIG-IP is passthrough
   
   when CLIENT_ACCEPTED {
       set proxyheader "PROXY "
       if {[IP::version] eq 4} {
           append proxyheader "TCP4 "
       } else {
           append proxyheader "TCP6 "
       }
       append proxyheader "[IP::remote_addr] [IP::local_addr] [TCP::remote_port] [TCP::local_port]\r\n"
   }
   
   when SERVER_CONNECTED {
       TCP::respond $proxyheader
   }
   

6. Click Finished

Configure CIS

1. Go back to the Web Shell session you opened in the previous task. If you need to open a new session go back to the Deployment tab of your UDF lab session at https://udf.f5.com to connect to kube-master1 using the Web Shell access method, then switch to the ubuntu user account using the “su” command:

   

   su ubuntu
   

2. Change to the default working directory with all the yaml files

   cd ~/agilitydocs/docs/class1/kubernetes/
   

3. Ensure the previously deployed “CIS ClusterIP deployment” is deleted

   kubectl delete -f cluster-deployment.yaml
   

   Attention

   This was most likely done in a previous step but we need to ensure the previous deployment is removed. It does not hurt to run the command again so do so now.

4. Create the CIS IngressLink custom resource definition. The schema is used to validate the JSON data during creation and updates so that it can prevent invalid data, or moreover, malicious attacks.

   kubectl create -f ingresslink/ingresslink-customresourcedefinition.yaml
   

5. Create a service for the Ingress Controller pods for ports 80 and 443

   kubectl create -f ingresslink/nginx-service.yaml
   

6. Verify the service

   kubectl describe svc nginx-ingress-ingresslink -n nginx-ingress
   

7. The default nginx config needs to be updated with proxy-protocol. This is necesary for IngressLink to properly operate.

   Note

   BIG IP will pass the original client IP to NGINX via PROXY PROTOCOL, and NGINX will pass the client IP to the application POD via X-Real-IP HTTP header.

   nginx-config.yaml

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: nginx-config
     namespace: nginx-ingress
   data:
     proxy-protocol: "True"
     real-ip-header: "proxy_protocol"
     set-real-ip-from: "0.0.0.0/0"
   

8. Apply the config changes to nginx ingress

   kubectl apply -f ingresslink/nginx-config.yaml
   

   Hint

   The use of “apply” allows us to modify an already running object.

9. Inspect the deployment yaml

   Note

   To enable IngressLink you’ll notice two additional “args”

   "--custom-resource-mode=true",
   "--ingress-link-mode=true",
   

   You’ll see this difference in the deployment file

   ingresslink-deployment.yaml

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: k8s-bigip-ctlr
     namespace: kube-system
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: k8s-bigip-ctlr
     template:
       metadata:
         name: k8s-bigip-ctlr
         labels:
           app: k8s-bigip-ctlr
       spec:
         serviceAccountName: k8s-bigip-ctlr
         containers:
           - name: k8s-bigip-ctlr
             image: "f5networks/k8s-bigip-ctlr:latest"
             imagePullPolicy: IfNotPresent
             env:
               - name: BIGIP_USERNAME
                 valueFrom:
                   secretKeyRef:
                     name: bigip-login
                     key: username
               - name: BIGIP_PASSWORD
                 valueFrom:
                   secretKeyRef:
                     name: bigip-login
                     key: password
             command: ["/app/bin/k8s-bigip-ctlr"]
             args: [
               "--bigip-username=$(BIGIP_USERNAME)",
               "--bigip-password=$(BIGIP_PASSWORD)",
               "--bigip-url=10.1.1.5",
               "--insecure=true",
               "--custom-resource-mode=true",
               "--bigip-partition=kubernetes",
               "--pool-member-type=cluster",
               "--flannel-name=/Common/fl-tunnel"
             ]
   

10. Create the CIS deployment

    kubectl create -f ingresslink/ingresslink-deployment.yaml
    

11. Verify the new CIS pod is “Running”

    kubectl get pods -A
    

    You should see something similar to the following. Verify a new pod named “K8s-bigip-ctrl…” has started.

    

    Hint

    Note the use of “-A” for all namespaces in the kubectl command.

Create an IngressLink Resource

1. Inspect the IngressLink resource

   Attention

   Ensure the IP ADDR in the IngressLink resource matches the required IP. In this lab we’re using 10.1.10.101 as the virtual IP. This IP ADDR will be used to configure the BIG-IP device to load balance the Ingress Controller resources.

   vs-ingresslink.yaml

   apiVersion: "cis.f5.com/v1"
   kind: IngressLink
   metadata:
     name: vs-ingresslink
     namespace: nginx-ingress
   spec:
     virtualServerAddress: "10.1.10.101"
     iRules:
       - /Common/Proxy_Protocol_iRule
     selector:
       matchLabels:
         app: nginx-ingress
   

   Important

   The name of the app label selector in the IngressLink resource should match the labels of the nginx-ingress service created in module 3 where we deployed NGINX.

2. Create the IngressLink

   kubectl create -f ingresslink/vs-ingresslink.yaml
   

3. To validate IngressLink deployment we’ll verify the pool member created on BIGIP consist of one IP and it matches the NGINX ingress controller. To find the IP run the following command and take note of the Endpoint IP.

   kubectl describe svc nginx-ingress-ingresslink -n nginx-ingress
   

   

   Note

   Your Endpoint/IP will most likely be different.

4. Go back to the TMUI session you opened in a previous task. If you need to open a new session go back to the Deployment tab of your UDF lab session at https://udf.f5.com and connect to BIG-IP1 using the TMUI access method (username: admin and password: admin)

   

5. Browse to: Local Traffic ‣ Virtual Servers

   Warning

   Don’t forget to select the “kubernetes” partition or you’ll

   see nothing.

   Here you can see two new Virtual Servers, “ingress_link_crd_10.1.10.101_80” and “ingress_link_crd_10.1.10.101_443” was created, in partition “kubernetes”.

   

6. Check the Pools to see a new pool and the associated pool members.

   Browse to: Local Traffic ‣ Pools and select either of the “nginx_ingress_nginx_ingress_ingresslink” pool objects. Both have the same pool member but are running on different ports. Click the Members tab.

   

   Note

   You can see that the pool member listed is the same Endpoint/IP discovered in the earlier step above.