Zum Inhalt springen
Produkte
Plattform
Developer Tools
Portal

Container Networking

Zuletzt aktualisiert am

Kubernetes networking simplifies how applications communicate by treating the entire cluster as a single, cohesive network. Its primary design philosophy is to eliminate the need for complex port mapping and Network Address Translation (NAT) between pods.

Core networking principles

Section titled “Core networking principles”

The Kubernetes network model dictates three fundamental rules that any implementation must follow:

  • Every Pod gets its own IP address: You do not need to explicitly map container ports to host ports.
  • Pods communicate without NAT: All Pods on all nodes can communicate with all other Pods without Network Address Translation.
  • Kubelet running on a node can communicate with all Pods on that same node.

STACKIT Kubernetes Engine (SKE) implements standard Kubernetes networking principles with the usage of two open source implementations: Calico and Cilium.

  1. Generate and fetch a basic cluster configuration using the STACKIT CLI.

  2. Modify the following part of the configuration to set your CNI:

    {
      "network": {
        ...
        "cni": {
          // Use either Calico or Cilium
          "calico": {}
          "cilium": {}
        }
      }
    }

  3. Use the following command to create your SKE cluster using the specified CNI:

    Terminal window
    stackit ske cluster create -p <PROJECT_ID> <CLUSTER_NAME> --payload @cluster-configuration.json

Calico

Section titled “Calico”

Calico is the current default Container Network Interface (CNI) implementation for SKE. It is currently setup using Overlay encapsulation using IPIP and leveraging the BGP peering between nodes to exchange pod routes.

Cilium

Section titled “Cilium”

Built on eBPF instead of iptables, Cilium leverages kernel-level programs to handle packet routing and processing as soon as they hit a Node. By utilizing Kubernetes-specific metadata Cilium achieves highly efficient in-kernel packet processing while sending enriched, context-aware logs back to user space.

Observability

Section titled “Observability”

Using Cilium’s Hubble component a user can gain deep visibility into it’s cluster behavior and communication between services.

By building on top of Cilium, Hubble leverages eBPF for visibility. By relying on eBPF, all visibility is programmable and allows for a dynamic approach that minimizes overhead.

To enable Hubble Observability on an existing cluster update your Cilium configuration of the SKE API:

{
  "network": {
    ...
    "cni": {
      "cilium": {
        "hubble": {
          "enabled": true
        }
      }
    }
  }
}
Terminal window
stackit ske cluster create -p <PROJECT_ID> <CLUSTER_NAME> --payload @cluster-configuration.json

Collecting metrics

Section titled “Collecting metrics”

Hubble exposes metrics about network flows through the Cilium containers. To collect such metrics, one can leverage Prometheus and scrape the Cilium DaemonSet pods on port 9091. Refer to the Cilium documentation to find out more about Hubble metrics.

UI

Section titled “UI”

SKE deploys the Hubble UI component into the cluster when Hubble is enabled which is not exposed by default.

Terminal window
kubectl port-forward -n kube-system svc/hubble-ui 8081:80

Access Hubble UI via http://localhost:8081

Limitations

Section titled “Limitations”

Cilium on SKE has the following limitations:

  • Cilium can only be enabled when creating a new cluster. Existing clusters cannot be upgraded to use Cilium.
  • Use Cilium kube-proxy replacement instead of kube-proxy to implement Kubernetes Services.
  • Cilium uses eBPF to manage your cluster’s network traffic. If you install a third-party application that also uses eBPF, it might interfere with it.

References

Section titled “References”