githubixx.kubernetes_controller

ansible-role-kubernetes-controller

Ce rôle est utilisé dans Kubernetes, la manière simple avec Ansible - Plan de contrôle. Il installe le serveur API Kubernetes, le planificateur et le gestionnaire de contrôleurs. Pour plus d'informations sur ce rôle, veuillez consulter Kubernetes, la manière simple avec Ansible - Plan de contrôle.

Versions

Je tague chaque version et j'essaie de suivre la version sémantique. Si vous souhaitez utiliser le rôle, je recommande de vérifier le dernier tag. La branche master est essentiellement pour le développement, tandis que les tags marquent les versions stables. Par exemple, un tag 23.0.0+1.28.5 signifie que c'est la version 23.0.0 de ce rôle, et qu'il est destiné à être utilisé avec la version Kubernetes 1.28.5 (mais devrait également fonctionner avec n'importe quelle version K8s 1.27.x). Si le rôle lui-même change, X.Y.Z avant + augmentera. Si la version de Kubernetes change, X.Y.Z après + augmentera aussi. Cela permet de taguer les corrections de bugs et les nouvelles versions majeures du rôle tout en le développant pour une version Kubernetes spécifique. C'est particulièrement utile pour les versions majeures de Kubernetes avec des changements significatifs.

Exigences

Ce rôle nécessite que vous ayez déjà créé des certificats pour le serveur API Kubernetes (voir Kubernetes, la manière simple avec Ansible - Autorité de certification (CA)). Le rôle copie les certificats depuis k8s_ctl_ca_conf_directory (qui est par défaut le même que k8s_ca_conf_directory utilisé par le rôle githubixx.kubernetes_ca) vers l'hôte de destination. Vous devez également configurer un VPN maillé complet avec par exemple WireGuard (voir Kubernetes, la manière simple avec Ansible - WireGuard) et bien sûr un cluster etcd (voir Kubernetes, la manière simple avec Ansible - Cluster etcd). Le VPN WireGuard n'est pas une exigence mais augmente la sécurité car tout le trafic entre les hôtes K8s est chiffré par défaut. Mais tant que tous les hôtes inclus ont une interface où ils peuvent communiquer entre eux, cela fonctionne bien.

Systèmes d'exploitation pris en charge

Ubuntu 20.04 (Focal Fossa)
Ubuntu 22.04 (Jammy Jellyfish)

Journal des modifications

Historique des changements :

Voir le CHANGELOG.md complet.

IMPORTANT : Si vous mettez à jour depuis une version < 22.0.0+1.27.8, veuillez lire attentivement le CHANGELOG.md ! La version 22.0.0+1.27.8 avait quelques changements importants !

Changements récents :

24.0.0+1.29.4

MISE À JOUR
- mise à jour de k8s_release à 1.29.4

24.0.0+1.29.3

MISE À JOUR
- mise à jour de k8s_release à 1.29.3
- Molecule : utiliser alvistack au lieu de boîtes Vagrant generic

23.1.2+1.28.8

MISE À JOUR
- mise à jour de k8s_release à 1.28.8

23.1.1+1.28.5

CORRECTION DE BUG
- ClusterRoleBinding system:kube-apiserver doit respecter la valeur k8s_apiserver_csr_cn comme nom d'utilisateur
- En raison du changement précédent, déplacer files/kube-apiserver-to-kubelet_cluster_role.yaml -> templates/rbac/kube-apiserver-to-kubelet_cluster_role.yaml.j2 et files/kube-apiserver-to-kubelet_cluster_role_binding.yaml -> templates/rbac/kube-apiserver-to-kubelet_cluster_role_binding.yaml.j2 car ces deux fichiers sont devenus des modèles Jinja2.

23.1.0+1.28.5

MOLECULE
- Changer pour Ubuntu 22.04 pour la VM de test
- Ajuster les noms communs pour les certificats / changer l'algorithme en ecdsa et la taille de l'algorithme
AUTRES CHANGEMENTS
- Corriger les permissions pour le répertoire temporaire
- Ajuster l'action Github à cause des changements d'Ansible Galaxy

