github.com/datadog/cilium@v1.6.12/Documentation/kubernetes/concepts.rst (about)

     1  .. only:: not (epub or latex or html)
     2  
     3      WARNING: You are looking at unreleased Cilium documentation.
     4      Please use the official rendered version released here:
     5      http://docs.cilium.io
     6  
     7  ******************
     8  Concepts
     9  ******************
    10  
    11  .. _k8s_concepts_deployment:
    12  
    13  Deployment
    14  ==========
    15  
    16  The configuration of a standard Cilium Kubernetes deployment consists of
    17  several Kubernetes resources:
    18  
    19  * A ``DaemonSet`` resource:  describes the Cilium pod that is deployed to each
    20    Kubernetes node.  This pod runs the cilium-agent and associated daemons. The
    21    configuration of this DaemonSet includes the image tag indicating the exact
    22    version of the Cilium docker container (e.g., v1.0.0) and command-line
    23    options passed to the cilium-agent.
    24  
    25  * A ``ConfigMap`` resource:  describes common configuration values that are
    26    passed to the cilium-agent, such as the kvstore endpoint and credentials,
    27    enabling/disabling debug mode, etc.
    28  
    29  * ``ServiceAccount``, ``ClusterRole``, and ``ClusterRoleBindings`` resources:
    30    the identity and permissions used by cilium-agent to access the Kubernetes
    31    API server when Kubernetes RBAC is enabled.
    32  
    33  * A ``Secret`` resource: describes the credentials use access the etcd kvstore,
    34    if required.
    35  
    36  Networking For Existing Pods
    37  ============================
    38  
    39  In case pods were already running before the Cilium `DaemonSet` was deployed,
    40  these pods will still be connected using the previous networking plugin
    41  according to the CNI configuration. A typical example for this is the
    42  ``kube-dns`` service which runs in the ``kube-system`` namespace by default.
    43  
    44  A simple way to change networking for such existing pods is to rely on the fact
    45  that Kubernetes automatically restarts pods in a Deployment if they are
    46  deleted, so we can simply delete the original kube-dns pod and the replacement
    47  pod started immediately after will have networking managed by Cilium.  In a
    48  production deployment, this step could be performed as a rolling update of
    49  kube-dns pods to avoid downtime of the DNS service.
    50  
    51  ::
    52  
    53          $ kubectl --namespace kube-system delete pods -l k8s-app=kube-dns
    54          pod "kube-dns-268032401-t57r2" deleted
    55  
    56  Running ``kubectl get pods`` will show you that Kubernetes started a new set of
    57  ``kube-dns`` pods while at the same time terminating the old pods:
    58  
    59  ::
    60  
    61          $ kubectl --namespace kube-system get pods
    62          NAME                          READY     STATUS        RESTARTS   AGE
    63          cilium-5074s                  1/1       Running       0          58m
    64          kube-addon-manager-minikube   1/1       Running       0          59m
    65          kube-dns-268032401-j0vml      3/3       Running       0          9s
    66          kube-dns-268032401-t57r2      3/3       Terminating   0          57m
    67  
    68  
    69  Default Ingress Allow from Local Host
    70  =====================================
    71  
    72  Kubernetes has functionality to indicate to users the current health of their
    73  applications via `Liveness Probes and Readiness Probes <https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/>`_.
    74  In order for ``kubelet`` to run these health checks for each pod, by default,
    75  Cilium will always allow all ingress traffic from the local host to each pod. 
    76