CRI-O jako alternatywa dla Dockera jako środowiska wykonawczego dla Kubernetes: konfiguracja na CentOS 8

Cześć! Nazywam się Sergey, jestem DevOps w Surf. Zespół DevOps w Surf ma na celu nie tylko ułatwienie współpracy między specjalistami oraz integrację procesów roboczych, ale także aktywne badania i wdrażanie najnowszych technologii zarówno w własnej infrastrukturze, jak i w infrastrukturze klientów.

Poniżej opowiem nieco o zmianach w stosie technologicznym dla kontenerów, z którymi mieliśmy do czynienia podczas badania dystrybucji CentOS 8 i o tym, czym jest CRI-O oraz jak szybko skonfigurować za jego pomocą środowisko wykonawcze dla Kubernetes.

Dlaczego Docker nie znajduje się w standardowej wersji CentOS 8

Po zainstalowaniu najnowszych dużych wydań RHEL 8 lub CentOS 8 nie można nie zauważyć: w tych dystrybucjach i officialnych repozytoriach brakuje aplikacji Docker, która ideologicznie i funkcjonalnie zastępuje pakiety Podman, Buildah (obecne w dystrybucji domyślnie) oraz CRI-O. Jest to związane z praktyczną realizacją standardów opracowywanych, w tym przez firmę Red Hat w ramach projektu Open Container Initiative (OCI).

Celem OCI, będącego częścią The Linux Foundation, jest stworzenie otwartych standardów przemysłowych dla formatów i środowisk wykonawczych kontenerów, które spełniają kilka zadań. Po pierwsze, nie powinny być sprzeczne z filozofią Linuksa (na przykład w tej części, że każdy program powinien wykonywać jedną funkcję, a Docker jest jakby kombajnem wszystko-w-jednym). Po drugie, powinny eliminować wszystkie istniejące niedoskonałości w oprogramowaniu Docker. Po trzecie, powinny być w pełni zgodne z wymaganiami biznesowymi stawianymi przez wiodące platformy komercyjne do wdrażania, zarządzania i utrzymywania aplikacji konteneryzowanych (na przykład Red Hat OpenShift).

Wady Docker Zalety nowego oprogramowania zostały już dość szczegółowo opisane w w tym artykule, a szczegółowy opis wszystkiego, co oferuje projekt OCI oraz jego charakterystyki architektoniczne można znaleźć w oficjalnej dokumentacji oraz artykułach zarówno od samego Red Hat (całkiem artykuł w blogu Red Hat), jak i w materiałach zewnętrznych. recenzjach.

Ważne jest, co do funkcjonalności ma komponenty oferowanego stosu:

• Podman — bezpośrednia interakcja z kontenerami i repozytorium obrazów przez proces runC;
• Buildah — budowanie i ładowanie obrazów do rejestru;
• CRI-O — środowisko wykonawcze dla systemów orkiestracji kontenerów (na przykład Kubernetes).

Uważam, że dla zrozumienia ogólnej schemy interakcji między komponentami stosu, warto przedstawić tutaj schemat zależności. Kubernetes c runC i niskopoziomowymi bibliotekami przy użyciu CRI-O:

CRI-O i Kubernetes trzymają się tego samego cyklu wydań i wsparcia (macierz zgodności jest bardzo prosta: wersje główne Kubernetes i CRI-O są zgodne), a to, mając na uwadze orientację na pełne i wszechstronne testowanie pracy tego stosu przez deweloperów, daje nam prawo oczekiwać maksymalnej stabilności w użyciu w różnych scenariuszach (tutaj korzysta się również z relatywnej lekkości CRI-O w porównaniu z Docker ze względu na celowe ograniczenie funkcjonalności).

Podczas instalacji Kubernetes sposobem «right way» (zdaniem OCI, oczywiście) przy użyciu CRI-O na CentOS 8 napotkaliśmy na niewielkie trudności, które jednak udało się pomyślnie przezwyciężyć. Chętnie podzielę się z Wami instrukcją instalacji i konfiguracji, która łącznie zajmie najwyżej 10 minut.

Jak wdrożyć Kubernetes na CentOS 8 przy użyciu środowiska CRI-O

Wymagania wstępne: przynajmniej jeden host (2 rdzenie, 4 GB RAM, dysk o pojemności co najmniej 15 GB) z zainstalowanym CentOS 8 (zaleca się profil instalacji „Server”), oraz zapisanym wpisem w lokalnym DNS (w ostateczności można się obejść bez wpisu w /etc/hosts). I nie zapomnijcie wyłączyć swap.

Wszystkie operacje na hoście wykonujemy jako użytkownik root, zachowajcie ostrożność.

