githubixx.kubernetes_controller

ansible-role-kubernetes-controller

Ten rol jest używany w Kubernetes the not so hard way with Ansible - Control plane. Instaluję serwer API Kubernetes, harmonogram oraz menedżera kontrolera. Więcej informacji na temat tej roli znajdziesz w Kubernetes the not so hard way with Ansible - Control plane.

Wersje

Każde wydanie jest oznaczane i staram się stosować semantic versioning. Jeśli chcesz używać roli, zalecam korzystanie z najnowszej wersji. Gałąź główna (master) to w zasadzie rozwój, natomiast tagi oznaczają stabilne wersje. Tag 23.0.0+1.28.5 oznacza, że to jest wydanie 23.0.0 tej roli i jest przeznaczone do użycia z wersją Kubernetes 1.28.5 (ale powinno działać także z każdą wersją K8s 1.27.x). Jeśli rola się zmienia, przed + zwiększa się X.Y.Z. Jeśli zmienia się wersja Kubernetes, po + również zwiększa się X.Y.Z. To pozwala oznaczać poprawki błędów i nowe główne wersje roli, podczas gdy jest ona dalej rozwijana dla konkretnej wersji Kubernetes. Jest to szczególnie przydatne przy głównych wydaniach Kubernetes z łamanymi zmianami.

Wymagania

Ta rola wymaga, abyś już stworzył certyfikaty dla serwera API Kubernetes (zobacz Kubernetes the not so hard way with Ansible - Certificate authority (CA)). Rola kopiuje certyfikaty z k8s_ctl_ca_conf_directory (który domyślnie jest tym samym co k8s_ca_conf_directory używany przez rolę githubixx.kubernetes_ca) na docelowy host. Powinieneś również skonfigurować w pełni zintegrowane VPN, na przykład z użyciem WireGuard (zobacz Kubernetes the not so hard way with Ansible - WireGuard) oraz oczywiście klaster etcd (zobacz Kubernetes the not so hard way with Ansible - etcd cluster). WireGuard VPN Mesh nie jest wymagany, ale zwiększa bezpieczeństwo, ponieważ cały ruch między hostami K8s jest domyślnie szyfrowany. Ale tak długo, jak wszystkie włączone hosty mają interfejs, dzięki któremu mogą komunikować się ze sobą, wszystko będzie w porządku.

Obsługiwane systemy operacyjne

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

Zmiany

Historia zmian:

Zobacz pełny CHANGELOG.md

WAŻNE: Jeśli aktualizujesz z wersji < 22.0.0+1.27.8, proszę dokładnie przeczytać CHANGELOG.md! Wersja 22.0.0+1.27.8 miała sporo łamiących zmian!

Ostatnie zmiany:

24.0.0+1.29.4

AKTUALIZACJA
- zaktualizowano k8s_release do 1.29.4

24.0.0+1.29.3

AKTUALIZACJA
- zaktualizowano k8s_release do 1.29.3
- Molecule: użyj alvistack zamiast generic obrazów Vagrant

23.1.2+1.28.8

AKTUALIZACJA
- zaktualizowano k8s_release do 1.28.8

23.1.1+1.28.5

POPRAWA BŁĘDU
- ClusterRoleBinding system:kube-apiserver musi uwzględniać wartość k8s_apiserver_csr_cn jako nazwę użytkownika
- Z powodu wcześniejszej zmiany przenieś files/kube-apiserver-to-kubelet_cluster_role.yaml -> templates/rbac/kube-apiserver-to-kubelet_cluster_role.yaml.j2 i files/kube-apiserver-to-kubelet_cluster_role_binding.yaml -> templates/rbac/kube-apiserver-to-kubelet_cluster_role_binding.yaml.j2, ponieważ oba pliki stały się szablonami Jinja2.

23.1.0+1.28.5

MOLECULE
- Zmiana na Ubuntu 22.04 dla test-assets VM
- Dostosowanie wspólnych nazw dla certyfikatów / zmiana algorytmu na ecdsa i rozmiar algorytmu
INNE ZMIANY
- Naprawiono uprawnienia dla katalogu tymczasowego
- Dostosowano akcję Githuba z powodu zmian w Ansible Galaxy

23.0.0+1.28.5

