The configuration of a standard Cilium Kubernetes deployment consists of
several Kubernetes resources:

A DaemonSet resource: describes the Cilium pod that is deployed to each
Kubernetes node. This pod runs the cilium-agent and associated daemons. The
configuration of this DaemonSet includes the image tag indicating the exact
version of the Cilium docker container (e.g., v1.0.0) and command-line
options passed to the cilium-agent.

A ConfigMap resource: describes common configuration values that are
passed to the cilium-agent, such as the kvstore endpoint and credentials,
enabling/disabling debug mode, etc.

ServiceAccount, ClusterRole, and ClusterRoleBindings resources:
the identity and permissions used by cilium-agent to access the Kubernetes
API server when Kubernetes RBAC is enabled.

A Secret resource: describes the credentials use access the etcd kvstore,
if required.

In case pods were already running before the Cilium DaemonSet was deployed,
these pods will still be connected using the previous networking plugin
according to the CNI configuration. A typical example for this is the
kube-dns service which runs in the kube-system namespace by default.

A simple way to change networking for such existing pods is to rely on the fact
that Kubernetes automatically restarts pods in a Deployment if they are
deleted, so we can simply delete the original kube-dns pod and the replacement
pod started immediately after will have networking managed by Cilium. In a
production deployment, this step could be performed as a rolling update of
kube-dns pods to avoid downtime of the DNS service.

Kubernetes has functionality to indicate to users the current health of their
applications via Liveness Probes and Readiness Probes.
In order for kubelet to run these health checks for each pod, by default,
Cilium will always allow all ingress traffic from the local host to each pod.