1. Na pierwszym kroku skonfigurujemy system operacyjny, zainstalujemy i skonfigurujemy wstępne zależności dla CRI-O.
   • Zaktualizujemy system operacyjny:

     dnf -y update
     

   • Następnie należy skonfigurować zaporę i SELinux. Tutaj wszystko zależy od środowiska, w którym będą działać nasz host lub hosty. Możecie skonfigurować zaporę zgodnie z zaleceniami z dokumentacji, lub, jeśli jesteście w zaufanej sieci lub korzystacie z zewnętrznej zapory, zmienić domyślną strefę na zaufaną lub wyłączyć zaporę:

     firewall-cmd --set-default-zone trusted
     
     firewall-cmd --reload

     Aby wyłączyć zaporę, można użyć następującej komendy:

     systemctl disable --now firewalld
     

     SELinux należy wyłączyć lub przełączyć w tryb «permissive»:

     setenforce 0
     
     sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

   • załadujemy potrzebne moduły jądra i pakiety, skonfigurujemy automatyczne ładowanie modułu „br_netfilter” przy starcie systemu:

     modprobe overlay
     
     modprobe br_netfilter
     
     echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf
     
     dnf -y install iproute-tc
     

   • Aby aktywować przekazywanie pakietów i poprawnie przetwarzać ruch, wprowadzimy odpowiednie ustawienia:

     cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
     net.bridge.bridge-nf-call-iptables = 1
     net.ipv4.ip_forward = 1
     net.bridge.bridge-nf-call-ip6tables = 1
     EOF
     

     Zastosujemy wprowadzone ustawienia:

     sysctl --system

   • Ustawimy wymaganą wersję CRI-O (wersja główna CRI-O, jak już wspomniano, odpowiada wymaganą wersją Kubernetes), ponieważ ostatnia stabilna wersja Kubernetes w tej chwili to 1.18:

     export REQUIRED_VERSION=1.18
     

     Dodamy potrzebne repozytoria:

     dnf -y install 'dnf-command(copr)'
     
     dnf -y copr enable rhcontainerbot/container-selinux
     
     curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_8/devel:kubic:libcontainers:stable.repo
     
     curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION/CentOS_8/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION.repo

   • Teraz możemy zainstalować CRI-O:

     dnf -y install cri-o
     

     Zwróć uwagę na pierwszy aspekt, na który natrafiamy podczas instalacji: konieczne jest edytowanie konfiguracji CRI-O przed uruchomieniem usługi, ponieważ wymagany komponent conmon ma inne miejsce przechowywania niż podane:

     sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf

     Teraz można aktywować i uruchomić demon CRI-O:

     systemctl enable --now crio
     

     Można sprawdzić status demona:

     systemctl status crio
     

2. Instalacja i aktywacja Kubernetes.
   • Dodamy wymagane repozytorium:

     cat < /etc/yum.repos.d/kubernetes.repo
     [kubernetes]
     name=Kubernetes
     baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch
     enabled=1
     gpgcheck=1
     repo_gpgcheck=1
     gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
     exclude=kubelet kubeadm kubectl
     EOF
     

     Teraz możemy zainstalować Kubernetes (wersje 1.18, jak już wcześniej wspomniano):

     dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes

   • Drugi ważny aspekt: ponieważ nie używamy demona Docker, a korzystamy z demona CRI-O, przed uruchomieniem i inicjalizacją Kubernetes konieczne jest wprowadzenie odpowiednich ustawień w pliku konfiguracyjnym /var/lib/kubelet/config.yaml, najpierw tworząc potrzebny katalog:

     mkdir /var/lib/kubelet
     
     cat < /var/lib/kubelet/config.yaml
     apiVersion: kubelet.config.k8s.io/v1beta1
     kind: KubeletConfiguration
     cgroupDriver: systemd
     EOF

   • Trzeci ważny punkt, na który napotykamy podczas instalacji: mimo że wskazaliśmy używany sterownik cgroup, jego konfiguracja za pomocą przekazywanych argumentów kubelet stała się przestarzała (co jest wyraźnie wskazane w dokumentacji), musimy dodać argumenty do pliku, w przeciwnym razie nasz klaster nie zainicjalizuje się:

     cat /dev/null > /etc/sysconfig/kubelet
     
     cat < /etc/sysconfig/kubelet
     KUBELET_EXTRA_ARGS=--container-runtime=remote --cgroup-driver=systemd --container-runtime-endpoint='unix:///var/run/crio/crio.sock'
     EOF

   • Teraz możemy aktywować demona kubelet:

     sudo systemctl enable --now kubelet
     

     Aby skonfigurować control-plane lub worker węzły w kilka minut, możesz skorzystać z tego skryptu.

3. Czas na inicjalizację naszego klastra.
   • Aby zainicjować klaster, wykonaj polecenie:

     kubeadm init --pod-network-cidr=10.244.0.0/16
     

     Zapisz polecenie do dołączenia do klastra 'kubeadm join ...', które zostanie zaproponowane na końcu wyjścia, lub przynajmniej zapisane tokeny.

   • Zainstalujemy wtyczkę (CNI) do obsługi sieci Pod. Zalecam użycie Calico. Być może bardziej popularna Flannel ma problemy z kompatybilnością z nftables, a także Calico to jedyna implementacja CNI rekomendowana i w pełni przetestowana przez projekt Kubernetes:

     kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 

   • Aby połączyć węzeł worker z naszym klastrem, należy go skonfigurować zgodnie z instrukcjami 1 i 2, lub skorzystać z skryptu, a następnie wykonać polecenie z wyjścia 'kubeadm init ...', które zapisaliśmy na poprzednim etapie:

     kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
         --discovery-token-ca-cert-hash $TOKEN_HASH

   • Sprawdźmy, czy nasz klaster został zainicjowany i działa:

     kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
     

   Gotowe! Możesz już wdrażać obciążenia na swoim klastrze K8s.

Co nas czeka dalej

Mam nadzieję, że powyższa instrukcja pomogła zaoszczędzić trochę czasu i nerwów.
Wynik procesów zachodzących w branży często zależy od tego, jak są one odbierane przez główną masę użytkowników końcowych i deweloperów innego oprogramowania w danej niszy. Nie jest jeszcze do końca jasne, do jakiego rezultatu przez kilka lat doprowadzą inicjatywy OCI, ale z chęcią będziemy to obserwować. Swoją opinię możesz przekazać już teraz w komentarzach.

Bądźcie na bieżąco!

Artykuł powstał dzięki następującym źródłom:

• Sekcja o Container runtimes w dokumentacji Kubernetes
• Stronie projektu CRI-O w Internecie
• Artykułom na blogach Red Hat: temu, tego i wielu innym

Źródło: habr.com