githubixx.kubernetes_controller

Descripción general Versiones Perspectivas

rol-ansible-kubernetes-controlador

Este rol se utiliza en Kubernetes de una manera no tan difícil con Ansible - Plano de control. Instala el servidor de API de Kubernetes, el programador y el administrador del controlador. Para más información sobre este rol, consulta Kubernetes de una manera no tan difícil con Ansible - Plano de control.

Versiones

Etiquetamos cada lanzamiento y tratamos de seguir versionamiento semántico. Si deseas usar el rol, te recomiendo usar la última etiqueta. La rama principal es principalmente desarrollo, mientras que las etiquetas marcan lanzamientos estables. Sin embargo, en general, trato de mantener la rama principal en buen estado. Una etiqueta 23.0.0+1.28.5 significa que es el lanzamiento 23.0.0 de este rol y está destinado a ser usado con la versión de Kubernetes 1.28.5 (pero debería funcionar con cualquier lanzamiento de K8s 1.27.x, por supuesto). Si el rol cambia, X.Y.Z antes de + aumentará. Si la versión de Kubernetes cambia, X.Y.Z después de + también aumentará. Esto permite etiquetar correcciones de errores y nuevas versiones principales del rol mientras aún se desarrolla para un lanzamiento específico de Kubernetes. Esto es especialmente útil para lanzamientos importantes de Kubernetes con cambios significativos.

Requisitos

Este rol requiere que ya hayas creado algunos certificados para el servidor de API de Kubernetes (ver Kubernetes de una manera no tan difícil con Ansible - Autoridad certificadora (CA)). El rol copia los certificados desde k8s_ctl_ca_conf_directory (que por defecto es el mismo que k8s_ca_conf_directory utilizado por el rol githubixx.kubernetes_ca) al host de destino. También deberías configurar una VPN totalmente malla con, por ejemplo, WireGuard (ver Kubernetes de una manera no tan difícil con Ansible - WireGuard) y, por supuesto, un clúster etcd (ver Kubernetes de una manera no tan difícil con Ansible - clúster etcd). La malla VPN de WireGuard no es un requisito, pero aumenta la seguridad ya que todo el tráfico entre los hosts K8s está encriptado por defecto. Pero mientras todos los hosts incluidos tengan una interfaz donde puedan comunicarse entre sí, está bien.

Sistemas Operativos Soportados

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

Registro de Cambios

Historial de cambios:

Consulta el CHANGELOG.md completo.

IMPORTANTE: Si actualizas desde una versión < 22.0.0+1.27.8, ¡por favor lee el CHANGELOG.md con cuidado! La versión 22.0.0+1.27.8 tuvo varios cambios significativos.

Cambios recientes:

24.0.0+1.29.4

ACTUALIZACIÓN
- Actualiza k8s_release a 1.29.4

24.0.0+1.29.3

ACTUALIZACIÓN
- Actualiza k8s_release a 1.29.3
- Molecule: usa alvistack en lugar de cajas Vagrant generic

23.1.2+1.28.8

ACTUALIZACIÓN
- Actualiza k8s_release a 1.28.8

23.1.1+1.28.5

CORRECCIÓN DE ERRORES
- ClusterRoleBinding system:kube-apiserver necesita honrar el valor de k8s_apiserver_csr_cn como nombre de usuario.
- Debido al cambio anterior, mueve files/kube-apiserver-to-kubelet_cluster_role.yaml -> templates/rbac/kube-apiserver-to-kubelet_cluster_role.yaml.j2 y files/kube-apiserver-to-kubelet_cluster_role_binding.yaml -> templates/rbac/kube-apiserver-to-kubelet_cluster_role_binding.yaml.j2, ya que ambos archivos se convirtieron en una plantilla Jinja2.

23.1.0+1.28.5

MOLECULA
- Cambia a Ubuntu 22.04 para VM de prueba
- Ajusta nombres comunes para certificados/cambia el algoritmo a ecdsa y tamaño del algoritmo
OTROS CAMBIOS
- Corrige permisos para el directorio temporal
- Ajusta la acción de Github debido a cambios en Ansible Galaxy

23.0.0+1.28.5

