cilium-kubernetes

Ta rola Ansible instaluje sieć Cilium na klastrze Kubernetes. W tle wykorzystuje oficjalny Helm chart. Obecnie wspierane są procedury takie jak instalacja, aktualizacja i usuwanie wdrożenia Cilium.

Wersje

Każde wydanie jest oznaczane, a ja staram się trzymać semantycznego wersjonowania. Jeśli chcesz użyć tej roli, polecam sprawdzić najnowsze oznaczenie. Gałąź master to w zasadzie rozwój, a oznaczenia wskazują na stabilne wydania. Oznaczenie 13.0.0+1.15.3 oznacza, że to jest wydanie 13.0.0 tej roli i zawiera wersję chartu Cilium 1.15.3. Jeśli rola sama się zmienia, wartość przed + wzrośnie. Jeśli zmieni się wersja chartu Cilium, wartość po + również wzrośnie. To pozwala na oznaczanie poprawek błędów i nowych głównych wersji roli podczas jej rozwoju dla konkretnego wydania Cilium.

Wymagania

Na hoście, na którym wykonuje się ansible-playbook, musisz mieć zainstalowany binarny plik Helm 3 lub na hoście, na który przekazałeś playbooki (np. używając zmiennej cilium_delegate_to). Możesz:

• użyć ulubionego menedżera pakietów, jeśli Twoja dystrybucja zawiera helm w swoim repozytorium (np. dla Archlinux użyj sudo pacman -S helm)
• lub użyć jednej z ról Ansible Helm (np. helm - która również zostanie zainstalowana, jeśli użyjesz ansible-galaxy role install -vr requirements.yml)
• lub bezpośrednio pobrać binarny plik z wydania Helm i umieścić go w katalogu /usr/local/bin/.

Potrzebujesz również prawidłowo skonfigurowanego KUBECONFIG (domyślnie znajduje się w ${HOME}/.kube/config). Zwykle, jeśli kubectl działa z Twoim klastrem, to powinno być w porządku.

Dodatkowo, musisz zainstalować kolekcję Ansible kubernetes.core. Można to zrobić, używając pliku collections.yml dołączonego do tej roli: ansible-galaxy install -r collections.yml.

I oczywiście potrzebujesz klastra Kubernetes ;-)

Instalacja