AKTUALIZACJA
- zaktualizowano k8s_release do 1.28.5
ŁAMIĄCE ZMIANY
- Rozszerzono enable-admission-plugins w k8s_apiserver_settings o: PodSecurity,Priority,StorageObjectInUseProtection,RuntimeClass,CertificateApproval,CertificateSigning,ClusterTrustBundleAttest,CertificateSubjectRestriction,DefaultIngressClass. Są one domyślnie włączone, jeśli ta flaga nie jest określona (zobacz Admission Controllers Reference po więcej informacji).
MOLECULE
- Zmiana adresów IP

Instalacja

Bezpośrednio pobierz z Github (zmień się do katalogu ról Ansible przed klonowaniem. Możesz znaleźć ścieżkę roli używając komendy ansible-config dump | grep DEFAULT_ROLES_PATH): git clone https://github.com/githubixx/ansible-role-kubernetes-controller.git githubixx.kubernetes_controller
Przez komendę ansible-galaxy i pobierz bezpośrednio z Ansible Galaxy: ansible-galaxy install role githubixx.kubernetes_controller
Utwórz plik requirements.yml z następującą treścią (to pobierze rolę z Github) i zainstaluj używając ansible-galaxy role install -r requirements.yml (zmień version, jeśli to konieczne):

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

Zmienne roli (domyślne)

# Główny katalog dla konfiguracji Kubernetes oraz plików certyfikacji dla
# wszystkiego co związane z kontrolą. Po zakończeniu playbooka ten katalog
# zawiera różne podfoldery.
k8s_ctl_conf_dir: "/etc/kubernetes/controller"

# Wszystkie pliki certyfikacji (związane z Private Key Infrastructure) określone w
# "k8s_ctl_certificates" i "k8s_ctl_etcd_certificates" (zobacz "vars/main.yml")
# będą przechowywane tutaj. Właścicielem tego nowego katalogu będzie "root". Grupa
# będzie zgodna z grupą określoną w "k8s_run_as_group". Pliki w tym katalogu
# będą w posiadaniu "root" oraz grupy określonej w "k8s_run_as_group". Uprawnienia
# plików będą "0640".
k8s_ctl_pki_dir: "{{ k8s_ctl_conf_dir }}/pki"

# Katalog do przechowywania binariów Kubernetes (patrz zmienna "k8s_ctl_binaries"
# w "vars/main.yml"). Właścicielem i grupą tego nowego katalogu
# będzie "root" w obu przypadkach. Uprawnienia dla tego katalogu będą "0755".
#
# UWAGA: Domyślny katalog "/usr/local/bin" zazwyczaj już istnieje na każdej
# instalacji systemu Linux z wymienionymi powyżej właścicielem, grupą i uprawnieniami.
# Jeśli Twoje aktualne ustawienia różnią się, rozważ inny katalog. Upewnij się jednak,
# że nowy katalog jest zawarty w wartości zmiennej "$PATH".
k8s_ctl_bin_dir: "/usr/local/bin"

# Wydanie Kubernetes.
k8s_ctl_release: "1.29.4"

# Interfejs, na którym powinny nasłuchiwać usługi Kubernetes. Ponieważ cała komunikacja
# w klastrze powinna korzystać z interfejsu VPN, jego nazwa to zazwyczaj "wg0"
# (WireGuard), "peervpn0" (PeerVPN) lub "tap0".
#
# Interfejs sieciowy, na którym będą nasłuchiwać usługi kontrolne Kubernetes. To:
#
# - kube-apiserver
# - kube-scheduler
# - kube-controller-manager
#
k8s_interface: "eth0"

# Uruchom usługę kontrolną Kubernetes (kube-apiserver, kube-scheduler,
# kube-controller-manager) jako tego użytkownika.
#
# Jeśli chcesz użyć "secure-port" < 1024 dla "kube-apiserver", musisz prawdopodobnie
# uruchomić "kube-apiserver" jako użytkownik "root" (co nie jest zalecane).
#
# Jeśli użytkownik określony w "k8s_run_as_user" nie istnieje, rola
# go utworzy. Tylko jeśli użytkownik już istnieje, rola go nie utworzy,
# ale dostosuje UID/GID oraz powłokę, jeśli jest to określone (zobacz poniższe ustawienia).
# Upewnij się zatem, że UID, GID i powłoka odpowiadają istniejącemu użytkownikowi, jeśli nie
# chcesz, aby ten użytkownik został zmieniony.
#
# Dodatkowo, jeśli "k8s_run_as_user" jest "root", to ta rola w ogóle nie zmieni użytkownika.
k8s_run_as_user: "k8s"