ACTUALIZACIÓN
- Actualiza k8s_release a 1.28.5
CAMBIO SIGNIFICATIVO
- Amplía enable-admission-plugins en k8s_apiserver_settings por: PodSecurity,Priority,StorageObjectInUseProtection,RuntimeClass,CertificateApproval,CertificateSigning,ClusterTrustBundleAttest,CertificateSubjectRestriction,DefaultIngressClass. Estos están habilitados por defecto si esta bandera no se especifica (ver Referencia de Controladores de Admisión para más información).
MOLECULA
- Cambia direcciones IP

Instalación

Descarga directamente desde Github (Cambia al directorio de roles de Ansible antes de clonar. Puedes encontrar la ruta del rol usando ansible-config dump | grep DEFAULT_ROLES_PATH): git clone https://github.com/githubixx/ansible-role-kubernetes-controller.git githubixx.kubernetes_controller
A través del comando ansible-galaxy y descarga directamente desde Ansible Galaxy: ansible-galaxy install role githubixx.kubernetes_controller
Crea un archivo requirements.yml con el siguiente contenido (esto descargará el rol desde Github) e instala con ansible-galaxy role install -r requirements.yml (cambia version si es necesario):

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

Variables del rol (por defecto)

# El directorio base para la configuración de Kubernetes y archivos
# de certificado para todo lo relacionado con el plano de control. Después de 
# que el playbook esté completo, este directorio contendrá varias subcarpetas.
k8s_ctl_conf_dir: "/etc/kubernetes/controller"

# Todos los archivos de certificado (relacionados con la Infraestructura de Clave Privada) 
# especificados en "k8s_ctl_certificates" y "k8s_ctl_etcd_certificates" 
# (ver "vars/main.yml") se almacenarán aquí. El propietario de este nuevo directorio 
# será "root". El grupo será el grupo especificado en "k8s_run_as_group". Los archivos 
# en este directorio serán propiedad de "root" y del grupo especificado en "k8s_run_as_group". 
# Los permisos del archivo serán "0640".
k8s_ctl_pki_dir: "{{ k8s_ctl_conf_dir }}/pki"

# El directorio para almacenar los binarios de Kubernetes (ver "k8s_ctl_binaries"
# variable en "vars/main.yml"). El propietario y grupo de este nuevo directorio 
# serán "root" en ambos casos. Los permisos para este directorio serán "0755".
#
# NOTA: El directorio por defecto "/usr/local/bin" normalmente ya existe en cada
# instalación de Linux con el propietario, grupo y permisos mencionados arriba. Si
# tus configuraciones actuales son diferentes considera usar otro directorio. Pero asegúrate
# de que el nuevo directorio esté incluido en el valor de tu variable "$PATH".
k8s_ctl_bin_dir: "/usr/local/bin"

# La versión de Kubernetes.
k8s_ctl_release: "1.29.4"

# La interfaz en la que los servicios de Kubernetes deben escuchar. Dado que toda la 
# comunicación del clúster debe usar una interfaz de VPN, el nombre de la interfaz 
# normalmente es "wg0" (WireGuard), "peervpn0" (PeerVPN) o "tap0".
#
# La interfaz de red en la que los servicios del plano de control de Kubernetes deben
# escuchar. Es decir:
#
# - kube-apiserver
# - kube-scheduler
# - kube-controller-manager
#
k8s_interface: "eth0"

# Ejecuta los servicios del plano de control de Kubernetes (kube-apiserver, kube-scheduler,
# kube-controller-manager) como este usuario.
#
# Si deseas usar un "secure-port" < 1024 para "kube-apiserver", probablemente necesites
# ejecutar "kube-apiserver" como usuario "root" (no recomendado).
#
# Si el usuario especificado en "k8s_run_as_user" no existe, entonces el rol 
# lo creará. Solo si el usuario ya existe, el rol no lo creará, pero ajustará su 
# UID/GID y shell si se especifica (ver configuraciones a continuación).
# Así que asegúrate de que el UID, GID y shell coincidan con el usuario existente si no
# deseas que ese usuario cambie.
#
# Además, si "k8s_run_as_user" es "root", entonces este rol no tocará al usuario
# en absoluto.
k8s_run_as_user: "k8s"