• Bezpośrednio pobierz z GitHub (zmień katalog na rolę 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-cilium-kubernetes.git githubixx.cilium_kubernetes

• Poprzez polecenie ansible-galaxy i pobierz bezpośrednio z Ansible Galaxy: ansible-galaxy install role githubixx.cilium_kubernetes

• Utwórz plik requirements.yml z następującą zawartością (pobierze rolę z GitHub) i zainstaluj za pomocą ansible-galaxy role install -r requirements.yml (zmień version, jeśli to konieczne):

---
roles:
  - name: githubixx.cilium_kubernetes
    src: https://github.com/githubixx/ansible-role-cilium-kubernetes.git
    version: 13.0.0+1.15.3

Zmiany

Historia zmian:

Zobacz pełny CHANGELOG.md

Ostatnie zmiany:

13.0.0+1.15.3

Zmiany breaking

• zmiany w templates/cilium_values_default.yml.j2:
  • dodano kubeProxyReplacement, nodePort i socketLB (to jest potrzebne, ponieważ BPF masquerade wymaga NodePort)

Aktualizacja

• aktualizacja do Cilium v1.15.3

Molecule

• zastąpienie boxów Vagrant generic/ubuntu2204 boxami alvistack/ubuntu-22.04

12.0.0+1.15.0

• aktualizacja do Cilium v1.15.0
• refaktoryzacja konfiguracji Molecule
• wprowadzenie zmiennej cilium_chart_values_directory

Zmienne roli

# Wersja chartu Helm
cilium_chart_version: "1.15.3"

# Nazwa chartu Helm
cilium_chart_name: "cilium"

# URL chartu Helm
cilium_chart_url: "https://helm.cilium.io/"

# Namespace Kubernetes, gdzie zasoby Cilium powinny być zainstalowane
cilium_namespace: "cilium"

# Katalog zawierający plik wartości chartu Helm. Ansible spróbuje znaleźć
# plik o nazwie "values.yml.j2" lub "values.yaml.j2" w określonym katalogu
# (".j2", ponieważ można tam używać typowych elementów szablonów Jinja2).
# Jeśli nie zostanie znaleziony, użyty zostanie domyślny "templates/cilium_values_default.yml.j2"
# (który można zresztą użyć jako szablon). Zawartość tego pliku
# zostanie przekazana do polecenia "helm install/template" jako plik wartości.
cilium_chart_values_directory: "/tmp/cilium/helm"

# ustawienia etcd. Jeśli zmienna "cilium_etcd_enabled" jest zdefiniowana i ustawiona na "true",
# ustawienia Cilium etcd są generowane i wdrażane. W przeciwnym razie wszystkie poniższe
# ustawienia "cilium_etcd_*" są ignorowane.
cilium_etcd_enabled: "true"

# Interfejs, na którym nasłuchują demony etcd. Jeśli demony etcd są powiązane z
# interfejsem WireGuard, to ustawienie powinno być "wg0" (domyślnie) np.
# Możesz również użyć zmiennej takiej jak "{{ etcd_interface }}", jeśli używałeś
# mojej roli etcd (https://github.com/githubixx/ansible-role-etcd)
cilium_etcd_interface: "eth0"

# Port, na którym nasłuchują demony etcd
cilium_etcd_client_port: 2379

# Grupa hostów etcd w pliku "hosts" Ansible. Ta wartość jest używana w
# szablonie "templates/cilium_values_default.yml.j2" do określenia adresów IP
# hostów, na których nasłuchują demony etcd.
cilium_etcd_nodes_group: "k8s_etcd"

# Jeśli ta zmienna jest zdefiniowana, zostanie zainstalowana tajemnica Kubernetes, która
# zawiera pliki certyfikatów określone w zmiennych "cilium_etcd_cafile",
# "cilium_etcd_certfile" i "cilium_etcd_keyfile"
#
# To powoduje, że nawiązywane jest bezpieczne połączenie (https) z etcd.
# Oczywiście wymaga to, aby etcd był skonfigurowany do używania SSL/TLS.
#
# Jeśli ta wartość nie jest zdefiniowana (np. skomentowana), pozostałe
# ustawienia "cilium_etcd_*" poniżej są ignorowane, a połączenie z etcd
# nawiązywane jest w sposób niezabezpieczony przez "http".
cilium_etcd_secrets_name: "cilium-etcd-secrets"

# Gdzie znaleźć pliki certyfikatów określone poniżej. Jeśli użyłeś mojej
# roli Certyfikatu w Kubernetes (https://github.com/githubixx/ansible-role-kubernetes-ca)
# możesz już mieć zdefiniowaną zmienną "k8s_ca_conf_directory", którą możesz
# ponownie wykorzystać tutaj. Ta rola również generuje pliki certyfikatów, które można
# wykorzystać w poniższych zmiennych.
# Domyślnie będzie to "$HOME/k8s/certs" bieżącego użytkownika, który uruchamia
# komendę "ansible-playbook".
cilium_etcd_cert_directory: "{{ '~/k8s/certs' | expanduser }}"

# plik autoryzacji certyfikatu etcd (plik zostanie pobrany w "cilium_etcd_cert_directory")
cilium_etcd_cafile: "ca-etcd.pem"

# plik certyfikatu etcd (plik zostanie pobrany w "cilium_etcd_cert_directory")
# Upewnij się, że certyfikat zawiera adresy IP w "Subject
# Alternative Name" (SAN) interfejsów, na których nasłuchują demony etcd
# (to są adresy IP interfejsów zdefiniowanych w "cilium_etcd_interface").
# To już jest obsługiwane przez moją rolę Certyfikatu w Kubernetes
# (https://github.com/githubixx/ansible-role-kubernetes-ca), jeśli z niej korzystałeś.
cilium_etcd_certfile: "cert-cilium.pem"

# plik klucza certyfikatu etcd (plik zostanie pobrany w "cilium_etcd_cert_directory")
cilium_etcd_keyfile: "cert-cilium-key.pem"

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

# Pokazuje komendę "helm", która została wykonana, jeśli zadanie używa Helm do
# instalacji, aktualizacji/modernizacji lub usuwania takiego zasobu.
cilium_helm_show_commands: false

# Bez zdefiniowanej zmiennej "cilium_action", ta rola tylko wygeneruje plik
# ze wszystkimi zasobami, które zostaną zainstalowane lub zaktualizowane. Wygenerowany
# plik z zasobami zostanie nazwany "template.yml" i umieszczony w
# katalogu określonym poniżej.
cilium_template_output_directory: "{{ '~/cilium/template' | expanduser }}"

Użycie

Pierwszą rzeczą do zrobienia jest sprawdzenie templates/cilium_values_default.yml.j2. Ten plik zawiera wartości/ustawienia dla chartu Helm Cilium, które są inne niż domyślne, które znajdują się tutaj. Domyślne wartości tej roli Ansible używają klastra etcd z włączonym TLS. Jeśli masz własny hostowany/bare metal klaster Kubernetes, szanse są wysokie, że działa już klaster etcd dla serwera API Kubernetes, co jest moim przypadkiem. Używam mojej roli Ansible etcd do zainstalowania takiego klastra etcd oraz mojej roli Kubernetes Certificate Authority do generacji certyfikatów. Więc jeśli skorzystałeś z moich ról, możesz użyć tej roli Cilium praktycznie jak jest.

Szablon templates/cilium_values_default.yml.j2 zawiera również kilka klauzul if, aby użyć klastra etcd, który nie jest włączony TLS. Zobacz defaults/main.yml, aby sprawdzić, które wartości mogą być zmieniane. Możesz też wprowadzić własne zmienne. Aby użyć własnych wartości, po prostu stwórz plik o nazwie values.yml.j2 lub values.yaml.j2 i umieść go w katalogu określonym w cilium_chart_values_directory. Wówczas ta rola wykorzysta ten plik do generacji wartości Helm.

Po umieszczeniu pliku wartości i sprawdzeniu wartości w defaults/main.yml, rolę można zainstalować. Większość zadań roli jest domyślnie wykonywana lokalnie, ponieważ wiele zadań musi komunikować się z serwerem API Kubernetes lub wykonywać polecenia Helm. Ale możesz oddelegować tego typu zadania do innego hosta, używając zmiennej cilium_delegate_to (patrz powyżej). Upewnij się tylko, że host, który delegujesz, ma połączenie z serwerem API Kubernetes, a użytkownik ma ważny plik KUBECONFIG.

Domyślną akcją jest jedynie wygenerowanie pliku YAML z zasobami Kubernetes po zastąpieniu wszystkich zmiennych Jinja2 i tym podobnych. W sekcji Przykładowy playbook poniżej znajduje się Przykład 2 (przypisz tag do roli). Rola githubixx.cilium_kubernetes ma przypisany tag role-cilium-kubernetes. Zakładając, że wartości dla chartu Helm powinny być wygenerowane (w tym przypadku nic nie będzie zainstalowane), a playbook nazywa się k8s.yml, wykonaj następujące polecenie:

ansible-playbook --tags=role-cilium-kubernetes k8s.yml

Aby wygenerować szablon w innym katalogu, użyj zmiennej cilium_template_output_directory, np.:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_template_output_directory="/tmp/cilium" k8s.yml

Jeśli chcesz zobaczyć polecenia helm i parametry, które zostały wykonane w logach, możesz także określić --extra-vars cilium_helm_show_commands=true.

Jednym z ostatnich zadań jest TASK [githubixx.cilium_kubernetes : Zapisz szablony do pliku]. To generuje szablon z zasobami, które zostaną utworzone w katalogu określonym w cilium_template_output_directory. Plik będzie nazwany template.yml. Katalog/plik zostanie umieszczony na Twojej lokalnej maszynie, aby móc go sprawdzić.

Jeśli wygenerowany wynik zawiera wszystko, czego potrzebujesz, rolę można zainstalować, co ostatecznie wdraża Cilium:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=install k8s.yml

Aby sprawdzić, czy wszystko zostało wdrożone, użyj zwykłych poleceń kubectl, takich jak kubectl -n <cilium_namespace> get pods -o wide.

Ponieważ Cilium wydaje aktualizacje/co jakiś czas, rola ta może również dokonywać aktualizacji. Rola zasadniczo wykonuje to, co opisano w przewodniku aktualizacji Cilium. Oznacza to, że sprawdzenie wstępne Cilium zostanie zainstalowane, a kilka kontrolnych sprawdzeń zostanie wykonanych przed rzeczywistą aktualizacją. Zobacz tasks/upgrade.yml, aby zobaczyć, co się dzieje przed, w trakcie i po aktualizacji. Oczywiście powinieneś zapoznać się z przewodnikiem aktualizacji Cilium w ogóle, aby sprawdzić główne zmiany i tym podobne przed aktualizacją. Upewnij się również, że sprawdziłeś Uwagi dotyczące aktualizacji!

Jeśli aktualizacja się nie powiodła, można zasadniczo zainicjować powrót do poprzedniej wersji, zmieniając jedynie zmienną cilium_chart_version. Ale zdecydowanie powinieneś przeczytać przewodnik dotyczący powrotu Cilium. Przełączanie między mniejszymi wersjami zazwyczaj nie stanowi problemu, ale przełączanie z jednej głównej wersji do poprzedniej może być problematyczne.

Sprawdź także templates/cilium_values_default_pre_flight_check.yml.j2. Jeśli musisz dostosować wartości do sprawdzenia pre-flight, możesz zmienić ten plik lub stworzyć plik templates/cilium_values_user_pre_flight_check.yml.j2 ze swoimi wartościami.

Przed dokonaniem aktualizacji zasadniczo musisz jedynie zmienić zmienną cilium_chart_version, np. z 1.13.4 na 1.14.5, aby zaktualizować z 1.13.4 na 1.14.5. Aby przeprowadzić aktualizację, uruchom

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=upgrade k8s.yml

Jak już wspomniano, rola ta ma już wbudowane niektóre kontrole, aby upewnić się, że aktualizacja przebiegnie pomyślnie, ale powinieneś ponownie sprawdzić za pomocą kubectl, czy wszystko działa zgodnie z oczekiwaniami po aktualizacji.

I w końcu, jeśli chcesz pozbyć się Cilium, możesz usunąć wszystkie zasoby:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=delete k8s.yml

Jeśli nie masz skonfigurowanych żadnych wtyczek CNI, spowoduje to, że proces kubelet na węzłach roboczych Kubernetes będzie co jakiś czas generował błędy CNI, ponieważ nie ma już nic związanego z CNI, a oczywiście łączność między podami na różnych hostach zniknie, razem z wszelkimi politykami sieciowymi i innymi tego typu.

Przykładowy playbook

Przykład 1 (bez tagu roli):

- hosts: k8s_worker
  roles:
    - githubixx.cilium_kubernetes

Przykład 2 (przypisz tag do roli):

-
  hosts: k8s_worker
  roles:
    -
      role: githubixx.cilium_kubernetes
      tags: role-cilium-kubernetes

Testowanie

Ta rola ma mały zestaw testowy, który jest tworzony przy użyciu Molecule, libvirt (vagrant-libvirt) i QEMU/KVM. Zobacz proszę mój post na blogu Testowanie ról Ansible przy użyciu Molecule, libvirt (vagrant-libvirt) i QEMU/KVM, aby dowiedzieć się, jak skonfigurować. Konfiguracja testowa znajduje się tutaj.

Po tym można uruchomić moleculę. Następujące polecenie wykona podstawową konfigurację i stworzy szablon zasobów (domyślna akcja, patrz powyżej), które będą tworzone:

molecule converge

Instalacja Cilium i wymaganych zasobów. To skonfiguruje kilka maszyn wirtualnych (VM) i zainstaluje klaster Kubernetes. Ta konfiguracja będzie używana do instalacji Cilium za pomocą tej roli.

molecule converge -- --extra-vars cilium_action=install

Następujące polecenie może być użyte do zainstalowania CoreDNS dla rzeczy związanych z DNS w Kubernetes i można przetransformować węzły kontrolne, aby uruchamiały tylko podów Cilium:

molecule converge -- --extra-vars cilium_setup_networking=install

Aby zaktualizować Cilium lub zmienić parametry:

molecule converge -- --extra-vars cilium_action=upgrade

Usuwanie Cilium i jego zasobów:

molecule converge -- --extra-vars cilium_action=delete

Aby przeprowadzić kilka testów, użyj (opcjonalnie dodaj -v, aby uzyskać więcej wyjścia):

molecule verify

Aby przeprowadzić porządki, uruchom

molecule destroy

Licencja

GNU GENERAL PUBLIC LICENSE Wersja 3

Informacje o autorze

http://www.tauceti.blog