Installation Overview

Vue d’ensemble des ressources Kubernetes et des manifests créés par Cilium, expliquant les agents, Envoy, l’operator, les ConfigMaps, les ServiceAccounts, le RBAC, les CRDs, et les méthodes d’installation

Cette leçon explique quelles ressources Kubernetes Cilium crée lors de l’installation et pourquoi chacune existe. Les leçons suivantes couvriront en détail les méthodes d’installation (Cilium CLI vs Helm) ainsi que des recommandations pour choisir la bonne option selon votre environnement.

À un niveau élevé, installer Cilium va créer :

• Un DaemonSet pour exécuter l’agent Cilium sur chaque nœud
• Un DaemonSet pour exécuter Envoy (par nœud) pour les fonctionnalités L7
• Un Deployment pour le cilium-operator (contrôleur cluster-scoped)
• Des ConfigMaps pour la configuration de l’agent et de Envoy
• Des ServiceAccounts pour chaque composant
• Des RBAC ClusterRoles et ClusterRoleBindings
• Des CustomResourceDefinitions (CRDs) utilisées par Cilium (politiques et observabilité)

Ci-dessous, des manifests Kubernetes représentatifs et des explications concises des composants principaux afin que vous puissiez reconnaître ce qui est déployé et pourquoi.

Ressources principales de Cilium et leur rôle

Cilium Agent¶

DaemonSet¶

Cilium Agent

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cilium
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: cilium
  template:
    metadata:
      labels:
        k8s-app: cilium
    spec:
      containers:
      - name: cilium-agent
        image: "quay.io/cilium/cilium:latest"
        # args, env, volumes, securityContext omis pour concision

Ce DaemonSet garantit qu’un agent Cilium s’exécute sur chaque nœud et gère:

• La programmation du datapath
• L’allocation d’identité
• L’application des politiques
• La télémétrie locale au nœud
• D’autres responsabilités liées au réseau du nœud

ConfigMap¶

(paramètres agent)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  identity-allocation-mode: crd
  identity-heartbeat-timeout: "30m0s"
  identity-gc-interval: "15m0s"
  cilium-endpoint-gc-interval: "5m0s"
  nodes-gc-interval: "5m0s"
  debug: "false"
  enable-policy: "default"

Ce ConfigMap contient les paramètres de l’agent :

• mode d’identité
• intervalles de GC
• debug
• mode de politique
• options de datapath / tunneling

Cilium Envoy¶

Envoy peut être : - intégré au pod Cilium agent - ou déployé en DaemonSet séparé

DaemonSet¶

Cilium Envoy (proxy L7)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cilium-envoy
  namespace: kube-system
  labels:
    k8s-app: cilium-envoy
spec:
  selector:
    matchLabels:
      k8s-app: cilium-envoy
  template:
    metadata:
      labels:
        k8s-app: cilium-envoy
    spec:
      containers:
      - name: cilium-envoy
        image: "quay.io/cilium/cilium-envoy:latest"
        # config, args, mounts, probes omis

• Un DaemonSet optionnel pour exécuter Envoy (fonctionnalités L7)

Le DaemonSet Envoy fournit un proxy L7 par nœud pour HTTP/gRPC ainsi qu’une télémétrie avancée. Envoy fonctionne aux côtés de l’agent Cilium et gère les politiques L7 et l’observabilité lorsque ces fonctionnalités sont activées.

ConfigMap¶

(bootstrap Envoy)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-envoy-config
  namespace: kube-system
data:
  bootstrap-config.json: |
    {
      "admin": {
        "address": {
          "pipe": {
            "path": "/var/run/cilium/envoy/sockets/admin.sock"
          }
        },
        "applicationLogConfig": {
          "logFormat": {
            "textFormat": "[%Y-%m-%d %T.%e][%t][%l][%n] [%g:%#] %v"
          }
        }
      },
      "bootstrapExtensions": [
        {
          "name": "envoy.bootstrap.internal_listener",
          "typedConfig": {}
        }
      ]
    }

Envoy nécessite une configuration de bootstrap (JSON/YAML). La clé bootstrap-config.json doit rester inchangée pour garantir la compatibilité.

Cilium Operator¶

Deployment¶

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cilium-operator
  namespace: kube-system
  labels:
    io.cilium/app: operator
spec:
  replicas: 2
  selector:
    matchLabels:
      io.cilium/app: operator
  template:
    metadata:
      labels:
        io.cilium/app: operator
    spec:
      containers:
      - name: cilium-operator
        image: "quay.io/cilium/operator-generic:latest"
        # args + permissions RBAC requis

L’operator est un contrôleur cluster-scoped qui :

• réconcilie les CRDs Cilium
• effectue le garbage collection (GC)
• coordonne l’état des nœuds
• gère les workflows globaux du cluster

Exécuter plusieurs réplicas améliore la disponibilité.

ServiceAccounts¶

apiVersion: v1
kind: ServiceAccount
metadata:
  name: "cilium"
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: "cilium-envoy"
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: "cilium-operator"
  namespace: kube-system

Chaque composant utilise un ServiceAccount dédié afin d’appliquer le principe du moindre privilège via RBAC.

RBAC : ClusterRole et Binding (exemple agent)¶

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cilium
  labels:
    app.kubernetes.io/part-of: cilium
rules:
  # permissions nécessaires : nodes, pods, endpoints, etc.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cilium
  labels:
    app.kubernetes.io/part-of: cilium
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cilium
subjects:
- kind: ServiceAccount
  name: "cilium"
  namespace: kube-system

Les ClusterRole et ClusterRoleBinding accordent les permissions nécessaires à l’échelle du cluster.

⚠️ Attention Cilium nécessite des privilèges élevés pour observer et manipuler des objets Kubernetes (nodes, pods, endpoints, CRDs). Vérifiez toujours les règles RBAC avant un déploiement en production.

CustomResourceDefinitions (CRDs)¶

Cilium installe plusieurs CRDs permettant :

• la gestion des politiques réseau
• la visibilité
• la gestion des endpoints

Exemples :

• CiliumNetworkPolicy
• CiliumClusterwideNetworkPolicy
• CiliumEndpoint

Résumé après installation¶

Après installation, vous trouverez :

• Pods node-local : cilium, cilium-envoy (DaemonSets)
• Contrôleur cluster : cilium-operator (Deployment)
• Configuration : ConfigMaps
• Sécurité : ServiceAccounts + RBAC
• APIs : CRDs Cilium

💡 Astuce Inspectez le namespace kube-system pour voir :

• DaemonSets : cilium, cilium-envoy
• Deployment : cilium-operator
• ConfigMaps
• ServiceAccounts
• CRDs

Méthodes d’installation¶

Cilium CLI¶

• CLI officielle : cilium
• Génère et applique les manifests adaptés à l’environnement
• Utilise Helm templates en interne
• Pas besoin d’installer Helm

Helm¶

• Installation via le chart officiel
• Contrôle granulaire des valeurs
• Intégration naturelle avec GitOps