# UID użytkownika określonego w "k8s_run_as_user". Jeśli nie jest określone, będzie
# użyty następny dostępny UID z "/etc/login.defs" (patrz ustawienie "SYS_UID_MAX"
# w tym pliku).
# k8s_run_as_user_uid: "999"

# Powłoka dla użytkownika określonego w "k8s_run_as_user". Dla zwiększonego bezpieczeństwa
# zachowaj domyślną.
k8s_run_as_user_shell: "/bin/false"

# Określa, czy użytkownik określony w "k8s_run_as_user" będzie użytkownikiem systemowym
# (domyślnie) czy nie. Jeśli "true", ustawienie "k8s_run_as_user_home" nie będzie
# brane pod uwagę. Zwykle sensownie jest zachować domyślną wartość, ponieważ nie powinno
# być potrzeby logowania się jako użytkownik, który uruchamia kube-apiserver,
# kube-scheduler lub kube-controller-manager.
k8s_run_as_user_system: true

# Katalog domowy użytkownika określonego w "k8s_run_as_user". Zostanie zignorowany, jeśli
# "k8s_run_as_user_system" jest ustawione na "true". W takim przypadku nie zostanie
# utworzony katalog domowy. Zazwyczaj nie jest potrzebny.
# k8s_run_as_user_home: "/home/k8s"

# Uruchom demon Kubernetes (kube-apiserver, kube-scheduler, kube-controller-manager)
# jako tę grupę.
#
# Uwaga: Jeśli grupa określona w "k8s_run_as_group" nie istnieje, rola
# ją utworzy. Tylko jeśli grupa już istnieje, rola jej nie utworzy,
# ale dostosuje GID, jeśli to konieczne w "k8s_run_as_group_gid" (zobacz poniżej).
k8s_run_as_group: "k8s"

# GID grupy określonej w "k8s_run_as_group". Jeśli nie jest określone, będzie
# użyty następny dostępny GID z "/etc/login.defs" (patrz ustawienie "SYS_GID_MAX"
# w tym pliku).
# k8s_run_as_group_gid: "999"

# Określa, czy grupa określona w "k8s_run_as_group" będzie grupą systemową
# (domyślnie) czy nie.
k8s_run_as_group_system: true

# Domyślnie wszystkie zadania, które muszą komunikować się z klastrem Kubernetes
# są wykonywane na lokalnym hoście (127.0.0.1). Ale jeśli ten host nie ma
# bezpośredniego połączenia z klastrem K8s lub powinny być wykonane gdzie indziej,
# ta zmienna może być odpowiednio zmieniona.
k8s_ctl_delegate_to: "127.0.0.1"

# Adres IP lub nazwa hosta punktu końcowego API Kubernetes. Ta zmienna
# jest używana przez "kube-scheduler" i "kube-controller-manager" do
# połączenia z "kube-apiserver" (serwerem API Kubernetes).
#
# Domyślnie pierwszy host w grupie Ansible "k8s_controller" jest
# tutaj określony. UWAGA: To ustawienie nie jest odporne na błędy! Oznacza to,
# że jeśli pierwszy host w grupie Ansible "k8s_controller" jest niedostępny,
# węzeł roboczy i jego obciążenie nadal będą działać, ale węzeł roboczy nie
# otrzyma żadnych aktualizacji z serwera API Kubernetes.
#
# Jeśli masz loadbalancer, który rozdziela ruch między wszystkimi
# serwerami API Kubernetes, powinien być on tutaj określony (jego adres IP
# lub nazwa DNS). Musisz jednak zapewnić, że adres IP
# lub nazwa DNS, którą chcesz tutaj użyć, jest zawarta w certyfikacie TLS serwera API Kubernetes
# (zobacz zmienną "k8s_apiserver_cert_hosts" z https://github.com/githubixx/ansible-role-kubernetes-ca
# rola). Jeśli nie jest określona, otrzymasz błędy certyfikatu w
# logach wymienionych powyżej usług.
k8s_ctl_api_endpoint_host: "{% set controller_host = groups['k8s_controller'][0] %}{{ hostvars[controller_host]['ansible_' + hostvars[controller_host]['k8s_interface']].ipv4.address }}"

# Jak powyżej, ale dla portu. Określa, na którym porcie
# nasłuchują serwery API Kubernetes. Ponownie, jeśli jest zainstalowany loadbalancer,
# który rozdziela żądania do serwerów API Kubernetes,
# umieść tutaj port loadbalancera.
k8s_ctl_api_endpoint_port: "6443"