# UID del usuario especificado en "k8s_run_as_user". Si no se especifica, el siguiente 
# UID disponible de "/etc/login.defs" será tomado (ver configuración "SYS_UID_MAX" en 
# ese archivo).
# k8s_run_as_user_uid: "999"

# Shell para el usuario especificado en "k8s_run_as_user". Para mayor seguridad, mantén
# el valor por defecto.
k8s_run_as_user_shell: "/bin/false"

# Especifica si el usuario especificado en "k8s_run_as_user" será un usuario del sistema 
# (por defecto) o no. Si "true", la configuración "k8s_run_as_user_home" será ignorada. 
# En general, tiene sentido mantener la configuración por defecto, ya que no debería 
# ser necesario iniciar sesión como el usuario que ejecuta kube-apiserver, kube-scheduler 
# o kube-controller-manager.
k8s_run_as_user_system: true

# Directorio personal del usuario especificado en "k8s_run_as_user". Será ignorado si
# "k8s_run_as_user_system" está configurado como "true". En este caso, no se creará 
# ningún directorio personal. Normalmente no es necesario.
# k8s_run_as_user_home: "/home/k8s"

# Ejecuta los demonios de Kubernetes (kube-apiserver, kube-scheduler, kube-controller-manager)
# como este grupo.
#
# Nota: Si el grupo especificado en "k8s_run_as_group" no existe, entonces el rol
# lo creará. Solo si el grupo ya existe, el rol no lo creará, pero ajustará el GID 
# si se especifica en "k8s_run_as_group_gid" (ver configuración a continuación).
k8s_run_as_group: "k8s"

# GID del grupo especificado en "k8s_run_as_group". Si no se especifica, el siguiente 
# GID disponible de "/etc/login.defs" será tomado (ver configuración "SYS_GID_MAX" en 
# ese archivo).
# k8s_run_as_group_gid: "999"

# Especifica si el grupo especificado en "k8s_run_as_group" será un grupo del sistema 
# (por defecto) o no.
k8s_run_as_group_system: true

# Por defecto, todas las tareas que necesitan comunicarse con el clúster de Kubernetes
# se ejecutan en el host local (127.0.0.1). Pero si ese no tiene conexión directa 
# al clúster de K8s o si se debe ejecutar en otro lugar, esta variable puede cambiarse
# adecuadamente.
k8s_ctl_delegate_to: "127.0.0.1"

# La dirección IP o el nombre de host del punto final de la API de Kubernetes. Esta variable
# es utilizada por "kube-scheduler" y "kube-controller-manager" para conectarse 
# al "kube-apiserver" (servidor de API de Kubernetes).
#
# Por defecto, aquí se especifica el primer host en el grupo de Ansible "k8s_controller".
# NOTA: ¡Esta configuración no es tolerante a fallos! Eso significa que si el primer 
# host en el grupo de Ansible "k8s_controller" está inactivo, el nodo de trabajo y su 
# carga de trabajo continuarán funcionando, pero el nodo de trabajo no recibirá 
# ninguna actualización del servidor de API de Kubernetes.
#
# Si tienes un balanceador de carga que distribuye el tráfico entre todos los 
# servidores de API de Kubernetes, debería especificarse aquí (ya sea su dirección IP 
# o su nombre DNS). Pero debes asegurarte de que la dirección IP o el nombre DNS 
# que deseas usar aquí esté incluido en el certificado TLS del servidor de API de Kubernetes 
# (ver la variable "k8s_apiserver_cert_hosts" del rol https://github.com/githubixx/ansible-role-kubernetes-ca). 
# Si no está especificado, recibirás errores de certificado en los 
# registros de los servicios mencionados anteriormente.
k8s_ctl_api_endpoint_host: "{% set controller_host = groups['k8s_controller'][0] %}{{ hostvars[controller_host]['ansible_' + hostvars[controller_host]['k8s_interface']].ipv4.address }}"

# Igual que arriba, pero para el puerto. Especifica en qué puerto los
# servidores de API de Kubernetes están escuchando. Nuevamente, si hay un balanceador de carga 
# en su lugar que distribuye las solicitudes a los servidores de API de Kubernetes,
# coloca el puerto del balanceador de carga aquí.
k8s_ctl_api_endpoint_port: "6443"