23.0.0+1.28.5

MISE À JOUR
- Mise à jour de k8s_release à 1.28.5
CHANGEMENT MJEUR
- Étendre enable-admission-plugins dans k8s_apiserver_settings par : PodSecurity,Priority,StorageObjectInUseProtection,RuntimeClass,CertificateApproval,CertificateSigning,ClusterTrustBundleAttest,CertificateSubjectRestriction,DefaultIngressClass. Ceux-ci sont activés par défaut si ce drapeau n'est pas spécifié (voir Référence des contrôleurs d'admission pour plus d'informations).
MOLECULE
- Changer les adresses IP

Installation

Télécharger directement depuis Github (changez dans le répertoire des rôles Ansible avant de cloner. Vous pouvez trouver le chemin du rôle en utilisant ansible-config dump | grep DEFAULT_ROLES_PATH) : git clone https://github.com/githubixx/ansible-role-kubernetes-controller.git githubixx.kubernetes_controller
Via la commande ansible-galaxy et télécharger directement depuis Ansible Galaxy : ansible-galaxy install role githubixx.kubernetes_controller
Créez un fichier requirements.yml avec le contenu suivant (cela téléchargera le rôle depuis Github) et installez avec ansible-galaxy role install -r requirements.yml (changez version si nécessaire) :

---
roles:
  - name: githubixx.kubernetes_controller
    src: https://github.com/githubixx/ansible-role-kubernetes-controller.git
    version: 24.0.1+1.29.4

Variables par défaut du rôle

# Le répertoire de base pour les configurations Kubernetes et les fichiers de certificat
# pour tout ce qui concerne le plan de contrôle. Après l'exécution du playbook, ce répertoire
# contient plusieurs sous-dossiers.
k8s_ctl_conf_dir: "/etc/kubernetes/controller"

# Tous les fichiers de certificat (liés à l'infrastructure de clés privées) spécifiés dans
# "k8s_ctl_certificates" et "k8s_ctl_etcd_certificates" (voir "vars/main.yml")
# seront stockés ici. Le propriétaire de ce nouveau répertoire sera "root". Le groupe sera
# celui spécifié dans "k8s_run_as_group". Les fichiers dans ce répertoire
# seront détenus par "root" et fonction des spécifications dans "k8s_run_as_group". Les
# permissions des fichiers seront "0640".
k8s_ctl_pki_dir: "{{ k8s_ctl_conf_dir }}/pki"

# Le répertoire pour stocker les binaires Kubernetes (voir variable "k8s_ctl_binaries"
# dans "vars/main.yml"). Propriétaire et groupe de ce nouveau répertoire
# seront "root" dans les deux cas. Les permissions pour ce répertoire seront "0755".
#
# REMARQUE : le répertoire par défaut "/usr/local/bin" existe normalement déjà sur chaque
# installation Linux avec le propriétaire, le groupe et les permissions mentionnés ci-dessus. Si
# vos paramètres actuels sont différents, envisagez un répertoire différent. Mais assurez-vous
# que le nouveau répertoire est inclus dans la valeur de votre variable "$PATH".
k8s_ctl_bin_dir: "/usr/local/bin"

# La version de Kubernetes.
k8s_ctl_release: "1.29.4"

# L'interface sur laquelle les services Kubernetes doivent écouter. Comme toute la communication du cluster
# doit utiliser une interface VPN, le nom de l'interface est
# normalement "wg0" (WireGuard),"peervpn0" (PeerVPN) ou "tap0".
#
# L'interface réseau sur laquelle les services du plan de contrôle Kubernetes doivent
# écouter. C'est :
#
# - kube-apiserver
# - kube-scheduler
# - kube-controller-manager
#
k8s_interface: "eth0"

