Cilium¶
Cilium provides networking and network security for Kubernetes applications using eBPF, a technology in the Linux kernel.
Your Platform Administrator manages the networking implementation used by your environment. To check whether your environment uses Cilium, run:
kubectl get pods -n kube-system | grep cilium
If Cilium is installed, the output will include Cilium Pods.
Differences from Calico¶
Cilium and Calico provide Pod networking and enforce Network Policies. When using Cilium, you continue to deploy applications using Kubernetes resources such as Services and NetworkPolicies.
Policies using Calico Custom Resource Definitions (CRDs) require review when moving to Cilium. Contact your Platform Administrator if your application depends on these resources.
Cilium also offers features such as Egress Gateway, additional Network Policy capabilities and network visibility through Hubble. Availability depends on your environment; an upstream feature is not necessarily enabled or supported in Welkin.
Egress Gateway¶
Some external services require you to allowlist the source IP addresses of incoming connections. Pod and Node IP addresses can change, making them unsuitable for this purpose.
Cilium Egress Gateway routes selected outgoing application traffic through a gateway configured by your Platform Administrator. The external service sees the configured outgoing IP address, which you can use for allowlisting.
Responsibilities¶
The Platform Administrator:
- Enables Egress Gateway and configures the gateway infrastructure.
- Creates and maintains the gateway policy.
- Provides the externally visible source IP addresses to allowlist.
The Application Developer:
- Identifies the application workloads and external destinations.
- Maintains the agreed Pod labels.
- Ensures application NetworkPolicies allow the required connections.
- Arranges allowlisting with the external service provider.
Requesting an egress IP¶
Contact your Platform Administrator and provide:
- Your environment and namespace.
- The workloads that need predictable outgoing IP and their Pod labels.
- The external service's hostname and destination IP ranges, where available.
- The required ports and protocols.
For example:
| Requirement | Example |
|---|---|
| Namespace | demo-app |
| Pod labels | app: demo-app-api |
| Destination IP range | 203.0.113.0/24 |
| Port and protocol | TCP port 443 |
These values are illustrative. Use the actual destination details supplied by your external service provider.
The Platform Administrator will confirm the configuration and the source IP addresses to allowlist. You do not need to create an Egress Gateway policy yourself.
Preparing your application¶
Ensure the agreed labels are present on your application's Pods. For a Deployment, configure these labels in the Pod template so replacement Pods receive them too.
Warning
The Egress Gateway policy selects your application's Pods using the labels agreed with your Platform Administrator. If these labels are missing or changed so that the Pods no longer match the policy, their traffic will not use the configured gateway through that policy. The external service may therefore see a different source IP and reject the connection.
Egress Gateway does not replace NetworkPolicies. Your application must still be permitted to reach the external service and resolve DNS names where required.