# Normalmente, "kube-apiserver", "kube-controller-manager" y "kube-scheduler" 
# registran en "journald". Pero hay excepciones como el registro de auditoría. 
# Para este tipo de archivos de registro, este directorio se utilizará como ruta base. 
# El propietario y el grupo de este directorio serán los especificados en "k8s_run_as_user" 
# y "k8s_run_as_group", ya que estos servicios se ejecutan como este usuario y 
# necesitan permisos para crear archivos de registro en este directorio.
k8s_ctl_log_base_dir: "/var/log/kubernetes"

# Permisos para el directorio especificado en "k8s_ctl_log_base_dir"
k8s_ctl_log_base_dir_mode: "0770"

# El puerto al que los componentes del plano de control deben conectarse al clúster etcd.
k8s_ctl_etcd_client_port: "2379"

# La interfaz en la que el clúster etcd está escuchando.
k8s_ctl_etcd_interface: "eth0"

# La ubicación del directorio donde se almacenan los certificados de Kubernetes.
# Estos certificados fueron generados por el rol de Ansible "kubernetes_ca" si no 
# has usado un método diferente para generar estos certificados. Así que este
# directorio está ubicado en el host del controlador de Ansible. Normalmente es el 
# host donde se ejecuta "ansible-playbook". "k8s_ca_conf_directory" es utilizado 
# por el rol "kubernetes_ca" para almacenar los certificados. Por lo tanto, se asume 
# que esta variable ya está configurada.
k8s_ctl_ca_conf_directory: "{{ k8s_ca_conf_directory }}"

# Directorio donde se almacena "admin.kubeconfig" 
# (el archivo de credenciales) para el usuario "admin".
# Por defecto este directorio (y su archivo "kubeconfig") 
# se almacenarán en el host especificado en "k8s_ctl_delegate_to". Por defecto 
# este es "127.0.0.1". Así que si ejecutas "ansible-playbook" localmente, 
# por ejemplo, el directorio y archivo se crearán allí.
#
# Por defecto, el valor de esta variable se expandirá al $HOME local del usuario
# más "/k8s/certs". Eso significa que si el directorio $HOME del usuario es, 
# por ejemplo, "/home/da_user", entonces "k8s_admin_conf_dir" tendrá un valor de 
# "/home/da_user/k8s/certs".
k8s_admin_conf_dir: "{{ '~/k8s/configs' | expanduser }}"

# Permisos para el directorio especificado en "k8s_admin_conf_dir".
k8s_admin_conf_dir_perm: "0700"

# Propietario del directorio especificado en "k8s_admin_conf_dir" y para
# "admin.kubeconfig" almacenado en este directorio.
k8s_admin_conf_owner: "root"

# Grupo del directorio especificado en "k8s_admin_conf_dir" y para
# "admin.kubeconfig" almacenado en este directorio.
k8s_admin_conf_group: "root"

# Host al que el usuario "admin" se conecta para administrar el clúster K8s. 
# Esta configuración se escribe en "admin.kubeconfig". Esto permite usar 
# un host/balanceador de carga diferente a los servicios de K8s que podrían usar 
# un balanceador interno, mientras que el usuario "admin" se conecta 
# a un host/balanceador diferente que distribuye el tráfico al "kube-apiserver", por ejemplo.
#
# Además de eso, se aplican los mismos comentarios que para la variable 
# "k8s_ctl_api_endpoint_host".
k8s_admin_api_endpoint_host: "{% set controller_host = groups['k8s_controller'][0] %}{{ hostvars[controller_host]['ansible_' + hostvars[controller_host]['k8s_interface']].ipv4.address }}"

# Igual que arriba, solo que para el puerto.
k8s_admin_api_endpoint_port: "6443"

# Directorio para almacenar los registros de auditoría de "kube-apiserver" (si está habilitado). 
# El propietario y grupo de este directorio serán los especificados en "k8s_run_as_user"
# y "k8s_run_as_group".
k8s_apiserver_audit_log_dir: "{{ k8s_ctl_log_base_dir }}/kube-apiserver"

# El directorio para almacenar la configuración de "kube-apiserver".
k8s_apiserver_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-apiserver"

# Configuración del daemon "kube-apiserver" (puede ser sobrescrita o añadirse 
# configuraciones adicionales definiendo "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"
  "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"