# Normalnie "kube-apiserver", "kube-controller-manager" i "kube-scheduler" logują
# się do "journald". Są jednak wyjątki, takie jak dziennik audytów. Dla tego rodzaju
# plików dziennika ten katalog będzie używany jako podstawowa ścieżka. Właścicielem i grupą
# tego katalogu będą ci określeni w "k8s_run_as_user" i "k8s_run_as_group",
# ponieważ te usługi działają jako ten użytkownik i potrzebują uprawnień do tworzenia plików dziennika
# w tym katalogu.
k8s_ctl_log_base_dir: "/var/log/kubernetes"

# Uprawnienia dla katalogu określonego w "k8s_ctl_log_base_dir"
k8s_ctl_log_base_dir_mode: "0770"

# Port, z którym komponenty kontrolne będą łączyć się z klastrem etcd
k8s_ctl_etcd_client_port: "2379"

# Interfejs, na którym nasłuchuje klaster etcd
k8s_ctl_etcd_interface: "eth0"

# Miejsce, w którym przechowywane są certyfikaty Kubernetes.
# Certyfikaty te zostały wygenerowane przez rolę "kubernetes_ca", jeśli
# nie użyłeś innej metody, aby je wygenerować. Tak więc ten
# katalog znajduje się na hoście kontrolera Ansible. Zwykle to
# host, na którym wykonywany jest "ansible-playbook". "k8s_ca_conf_directory" jest używana
# przez rolę "kubernetes_ca" do przechowywania certyfikatów. Zatem
# przyjmuje się, że ta zmienna jest już ustawiona.
k8s_ctl_ca_conf_directory: "{{ k8s_ca_conf_directory }}"

# Katalog, w którym przechowywany jest "admin.kubeconfig" (plik uwierzytelniający)
# dla użytkownika "admin". Domyślnie ten katalog (i plik "kubeconfig") będzie
# przechowywany na hoście określonym w "k8s_ctl_delegate_to". Domyślnie jest to "127.0.0.1".
# Tak więc, jeśli uruchomisz "ansible-playbook" lokalnie, np. katalog
# i plik zostaną utworzone tam.
#
# Domyślnie wartość tej zmiennej rozwinie się do lokalnego katalogu $HOME
# użytkownika plus "/k8s/certs". To oznacza, że jeśli katalog $HOME użytkownika to np.
# "/home/da_user", to "k8s_admin_conf_dir" będzie miało wartość
# "/home/da_user/k8s/certs".
k8s_admin_conf_dir: "{{ '~/k8s/configs' | expanduser }}"

# Uprawnienia dla katalogu określonego w "k8s_admin_conf_dir"
k8s_admin_conf_dir_perm: "0700"

# Właściciel katalogu określonego w "k8s_admin_conf_dir" i dla
# "admin.kubeconfig" przechowywanego w tym katalogu.
k8s_admin_conf_owner: "root"

# Grupa katalogu określonego w "k8s_admin_conf_dir" i dla
# "admin.kubeconfig" przechowywanego w tym katalogu.
k8s_admin_conf_group: "root"

# Host, z którego użytkownik "admin" łączy się, aby zarządzać klastrem K8s. 
# To ustawienie jest zapisywane w "admin.kubeconfig". Umożliwia
# używanie innego hosta/loadbalancera niż usługi K8s, które mogą wykorzystywać wewnętrzny
# loadbalancer, podczas gdy użytkownik "admin" łączy się z innym hostem/loadbalancerem,
# który rozdziela ruch do "kube-apiserver", na przykład.
#
# Oprócz tego zasadniczo mają zastosowanie te same uwagi, co do zmiennej "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 }}"

# Jak powyżej, ale dla portu.
k8s_admin_api_endpoint_port: "6443"

# Katalog do przechowywania dzienników audytów "kube-apiserver" (jeśli są włączone). Właścicielem i
# grupą tego katalogu będą ci określeni w "k8s_run_as_user"
# i "k8s_run_as_group".
k8s_apiserver_audit_log_dir: "{{ k8s_ctl_log_base_dir }}/kube-apiserver"

# Katalog do przechowywania konfiguracji "kube-apiserver".
k8s_apiserver_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-apiserver"

# Ustawienia demona "kube-apiserver" (mogą być nadpisane lub dodatkowe
# dodane przez zdefiniowanie "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" domyślnie to:
                                                                       # "Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP"
                                                                       # Musi być zmienione, aby poprawnie działały "kubectl logs" i "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"

