|
| 1 | +# Listener CRD support for Ingress through annotation |
| 2 | + |
| 3 | +Ingress is a standard Kubernetes resource that specifies HTTP routing capability to back-end Kubernetes services. Citrix ingress controller provides various annotations to fine-tune the Ingress parameters for both front-end and back-end configurations. For example, using the `ingress.citrix.com/frontend-ip` annotation you can specify the front-end listener IP address configured in Citrix ADC by Citrix ingress controller. Similarly, there are other front-end annotations to fine-tune HTTP and SSL parameters. When there are multiple Ingress resources and if they share front-end IP and port, specifying these annotations in each Ingress resource is difficult. |
| 4 | + |
| 5 | +Sometimes, there is a separation of responsibility between network operations professionals (NetOps) and developers. NetOps are responsible for coming up with front-end configurations like front-end IP, certificates, and SSL parameters. Developers are responsible for HTTP routing and back-end configurations. Citrix ingress controller already provides [content routing CRDs](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/crd/contentrouting) such as listener CRD for front-end configurations and `HTTProute` for back-end routing logic. |
| 6 | +Now, Listener CRD can be applied for Ingress resources using an annotation provided by Citrix. |
| 7 | + |
| 8 | +Through this feature, you can use the Listener CRD for your Ingress resource and separate the creation of the front-end configuration from the Ingress definition. Hence, NetOps can separately define the Listener resource to configure front-end IP, certificates, and other front-end parameters (TCP, HTTP, and SSL). Any configuration changes can be applied to the listener resources without changing each Ingress resource. In Citrix ADC, a listener resource corresponds to content switching virtual servers, SSL virtual servers, certkeys and front-end HTTP, SSL, and TCP profiles. |
| 9 | + |
| 10 | +**Note:** While using this feature, you must ensure that all ingresses with the same front-end IP and port refer to the same Listener resource. For ingresses that use the same front-end IP and port combinations, one Ingress referring to a listener resource and another ingress referring to the `ingress.citrix.com/frontend-ip` annotation is not supported. |
| 11 | + |
| 12 | +## Restrictions |
| 13 | + |
| 14 | +When Listener is used for the front-end configurations, the following annotations are ignored and there may not be any effect: |
| 15 | + |
| 16 | +- `ingress.citrix.com/frontend-ip` |
| 17 | +- `Ingress.citrix.com/frontend-ipset-name` |
| 18 | +- `ingress.citrix.com/secure-port` |
| 19 | +- `ingress.citrix.com/insecure-port` |
| 20 | +- `ingress.citrix.com/insecure-termination` |
| 21 | +- `ingress.citrix.com/secure-service-type` |
| 22 | +- `ingress.citrix.com/insecure-service-type` |
| 23 | +- `ingress.citrix.com/csvserver` |
| 24 | +- `ingress.citrix.com/frontend-tcpprofile` |
| 25 | +- `ingress.citrix.com/frontend-sslprofile` |
| 26 | +- `ingress.citrix.com/frontend-httpprofile` |
| 27 | + |
| 28 | +## Deploying a Listener CRD resource for Ingress |
| 29 | + |
| 30 | +Using the `ingress.citrix.com/listener` annotation, you can specify the name and namespace of the Listener resource for the ingress in the form of `namespace/name`. The namespace is not required if the Listener resource is in the same namespace as that of Ingress. |
| 31 | + |
| 32 | +Following is an example for the annotation: |
| 33 | + |
| 34 | + ingress.citrix.com/listener: default/listener1 |
| 35 | + |
| 36 | +Here, `default` is the namespace of the Listener resource and `listener1` is the name of the Listener resource which specifies the front-end parameters. |
| 37 | + |
| 38 | +Perform the following steps to deploy a Listener resource for the Ingress: |
| 39 | + |
| 40 | +1. Create a Listener resource (`listener.yaml`) as follows: |
| 41 | + |
| 42 | + ```yml |
| 43 | + apiVersion: citrix.com/v1 |
| 44 | + kind: Listener |
| 45 | + metadata: |
| 46 | + name: my-listener |
| 47 | + namespace: default |
| 48 | + spec: |
| 49 | + ingressClass: citrix |
| 50 | + vip: '192.168.0.1' # Virtual IP address to be used, not required when CPX is used as ingress device |
| 51 | + port: 443 |
| 52 | + protocol: https |
| 53 | + redirectPort: 80 |
| 54 | + secondaryVips: |
| 55 | + - "10.0.0.1" |
| 56 | + - "1.1.1.1" |
| 57 | + policies: |
| 58 | + httpprofile: |
| 59 | + config: |
| 60 | + websocket: "ENABLED" |
| 61 | + tcpprofile: |
| 62 | + config: |
| 63 | + sack: "ENABLED" |
| 64 | + sslprofile: |
| 65 | + config: |
| 66 | + ssl3: "ENABLED" |
| 67 | + sslciphers: |
| 68 | + - SECURE |
| 69 | + - MEDIUM |
| 70 | + analyticsprofile: |
| 71 | + config: |
| 72 | + - type: webinsight |
| 73 | + parameters: |
| 74 | + allhttpheaders: "ENABLED" |
| 75 | + csvserverConfig: |
| 76 | + rhistate: 'ACTIVE' |
| 77 | + ``` |
| 78 | +
|
| 79 | + Here, the Listener resource `my-listener` in the default namespace specifies the front-end configuration such as VIP, secondary VIPs, HTTP profile, TCP profile, SSL profile, and SSL ciphers. It creates a content switching virtual server in Citrix ADC on port 443 for HTTPS traffic, and all HTTP traffic on port 80 is redirected to HTTPS. |
| 80 | + |
| 81 | + **Note:** The `vip` field in the Listener resource is not required when Citrix ADC CPX is used as an ingress device. For Citrix ADC VPX, VIP is the same as the pod IP address which is automatically configured by Citrix ingress controller. |
| 82 | + |
| 83 | +1. Apply the Listener resource. |
| 84 | + |
| 85 | + kubectl apply -f listener.yaml |
| 86 | + |
| 87 | +1. Create an Ingress resource (`ingress.yaml`) by referring to the Listener resource. |
| 88 | + |
| 89 | + ```yml |
| 90 | + apiVersion: networking.k8s.io/v1 |
| 91 | + kind: Ingress |
| 92 | + metadata: |
| 93 | + name: my-ingress |
| 94 | + namespace: default |
| 95 | + annotations: |
| 96 | + ingress.citrix.com/listener: my-listener |
| 97 | + kubernetes.io/ingress.class: "citrix" |
| 98 | + spec: |
| 99 | + tls: |
| 100 | + - secretName: my-secret |
| 101 | + hosts: |
| 102 | + - example.com |
| 103 | + rules: |
| 104 | + - host: example.com |
| 105 | + http: |
| 106 | + paths: |
| 107 | + - path: / |
| 108 | + pathType: Prefix |
| 109 | + backend: |
| 110 | + service: |
| 111 | + name: kuard |
| 112 | + port: |
| 113 | + number: 80 |
| 114 | + ``` |
| 115 | + |
| 116 | + Here, the ingress resource `my-ingress` refers to the Listener resource `my-listener` in the default namespace for front-end configurations. |
| 117 | + |
| 118 | +1. Apply the ingress resource. |
| 119 | + |
| 120 | + kubectl apply -f ingress.yaml |
| 121 | + |
| 122 | +## Certificate management |
| 123 | + |
| 124 | +There are two ways in which you can specify the certificates for Ingress resources. You can specify the certificates as part of the Ingress resource or provide the certificates as part of the Listener resource. |
| 125 | + |
| 126 | +### Certificate management through Ingress resource |
| 127 | + |
| 128 | +In this approach, all certificates are specified as part of the regular ingress resource as follows. Listener resource does not specify certificates. In this mode, you need to specify certificates as part of the Ingress resource. |
| 129 | + |
| 130 | + ```yml |
| 131 | + apiVersion: networking.k8s.io/v1 |
| 132 | + kind: Ingress |
| 133 | + metadata: |
| 134 | + name: my-ingress |
| 135 | + namespace: default |
| 136 | + annotations: |
| 137 | + ingress.citrix.com/listener: my-listener |
| 138 | + kubernetes.io/ingress.class: "citrix" |
| 139 | + spec: |
| 140 | + tls: |
| 141 | + - secretName: my-secret |
| 142 | + hosts: |
| 143 | + - example.com |
| 144 | + rules: |
| 145 | + - host: example.com |
| 146 | + http: |
| 147 | + paths: |
| 148 | + - path: / |
| 149 | + pathType: Prefix |
| 150 | + backend: |
| 151 | + service: |
| 152 | + name: kuard |
| 153 | + port: |
| 154 | + number: 80 |
| 155 | + ``` |
| 156 | + |
| 157 | +### Certificate management through Listener resource |
| 158 | + |
| 159 | +In this approach, certificates are provided as part of the Listener resource. You do not have to specify certificates as part of the Ingress resource. |
| 160 | + |
| 161 | +The following Listener resource example shows certificates. |
| 162 | + |
| 163 | +```yml |
| 164 | +apiVersion: citrix.com/v1 |
| 165 | +kind: Listener |
| 166 | +metadata: |
| 167 | + name: my-listener |
| 168 | + namespace: default |
| 169 | +spec: |
| 170 | + ingressClass: citrix |
| 171 | + certificates: |
| 172 | + - secret: |
| 173 | + name: my-secret |
| 174 | + # Secret named 'my-secret' in current namespace bound as default certificate |
| 175 | + default: true |
| 176 | + - secret: |
| 177 | + # Secret 'other-secret' in demo namespace bound as SNI certificate |
| 178 | + name: other-secret |
| 179 | + namespace: demo |
| 180 | + vip: '192.168.0.1' # Virtual IP address to be used, not required when CPX is used as ingress device |
| 181 | + port: 443 |
| 182 | + protocol: https |
| 183 | + redirectPort: 80 |
| 184 | +``` |
| 185 | + |
| 186 | +In the Ingress resource, secrets are not specified as shown in the following example. |
| 187 | + |
| 188 | +```yml |
| 189 | + apiVersion: networking.k8s.io/v1 |
| 190 | + kind: Ingress |
| 191 | + metadata: |
| 192 | + name: my-ingress |
| 193 | + namespace: default |
| 194 | + annotations: |
| 195 | + ingress.citrix.com/listener: my-listener |
| 196 | + kubernetes.io/ingress.class: "citrix" |
| 197 | + spec: |
| 198 | + tls: |
| 199 | + # TLS field is empty as the certs are specified in Listener |
| 200 | + rules: |
| 201 | + - host: example.com |
| 202 | + http: |
| 203 | + paths: |
| 204 | + - path: / |
| 205 | + pathType: Prefix |
| 206 | + backend: |
| 207 | + service: |
| 208 | + name: kuard |
| 209 | + port: |
| 210 | + number: 80 |
| 211 | +``` |
0 commit comments