cilium

Application

cilium/cilium

eBPF-based networking, security, and observability for Kubernetes clusters.

Overview

Cilium is a cloud-native networking, observability, and security solution powered by an eBPF dataplane. It provides L3-L7 network policy enforcement, distributed load balancing that can replace kube-proxy, and deep visibility into traffic. It supports overlay and native routing modes, multi-cluster connectivity, and service mesh features.

README Preview

.. raw:: html\n\n   \n      \n      \n   \n\n|cii| |go-report| |clomonitor| |artifacthub| |slack| |go-doc| |rtd| |apache| |bsd| |gpl| |fossa| |gateway-api| |codespaces|\n\nCilium is a networking, observability, and security solution with an eBPF-based\ndataplane. It provides a simple flat Layer 3 network with the ability to span\nmultiple clusters in either a native routing or overlay mode. It is L7-protocol\naware and can enforce network policies on L3-L7 using an identity-based security\nmodel that is decoupled from network addressing.\n\nCilium implements distributed load balancing for traffic between pods and to\nexternal services, and is able to fully replace kube-proxy, using efficient\nhash tables in eBPF, allowing for almost unlimited scale. It also supports\nadvanced functionality like integrated ingress and egress gateways, bandwidth\nmanagement, and service mesh, and provides deep network and security visibility and monitoring.\n\nA new Linux kernel technology called eBPF_ is at the foundation of Cilium. It\nsupports dynamic insertion of eBPF bytecode into the Linux kernel at various\nintegration points such as: network IO, application sockets, and tracepoints to\nimplement security, networking, and visibility logic. eBPF is highly efficient\nand flexible. To learn more about eBPF, visit `eBPF.io`_.\n\n.. image:: Documentation/images/cilium-overview.png\n   :alt: Overview of Cilium features for networking, observability, service mesh, and runtime security\n\n.. raw:: html\n\n   \n      \n         \n         \n      \n   \n   \n      \n         \n         \n      \n   \n\nStable Releases\n===============\n\nThe Cilium community maintains minor stable releases for the last three minor\nCilium versions. Older Cilium stable versions from minor releases prior to that\nare considered EOL.\n\nFor upgrades to new minor releases, please consult the `Cilium Upgrade Guide`_.\n\nListed below are the actively maintained release branches along with their latest\npatch 

FAQ (1)

Troubleshooting
Why do connections from a worker node to a Cilium ingress service on the same node fail with 'upstream connect error or disconnect/reset before headers'?

This is a confirmed regression introduced in Cilium 1.17.6 (still present in 1.18.x, 1.19.x and 1.20.0-pre). When Cilium ingress (or Gateway API with hostNetwork envoy) is enabled with kubeProxyReplacement, a pod or process on node-A cannot reach the ingress LoadBalancer IP of a backend pod running on the same node-A. Connections from other nodes work fine. Envoy returns HTTP 503 'upstream connect error or disconnect/reset before headers. reset reason: connection timeout'. Workaround: downgrade to Cilium 1.17.5, which the reporter verified restores same-node ingress connectivity, e.g. helm upgrade cilium cilium/cilium --version 1.17.5 -n kube-system -f values.yaml. No root-cause fix has been released yet (GitHub issue #44529 is unresolved). If you are affected, collect diagnostics with cilium sysdump and attach it to the issue to help maintainers investigate.

GitHub Issue #44529