# Este es el contenido de "encryption-config.yaml". Usado por "kube-apiserver"
# (ver opción "encryption-provider-config" en "k8s_apiserver_settings").
# "kube-apiserver" usará esta configuración para encriptar datos antes de almacenarlos
# en etcd (encriptar datos en reposo).
#
# La configuración a continuación es un ejemplo utilizable, pero podría no adaptarse a tus 
# necesidades. Así que por favor revísalo con cuidado. Por ejemplo, podrías querer 
# reemplazar el proveedor "aescbc" con otro diferente como "secretbox". Como puedes ver, 
# esta configuración solo encripta "secretos" en reposo. Pero también es posible 
# encriptar otros recursos de K8s. NOTA: El proveedor "identity" no encripta nada. 
# Eso significa texto plano. En la configuración a continuación se usa como respaldo. 
#
# Si mantienes lo definido por defecto, asegúrate de especificar la variable 
# "k8s_encryption_config_key" en algún lugar (por ejemplo, en "group_vars/all.yml" o 
# incluso mejor usa "ansible-vault" para almacenar este tipo de secretos).
# Esto necesita ser un valor codificado en base64. Para crear tal valor en Linux 
# ejecuta el siguiente comando:
#
# head -c 32 /dev/urandom | base64
#
# Para una descripción detallada, visita:
# https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
#
# Cómo rotar la clave de encriptación o implementar encriptación en reposo en
# un clúster K8s existente, visita:
# 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: {}

# El directorio para almacenar la configuración del administrador del controlador.
k8s_controller_manager_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-controller-manager"

# Configuración del administrador del controlador de K8s (puede ser sobrescrita o añadir 
# configuraciones adicionales definiendo "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"

# El directorio para almacenar la configuración del programador.
k8s_scheduler_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-scheduler"

# Configuración del 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"

# Estas configuraciones de seguridad/sandbox se usarán para
# "kube-apiserver", "kube-scheduler" y "kube-controller-manager"
# unidades systemd. Estas opciones se colocarán en la sección "[Service]". 
# Las configuraciones por defecto deberían ser adecuadas para aumentar 
# la seguridad de los servicios mencionados. Entonces tiene sentido mantenerlas 
# si es posible.
#
# Para más información, consulta:
# https://www.freedesktop.org/software/systemd/man/systemd.service.html#Options
#
# Las opciones a continuación "RestartSec=5" son en su mayoría configuraciones de 
# seguridad/sandbox relacionadas y limitan la exposición del sistema hacia 
# los procesos de la unidad. Puedes añadir o eliminar opciones según sea necesario, por 
# supuesto. Para más información, consulta:
# 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

Los ajustes de kube-apiserver definidos en k8s_apiserver_settings pueden ser sobrescritos definiendo una variable llamada k8s_apiserver_settings_user. También puedes añadir configuraciones adicionales usando esta variable. Por ejemplo, para sobrescribir los valores predeterminados de audit-log-maxage y audit-log-maxbackup y añadir watch-cache, añade los siguientes ajustes a group_vars/k8s.yml:

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

Lo mismo se aplica para el kube-controller-manager añadiendo entradas a la variable k8s_controller_manager_settings_user. Para kube-scheduler, añade entradas a la variable k8s_scheduler_settings_user para sobrescribir/añadir configuraciones en el diccionario k8s_scheduler_settings.

Ejemplo de Playbook

- hosts: k8s_controller
  roles:
    - githubixx.kubernetes_controller

Pruebas

Este rol tiene una pequeña configuración de prueba que se crea usando Molecule, libvirt (vagrant-libvirt) y QEMU/KVM. Consulta mi publicación de blog Pruebas de roles de Ansible con Molecule, libvirt (vagrant-libvirt) y QEMU/KVM sobre cómo configurarlo. La configuración de prueba está aquí.

Después, se puede ejecutar Molecule:

molecule converge

Esto configurará unas pocas máquinas virtuales (VM) con sistemas operativos de Ubuntu compatibles e instala un clúster de Kubernetes, pero sin los nodos de trabajo (así que no hay nodos con kube-proxy y kubelet instalados). También se incluye un pequeño paso de verificación: