F5 Container Ingress Services (CIS) and using k8s traffic policies to send traffic directly to pods
Integrating external ADC and WAF appliances with k8s kubernetes or openshift clusters becomes more and more important as to effective protect k8s the appliance needs to see inside k8s and this is where CIS comes into play but service meshes introduce a new challenge!
MVPGreat article. I tried to understand your thoughts, but I realized that unfortunately I don't know enough about Kubernetes.
Do I understand your summary correctly? Your preferred way is to add all NodePorts to a F5 LTM Pool und let decide Health Monitors on which Kubernetes Worker the NodePorts are available? Sorry if this is a dump question...
- Nikoolayy1
As an option especially for service mesh in ambient mode ( sidecar-less ) as in that case I see no option to send directly traffic to pods without going first to a Ingress/Gateway this seems a good option with Node-port and sending traffic through the gateways/ingresses (each node needs to have ingress/gateway and this is called k8s daemonset) only to nodes that have an application pod using the health monitors to mark the nodes without pods as down.
For old service meshes or linkerd (linkerd uses a small special sidecar proxy not like everyone else for example istio mesh that use envoy heavy proxy that is for ingress/gateway but not perfect for a sidecar mesh) that injects sidecar in each pod the 2 ways could be used but using Cluster-IP mode will be simpler (not my workaround). A limitation is what I mentioned in your article 😁
The State Of HTTP/2 Full Proxy With F5 LTM | DevCentral that TLS1.3 seems not supported with HTTP/2 by F5 BIG-IP and I am mentioning this as Linkerd needs TLS1.3 and if the traffic is HTTP/2 or using HTTP/2 for transport protocol like gRPC then directly sending traffic from F5 to linkerd enabled pods does not work. For HTTP1.1 no issues as I tested this.