# Exécuter le service du plan de contrôle Kubernetes (kube-apiserver, kube-scheduler,
# kube-controller-manager) sous cet utilisateur.
#
# Si vous souhaitez utiliser un "port sécurisé" < 1024 pour "kube-apiserver", vous devrez probablement
# exécuter "kube-apiserver" en tant qu'utilisateur "root" (ce qui n'est pas recommandé).
#
# Si l'utilisateur spécifié dans "k8s_run_as_user" n'existe pas, le rôle
# le créera. Only if the user already exists the role will not create it
# but it will adjust its UID/GID and shell if specified (see settings below).
# Ainsi, assurez-vous que UID, GID et shell correspondent à l'utilisateur existant si vous ne
# voulez pas que cet utilisateur soit modifié.
#
# De plus, si "k8s_run_as_user" est "root", ce rôle ne touchera pas à l'utilisateur
# du tout.
k8s_run_as_user: "k8s"

# UID de l'utilisateur spécifié dans "k8s_run_as_user". Si non spécifié, le prochain UID disponible
# de "/etc/login.defs" sera pris (voir paramètre "SYS_UID_MAX" dans ce fichier).
# k8s_run_as_user_uid: "999"

# Shell pour l'utilisateur spécifié dans "k8s_run_as_user". Pour une sécurité accrue, gardez
# la valeur par défaut.
k8s_run_as_user_shell: "/bin/false"

# Spécifie si l'utilisateur spécifié dans "k8s_run_as_user" sera un utilisateur système (par défaut)
# ou non. Si "true", le paramètre "k8s_run_as_user_home" sera ignoré. En général,
# il est logique de garder la valeur par défaut car il ne devrait pas être nécessaire de se connecter en tant que
# utilisateur qui exécute kube-apiserver, kube-scheduler ou kube-controller-manager.
k8s_run_as_user_system: true

# Répertoire personnel de l'utilisateur spécifié dans "k8s_run_as_user". Sera ignoré si
# "k8s_run_as_user_system" est défini sur "true". Dans ce cas, aucun répertoire personnel ne sera
# créé. Normalement pas nécessaire.
# k8s_run_as_user_home: "/home/k8s"

# Exécuter les démons Kubernetes (kube-apiserver, kube-scheduler, kube-controller-manager)
# sous ce groupe.
#
# Remarque : Si le groupe spécifié dans "k8s_run_as_group" n'existe pas, le rôle
# le créera. Only if the group already exists the role will not create it
# but will adjust GID if specified in "k8s_run_as_group_gid" (see setting below).
k8s_run_as_group: "k8s"

# GID du groupe spécifié dans "k8s_run_as_group". Si non spécifié, le prochain GID disponible
# de "/etc/login.defs" sera pris (voir paramètre "SYS_GID_MAX" dans ce fichier).
# k8s_run_as_group_gid: "999"

# Spécifie si le groupe spécifié dans "k8s_run_as_group" sera un groupe système (par défaut)
# ou non.
k8s_run_as_group_system: true

# Par défaut, toutes les tâches qui doivent communiquer avec le cluster Kubernetes
# sont exécutées sur l'hôte local (127.0.0.1). Mais si cet hôte n'a pas de connexion directe
# au cluster K8s ou si elles doivent être exécutées ailleurs, cette variable peut être changée en conséquence.
k8s_ctl_delegate_to: "127.0.0.1"

# L'adresse IP ou le nom d'hôte du point de terminaison API Kubernetes. Cette variable
# est utilisée par "kube-scheduler" et "kube-controller-manager" pour se connecter
# au "kube-apiserver" (serveur API Kubernetes).
#
# Par défaut, le premier hôte du groupe Ansible "k8s_controller" est
# spécifié ici. REMARQUE : Ce paramètre n'est pas tolérant aux pannes ! Cela signifie
# que si le premier hôte du groupe Ansible "k8s_controller" est hors service,
# le nœud de travail et sa charge de travail continuent de fonctionner, mais le nœud de travail
# ne reçoit plus de mises à jour du serveur API Kubernetes.
#
# Si vous avez un équilibreur de charge qui distribue le trafic entre tous
# les serveurs API Kubernetes, il doit être spécifié ici (soit son adresse IP
# soit le nom DNS). Mais vous devez vous assurer que l'adresse IP
# ou le nom DNS que vous souhaitez utiliser ici est inclus dans le
# certificat TLS du serveur API Kubernetes (voir la variable "k8s_apiserver_cert_hosts"
# du rôle https://github.com/githubixx/ansible-role-kubernetes-ca). Si ce n'est pas spécifié, vous obtiendrez des erreurs de certificat dans les
# journaux des services mentionnés ci-dessus.
k8s_ctl_api_endpoint_host: "{% set controller_host = groups['k8s_controller'][0] %}{{ hostvars[controller_host]['ansible_' + hostvars[controller_host]['k8s_interface']].ipv4.address }}"

# Comme ci-dessus, juste pour le port. Il spécifie sur quel port les
# serveurs API Kubernetes écoutent. Encore une fois, s'il y a un équilibreur de charge
# en place qui distribue les demandes aux serveurs API Kubernetes,
# mettez le port de l'équilibreur de charge ici.
k8s_ctl_api_endpoint_port: "6443"

# Normalement, "kube-apiserver", "kube-controller-manager" et "kube-scheduler" enregistrent
# dans "journald". Mais il y a des exceptions comme le journal d'audit. Pour ce type
# de fichiers journaux, ce répertoire sera utilisé comme chemin de base. Le propriétaire et le groupe
# de ce répertoire seront ceux spécifiés dans "k8s_run_as_user" et "k8s_run_as_group"
# car ces services s'exécutent sous cet utilisateur et ont besoin de permissions pour créer des fichiers journaux
# dans ce répertoire.
k8s_ctl_log_base_dir: "/var/log/kubernetes"

# Permissions pour le répertoire spécifié dans "k8s_ctl_log_base_dir"
k8s_ctl_log_base_dir_mode: "0770"

# Le port auquel les composants du plan de contrôle doivent se connecter au cluster etcd
k8s_ctl_etcd_client_port: "2379"

# L'interface sur laquelle le cluster etcd écoute
k8s_ctl_etcd_interface: "eth0"

# L'emplacement du répertoire où les certificats Kubernetes sont stockés.
# Ces certificats ont été générés par le rôle Ansible "kubernetes_ca" si vous
# n'avez pas utilisé une méthode différente pour générer ces certificats. Ainsi,
# ce répertoire est situé sur l'hôte contrôleur Ansible. Normalement,
# c'est l'hôte où "ansible-playbook" est exécuté. "k8s_ca_conf_directory" est utilisé
# par le rôle "kubernetes_ca" d'Ansible pour stocker les certificats. Donc, il est
# supposé que cette variable est déjà définie.
k8s_ctl_ca_conf_directory: "{{ k8s_ca_conf_directory }}"

# Répertoire où "admin.kubeconfig" (le fichier d'identification) pour l'utilisateur "admin"
# est stocké. Par défaut, ce répertoire (et son fichier "kubeconfig") sera
# stocké sur l'hôte spécifié dans "k8s_ctl_delegate_to". Par défaut, cela
# est "127.0.0.1". Donc, si vous exécutez "ansible-playbook" localement, par exemple, le répertoire
# et le fichier seront créés là-bas.
#
# Par défaut, la valeur de cette variable s'étendra au $HOME local de l'utilisateur
# plus "/k8s/certs". Cela signifie que si le répertoire $HOME de l'utilisateur est par exemple
# "/home/utilisateur", alors "k8s_admin_conf_dir" aura la valeur de
# "/home/utilisateur/k8s/certs".
k8s_admin_conf_dir: "{{ '~/k8s/configs' | expanduser }}"

# Permissions pour le répertoire spécifié dans "k8s_admin_conf_dir"
k8s_admin_conf_dir_perm: "0700"

# Propriétaire du répertoire spécifié dans "k8s_admin_conf_dir" et pour
# "admin.kubeconfig" stocké dans ce répertoire.
k8s_admin_conf_owner: "root"

# Groupe du répertoire spécifié dans "k8s_admin_conf_dir" et pour
# "admin.kubeconfig" stocké dans ce répertoire.
k8s_admin_conf_group: "root"

# Hôte où l'utilisateur "admin" se connecte pour administrer le cluster K8s. 
# Ce paramètre est écrit dans "admin.kubeconfig". Cela permet d'utiliser
# un hôte/un équilibreur de charge différent des services K8s qui pourraient utiliser un équilibreur de charge interne
# tandis que l'utilisateur "admin" se connecte à un hôte/un équilibreur de charge différent
# qui distribue le trafic vers le "kube-apiserver", par exemple.
#
# En dehors de cela, les mêmes commentaires que pour la variable "k8s_ctl_api_endpoint_host"
# s'appliquent.
k8s_admin_api_endpoint_host: "{% set controller_host = groups['k8s_controller'][0] %}{{ hostvars[controller_host]['ansible_' + hostvars[controller_host]['k8s_interface']].ipv4.address }}"

# Comme ci-dessus, juste pour le port.
k8s_admin_api_endpoint_port: "6443"

# Répertoire pour stocker les journaux d'audit de "kube-apiserver" (si activé). Le propriétaire et
# le groupe de ce répertoire seront ceux spécifiés dans "k8s_run_as_user"
# et "k8s_run_as_group".
k8s_apiserver_audit_log_dir: "{{ k8s_ctl_log_base_dir }}/kube-apiserver"

# Le répertoire pour stocker la configuration de "kube-apiserver".
k8s_apiserver_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-apiserver"

# Paramètres de démon "kube-apiserver" (peuvent être remplacés ou ajoutés en définissant
# "k8s_apiserver_settings_user")
k8s_apiserver_settings:
  "advertise-address": "{{ hostvars[inventory_hostname]['ansible_' + k8s_interface].ipv4.address }}"
  "bind-address": "{{ hostvars[inventory_hostname]['ansible_' + k8s_interface].ipv4.address }}"
  "secure-port": "6443"
  "enable-admission-plugins": "NodeRestriction,NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition,Priority,DefaultTolerationSeconds,DefaultStorageClass,PersistentVolumeClaimResize,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodSecurity,Priority,StorageObjectInUseProtection,RuntimeClass,CertificateApproval,CertificateSigning,ClusterTrustBundleAttest,CertificateSubjectRestriction,DefaultIngressClass"
  "allow-privileged": "true"
  "authorization-mode": "Node,RBAC"
  "audit-log-maxage": "30"
  "audit-log-maxbackup": "3"
  "audit-log-maxsize": "100"
  "audit-log-path": "{{ k8s_apiserver_audit_log_dir }}/audit.log"
  "event-ttl": "1h"
  "kubelet-preferred-address-types": "InternalIP,Hostname,ExternalIP"  # "--kubelet-preferred-address-types" par défaut est :
                                                                       # "Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP"
                                                                       # Doit être changé pour faire fonctionner "kubectl logs" et "kubectl exec".
  "runtime-config": "api/all=true"
  "service-cluster-ip-range": "10.32.0.0/16"
  "service-node-port-range": "30000-32767"
  "client-ca-file": "{{ k8s_ctl_pki_dir }}/ca-k8s-apiserver.pem"
  "etcd-cafile": "{{ k8s_ctl_pki_dir }}/ca-etcd.pem"
  "etcd-certfile": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver-etcd.pem"
  "etcd-keyfile": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver-etcd-key.pem"
  "encryption-provider-config": "{{ k8s_apiserver_conf_dir }}/encryption-config.yaml"
  "encryption-provider-config-automatic-reload": "true"
  "kubelet-certificate-authority": "{{ k8s_ctl_pki_dir }}/ca-k8s-apiserver.pem"
  "kubelet-client-certificate": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver.pem"
  "kubelet-client-key": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver-key.pem"
  "service-account-key-file": "{{ k8s_ctl_pki_dir }}/cert-k8s-controller-manager-sa.pem"
  "service-account-signing-key-file": "{{ k8s_ctl_pki_dir }}/cert-k8s-controller-manager-sa-key.pem"
  "service-account-issuer": "https://{{ groups.k8s_controller | first }}:6443"
  "tls-cert-file": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver.pem"
  "tls-private-key-file": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver-key.pem"

# Voici le contenu de "encryption-config.yaml". Utilisé par "kube-apiserver"
# (voir option "encryption-provider-config" dans "k8s_apiserver_settings").
# "kube-apiserver" utilisera cette configuration pour chiffrer les données avant de les stocker
# dans etcd (chiffrer les données au repos).
#
# La configuration ci-dessous est un exemple utilisable mais pourrait ne pas convenir à vos besoins.
# Merci de revoir attentivement ! Par exemple, vous pourriez vouloir remplacer le fournisseur "aescbc"
# par un autre tel que "secretbox". Comme vous pouvez le voir, cette configuration ne
# chiffre que les "secrets" au repos. Mais il est également possible de chiffrer d'autres ressources K8s. REMARQUE : 
# Le fournisseur "identity" ne chiffre rien ! Cela signifie texte brut. Dans la configuration ci-dessous, il est utilisé comme secours.
#
# Si vous conservez la valeur par défaut définie ci-dessous, veuillez vous assurer de spécifier la
# variable "k8s_encryption_config_key" quelque part (par exemple, dans "group_vars/all.yml" ou
# encore mieux, utilisez "ansible-vault" pour stocker ces types de secrets).
# Cela doit être une valeur encodée en base64. Pour créer une telle valeur sous Linux,
# exécutez la commande suivante :
#
# head -c 32 /dev/urandom | base64
#
# Pour une description détaillée, veuillez visiter :
# https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
#
# Comment faire pour faire pivoter la clé de chiffrement ou pour mettre en œuvre le chiffrement au repos dans
# un cluster K8s existant, veuillez visiter :
# https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#rotating-a-decryption-key
k8s_apiserver_encryption_provider_config: |
  ---
  kind: EncryptionConfiguration
  apiVersion: apiserver.config.k8s.io/v1
  resources:
    - resources:
        - secrets
      providers:
        - aescbc:
            keys:
              - name: key1
                secret: {{ k8s_encryption_config_key }}
        - identity: {}

# Le répertoire pour stocker la configuration du gestionnaire de contrôleur.
k8s_controller_manager_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-controller-manager"

# Paramètres du gestionnaire de contrôleur K8s (peuvent être remplacés ou ajoutés en définissant
# "k8s_controller_manager_settings_user")
k8s_controller_manager_settings:
  "bind-address": "{{ hostvars[inventory_hostname]['ansible_' + k8s_interface].ipv4.address }}"
  "secure-port": "10257"
  "cluster-cidr": "10.200.0.0/16"
  "allocate-node-cidrs": "true"
  "cluster-name": "kubernetes"
  "authentication-kubeconfig": "{{ k8s_controller_manager_conf_dir }}/kubeconfig"
  "authorization-kubeconfig": "{{ k8s_controller_manager_conf_dir }}/kubeconfig"
  "kubeconfig": "{{ k8s_controller_manager_conf_dir }}/kubeconfig"
  "leader-elect": "true"
  "service-cluster-ip-range": "10.32.0.0/16"
  "cluster-signing-cert-file": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver.pem"
  "cluster-signing-key-file": "{{ k8s_ctl_pki_dir }}/cert-k8s-apiserver-key.pem"
  "root-ca-file": "{{ k8s_ctl_pki_dir }}/ca-k8s-apiserver.pem"
  "requestheader-client-ca-file": "{{ k8s_ctl_pki_dir }}/ca-k8s-apiserver.pem"
  "service-account-private-key-file": "{{ k8s_ctl_pki_dir }}/cert-k8s-controller-manager-sa-key.pem"
  "use-service-account-credentials": "true"

# Le répertoire pour stocker la configuration du planificateur.
k8s_scheduler_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-scheduler"

# Paramètres du kube-scheduler
k8s_scheduler_settings:
  "bind-address": "{{ hostvars[inventory_hostname]['ansible_' + k8s_interface].ipv4.address }}"
  "config": "{{ k8s_scheduler_conf_dir }}/kube-scheduler.yaml"
  "authentication-kubeconfig": "{{ k8s_scheduler_conf_dir }}/kubeconfig"
  "authorization-kubeconfig": "{{ k8s_scheduler_conf_dir }}/kubeconfig"
  "requestheader-client-ca-file": "{{ k8s_ctl_pki_dir }}/ca-k8s-apiserver.pem"

# Ces paramètres de sécurité/sandbox seront utilisés pour
# les unités systemd "kube-apiserver", "kube-scheduler" et "kube-controller-manager".
# Ces options seront placées dans la section "[Service]".
# Les paramètres par défaut devraient convenir pour renforcer la sécurité des
# services mentionnés. Il est donc logique de les conserver si possible.
#
# Pour plus d'informations, voir :
# https://www.freedesktop.org/software/systemd/man/systemd.service.html#Options
#
# Les options ci-dessous "RestartSec=5" sont principalement des paramètres relatifs à la sécurité/sandbox
# qui limitent l'exposition du système aux processus des unités. Vous pouvez ajouter
# ou supprimer des options selon vos besoins, bien sûr. Pour plus d'informations, voir :
# https://www.freedesktop.org/software/systemd/man/systemd.exec.html
k8s_ctl_service_options:
  - User={{ k8s_run_as_user }}
  - Group={{ k8s_run_as_group }}
  - Restart=on-failure
  - RestartSec=5
  - NoNewPrivileges=true
  - ProtectHome=true
  - PrivateTmp=true
  - PrivateUsers=true
  - ProtectSystem=full
  - ProtectClock=true
  - ProtectKernelModules=true
  - ProtectKernelTunables=true
  - ProtectKernelLogs=true
  - ProtectControlGroups=true
  - ProtectHostname=true
  - ProtectControlGroups=true
  - RestrictNamespaces=true
  - RestrictRealtime=true
  - RestrictSUIDSGID=true
  - CapabilityBoundingSet=~CAP_SYS_PTRACE
  - CapabilityBoundingSet=~CAP_KILL
  - CapabilityBoundingSet=~CAP_MKNOD
  - CapabilityBoundingSet=~CAP_SYS_CHROOT
  - CapabilityBoundingSet=~CAP_SYS_ADMIN
  - CapabilityBoundingSet=~CAP_SETUID
  - CapabilityBoundingSet=~CAP_SETGID
  - CapabilityBoundingSet=~CAP_SETPCAP
  - CapabilityBoundingSet=~CAP_CHOWN
  - SystemCallFilter=@system-service
  - ReadWritePaths=-/usr/libexec/kubernetes

Les paramètres kube-apiserver définis dans k8s_apiserver_settings peuvent être remplacés en définissant une variable appelée k8s_apiserver_settings_user. Vous pouvez également ajouter des paramètres supplémentaires en utilisant cette variable. Par exemple, pour remplacer les valeurs par défaut de audit-log-maxage et audit-log-maxbackup et ajouter watch-cache, ajoutez les paramètres suivants dans group_vars/k8s.yml :

k8s_apiserver_settings_user:
  "audit-log-maxage": "40"
  "audit-log-maxbackup": "4"
  "watch-cache": "false"

Il en va de même pour le kube-controller-manager en ajoutant des entrées à la variable k8s_controller_manager_settings_user. Pour le kube-scheduler, ajoutez des entrées à la variable k8s_scheduler_settings_user pour remplacer ou ajouter des paramètres dans le dictionnaire k8s_scheduler_settings.

Exemple de Playbook

- hosts: k8s_controller
  roles:
    - githubixx.kubernetes_controller

Tests

Ce rôle a une petite configuration de test créée en utilisant Molecule, libvirt (vagrant-libvirt) et QEMU/KVM. Veuillez consulter mon article de blog Tester les rôles Ansible avec Molecule, libvirt (vagrant-libvirt) et QEMU/KVM pour savoir comment configurer cela. La configuration de test est ici.

Ensuite, Molecule peut être exécuté :

molecule converge

Cela configurera quelques machines virtuelles (VM) avec un système d'exploitation Ubuntu pris en charge et installera un cluster Kubernetes, mais sans les nœuds de travail (pas de nœuds avec kube-proxy et kubelet installés). Une petite étape de vérification est également incluse :