# To jest zawartość "encryption-config.yaml". Używane przez "kube-apiserver"
# (zobacz opcję "encryption-provider-config" w "k8s_apiserver_settings").
# "kube-apiserver" użyje tej konfiguracji do szyfrowania danych przed ich
# zapisaniem w etcd (szyfrowanie danych w spoczynku).
#
# Poniższa konfiguracja to przykład, ale może nie odpowiadać Twoim potrzebom.
# Proszę dokładnie to przejrzeć! Na przykład możesz chcieć zastąpić 
# dostawcę "aescbc" innym, na przykład "secretbox". Jak widać, ta konfiguracja
# szyfruje tylko "secrets" w spoczynku. Możliwe jest również szyfrowanie
# innych zasobów K8s. UWAGA: dostawca "identity" nie szyfruje nic! Oznacza to
# czysty tekst. W poniższej konfiguracji jest używany jako zapasowy.
#
# Jeśli zachowasz domyślnie zdefiniowane poniżej, upewnij się, że gdzieś 
# określiłeś zmienną "k8s_encryption_config_key" (np. w "group_vars/all.yml" lub
# jeszcze lepiej, użyj "ansible-vault", aby przechowywać takie sekrety).
# Musi to być zakodowana w base64 wartość. Aby utworzyć taką wartość na Linuxie,
# uruchom następującą komendę:
#
# head -c 32 /dev/urandom | base64
#
# Po szczegółowy opis odwiedź:
# https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
#
# Jak obrócić klucz szyfrujący lub wdrożyć szyfrowanie w spoczynku w
# istniejącym klastrze K8s odwiedź:
# 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: {}

# Katalog do przechowywania konfiguracji menedżera kontrolera.
k8s_controller_manager_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-controller-manager"

# Ustawienia menedżera kontrolera K8s (mogą być nadpisane lub dodatkowe
# dodane przez zdefiniowanie "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"

# Katalog do przechowywania konfiguracji harmonogramu.
k8s_scheduler_conf_dir: "{{ k8s_ctl_conf_dir }}/kube-scheduler"

# Ustawienia 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"

# Te powiązane z bezpieczeństwem ustawienia sandbox będą używane dla
# "kube-apiserver", "kube-scheduler" i "kube-controller-manager"
# jednostek systemd. Te opcje zostaną umieszczone w sekcji "[Service]".
# Domyślne ustawienia powinny być wystarczające dla zwiększenia bezpieczeństwa
# wspomnianych usług. Dlatego sensownie jest je zachować, jeśli to możliwe.
#
# Po więcej informacji zobacz:
# https://www.freedesktop.org/software/systemd/man/systemd.service.html#Options
#
# Opcje poniżej "RestartSec=5" to głównie ustawienia związane z bezpieczeństwem
# i ograniczają eksponowanie systemu na procesy jednostek. Możesz dodawać
# lub usuwać opcje według potrzeb. Więcej informacji zobacz:
# 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
  - 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

Ustawienia kube-apiservera określone w k8s_apiserver_settings mogą być nadpisane poprzez zdefiniowanie zmiennej o nazwie k8s_apiserver_settings_user. Możesz też dodać dodatkowe ustawienia przy użyciu tej zmiennej. Na przykład, aby nadpisać domyślne wartości audit-log-maxage i audit-log-maxbackup oraz dodać watch-cache, dodaj następujące ustawienia do group_vars/k8s.yml:

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

To samo dotyczy menedżera kontrolera kube-controller-manager, dodając wpisy do zmiennej k8s_controller_manager_settings_user. Dla kube-scheduler dodaj wpisy do zmiennej k8s_scheduler_settings_user, aby nadpisać/dodać ustawienia w słowniku k8s_scheduler_settings.

Przykładowy playbook

- hosts: k8s_controller
  roles:
    - githubixx.kubernetes_controller

Testowanie

Ta rola ma małą konfigurację testową, która jest tworzona przy użyciu Molecule, libvirt (vagrant-libvirt) i QEMU/KVM. Zobacz mój post na blogu Testing Ansible roles with Molecule, libvirt (vagrant-libvirt) and QEMU/KVM, aby dowiedzieć się, jak to skonfigurować. Konfiguracja testowa znajduje się tutaj.

Następnie można wykonać Molecule:

molecule converge

To skonfiguruje kilka maszyn wirtualnych (VM) z obsługiwanym systemem Ubuntu i zainstaluje klaster Kubernetes, ale bez węzłów roboczych (czyli węzły bez zainstalowanego kube-proxy i kubelet). Zawiera również mały krok weryfikacji: