CRI-O mint Docker helyett Kubernetes futtatókörnyezeteként: beállítás CentOS 8-on

Helló! A nevem Szergej, DevOps vagyok a Surf-nél. A Surf DevOps osztályának nemcsak a szakemberek közötti együttműködés javítása és a munkafolyamatok integrálása a feladata, hanem aktuális technológiák aktív kutatása és bevezetése saját infrastruktúrájukba, valamint az ügyfél infrastruktúrájába is.

Az alábbiakban kicsit mesélek a konténer technológiai stackjében bekövetkezett változásokról, amikkel a disztribúció tanulmányozása során találkoztunk. CentOS 8 és arról, hogy mi az, CRI-O és hogyan lehet gyorsan beállítani a segítségével egy futtatókörnyezetet Kubernetes.

CRI-O mint Docker helyett Kubernetes futtatókörnyezeteként: beállítás CentOS 8-on

Miért hiányzik a Docker a CentOS 8 alapértelmezett csomagjából?

A legutóbbi főbb kiadások telepítése után RHEL 8 vagy CentOS 8 nem lehet figyelmen kívül hagyni: ezekben a disztribúciókban és hivatalos tárolókban hiányzik az alkalmazás, Dockeramelyek ideológiailag és funkcionálisan helyettesítik a Podman, Buildah (alapértelmezett csomagként szereplő disztribúciókban) és CRI-O. Ez összefügg a szabványok gyakorlati megvalósításával, amelyeket többek között a Red Hat a Nyílt Konténer Kezdeményezés (OCI) keretében dolgoz ki.

Az OCI célja, amely a Linux Alapítvány része, hogy nyílt ipari szabványokat hozzon létre a konténerek formátumaihoz és futtatókörnyezetéhez, amelyek egyszerre több feladatot is megoldanak. Először is, nem ellentmondanak a Linux filozófiájának (például abban a részében, hogy minden programnak egyetlen feladatot kell végrehajtania, míg Docker olyan, mint egy minden tudó kombináció). Másodsorban, képesek legyenek megszüntetni a szoftverben lévő összes meglévő hiányosságot. DockerHarmadsorban, teljes mértékben összhangban legyenek a vezető kereskedelmi platformok által támasztott üzleti követelményekkel a konténerizált alkalmazások telepítése, kezelése és karbantartása terén (például a Red Hat OpenShift).

Hátrányok Docker és az új szoftver előnyei már elég részletesen szerepeltek a cikkben, míg a projekt keretében kínált szoftver stackről és az architekturális jellemzőiről az hivatalos dokumentációban és cikkekben olvashatunk, mind a Red Hat-től (nem rossz cikk a Red Hat blogon), mind harmadik fél forrásaiból. említik az olyan problémákat a Moment.js-el kapcsolatban, mint az alacsony teljesítmény, az API bonyolultsága, a „.

Fontos megjegyezni, hogy milyen funkcionalitással rendelkeznek a javasolt stack komponensei:

  • Podman — közvetlen interakció a konténerekkel és a képmag tárolókkal a runC folyamaton keresztül;
  • Buildah — képek összegyűjtése és regiszterbe töltése;
  • CRI-O — végrehajtási környezet a konténer-orchestration rendszerek számára (például Kubernetes).

Azt hiszem, hogy a komponensk közötti interakció általános sémájának megértéséhez hasznos lenne itt bemutatni a kapcsolatok ábráját. Kubernetes c runC és alacsony szintű könyvtárakkal való használatával CRI-O:

CRI-O mint Docker helyett Kubernetes futtatókörnyezeteként: beállítás CentOS 8-on

CRI-O és Kubernetes ugyanazon kiadási és támogatási ciklusra épülnek (a kompatibilitási mátrix nagyon egyszerű: a fő verziók Kubernetes és CRI-O egyeznek), ami figyelembe véve a fejlesztők által a stack teljes, alapos tesztelése iránti elkötelezettséget, jogot ad arra, hogy a lehető legnagyobb stabilitást várjuk el a bármely felhasználási forgatókönyv mellett (itt a viszonylagos könnyedség is segít CRI-O összehasonlítva Docker a funkciók célzott korlátozása miatt).

Telepítéskor Kubernetes „helyes módon” (az OCI szerint persze) való felhasználásával CRI-O Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata CentOS 8 találkoztunk néhány kisebb nehézséggel, amelyeket azonban sikeresen leküzdöttünk. Örömmel osztom meg Önökkel a telepítési és konfigurálási útmutatót, amely összesen maximum 10 percet vesz igénybe.

Hogyan telepítsük a Kubernetest CentOS 8-ra a CRI-O környezet használatával

Előlegfeltételek: legalább egy gazdagép (2 mag, 4 GB RAM, legalább 15 GB tároló) telepített CentOS 8 (ajánlott a „Server” telepítési profil), valamint helyi DNS bejegyzés (vészhelyzetben elegendő lehet a /etc/hosts fájlba való bejegyzés). Ne felejtsd el letiltani a swapot..

Minden műveletet a gazdagépen root felhasználóként hajtunk végre, légy óvatos.

  1. Az első lépésben beállítjuk az operációs rendszert, telepítjük és konfiguráljuk a CRI-O előfeltételeit.
    • Frissítjük az operációs rendszert:
      dnf -y update
      

    • Ezután be kell állítanunk a tűzfalat és a SELinuxot. Mindez attól függ, hogy a gazdagép vagy gazdagépek milyen környezetben fognak üzemelni. Lehetőséged van a tűzfal beállításhoz követni dokumentáció, vagy ha megbízható hálózaton tartózkodsz vagy külső tűzfalat használsz, módosítani az alapértelmezett zónát megbízhatóra vagy letiltani a tűzfalat:
      firewall-cmd --set-default-zone trusted
      
      firewall-cmd --reload

      A tűzfal letiltásához az alábbi parancsot használhatod:

      systemctl disable --now firewalld
      

      A SELinux-t le kell tiltani, vagy „permissive” módba kell állítani:

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

    • betöltjük a szükséges kernel modulokat és csomagokat, beállítjuk a „br_netfilter” modul automatikus betöltését a rendszerindításkor:
      modprobe overlay
      
      modprobe br_netfilter
      
      echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf
      
      dnf -y install iproute-tc
      

    • A csomagok irányításának aktiválásához és a forgalom megfelelő kezeléséhez elvégezzük a szükséges beállításokat:
      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
      

      Alkalmazzuk a végrehajtott beállításokat:

      sysctl --system

    • Beállítjuk a szükséges verziót CRI-O (főverzió CRI-O, ahogy korábban említettük, megegyezik a szükséges verzióval Kubernetes), mivel a legújabb stabil verzió Kubernetes jelenleg 1.18:
      export REQUIRED_VERSION=1.18
      

      Hozzáadjuk a szükséges tárolókat:

      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

    • Most telepíthetjük CRI-O:
      dnf -y install cri-o
      

      Figyelembe kell venni az első szempontot, amellyel a telepítés során találkozunk: a szolgáltatás indítása előtt szükséges a konfiguráció szerkesztése CRI-O , mivel a szükséges összetevő, a conmon eltér a megadott elérhetőségtől:

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

      Most aktiválhatjuk és elindíthatjuk a daemont CRI-O:

      systemctl enable --now crio
      

      Ellenőrizhetjük a daemon állapotát:

      systemctl status crio
      

  2. Telepítés és aktiválás Kubernetes.
    • Hozzáadjuk a szükséges tárolót:
      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
      

      Most telepíthetjük Kubernetes (1.18 verzió, amint az korábban említve volt):

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

    • A második fontos szempont: mivel nem használunk daemont Docker, hanem daemont használunk CRI-O, az indítás és inicializálás előtt szükséges a megfelelő beállításokat elvégezni a /var/lib/kubelet/config.yaml konfigurációs fájlban, először létrehozva a megfelelő könyvtárat: Kubernetes mkdir /var/lib/kubeletcat < /var/lib/kubelet/config.yaml apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cgroupDriver: systemd EOF
      A harmadik fontos szempont, amellyel a telepítés során találkozunk: annak ellenére, hogy megadtuk a használt meghajtót

    • cgroup , és annak beállítása az átadott argumentumokon keresztülkubelet kubelet Elavult (amire közvetlenül utal a dokumentáció), hozzá kell adnunk a fájlhoz argumentumokat, különben a klaszterünk nem inicializálódik:
      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

    • Most aktiválhatjuk a démon. kubelet:
      sudo systemctl enable --now kubelet
      

      A beállításhoz vezérlőlap vagy munkavállaló csomópontokat néhány perc alatt, használhatja ezt a scriptet.

  3. Itt az idő inicializálni a klaszterünket.
    • A klaszter inicializálásához futtassa a következő parancsot:
      kubeadm init --pod-network-cidr=10.244.0.0/16
      

      Kérjük, jegyezze fel a klaszterhez való csatlakozás parancsát „kubeadm join …”, amelyet a kimenet végén ajánlanak fel, vagy legalábbis a megadott tokeneket.

    • Telepítjük a Plugint (CNI) a Pod hálózat működéséhez. Javaslom, hogy használja Calico. Talán a népszerűbb Flannel problémái vannak a kompatibilitással nftables, és a Calico — az egyetlen CNI megvalósítás, amelyet a Kubernetes:
      kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 

    • A munkavállaló csomópontot a klaszterhez kell beállítani az 1. és 2. lépés szerint, vagy használhatja a scriptet, majd futtassa a kimenetből a „kubeadm init …” parancsot, amelyet az előző lépésben jegyeztünk fel:
      kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
          --discovery-token-ca-cert-hash $TOKEN_HASH

    • Ellenőrizzük, hogy a klaszterünk inicializálva és működik-e:
      kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
      

    Kész! Most már indíthat terhelést a K8s klaszterén.

Mi vár ránk a jövőben

Remélem, hogy a fenti utasítás segített spórolni egy kis időt és idegességet.
A folyamatok, amelyek az iparban zajlanak, gyakran attól függnek, hogyan fogadják őket a végfelhasználók többsége és más szoftver fejlesztők a megfelelő részen. Még nem világos, hová vezetnek az OCI kezdeményezések néhány év múlva, de örömmel figyeljük ezt. Véleményét most közvetlenül megoszthatja a megjegyzésekben.

Maradjatok velünk!

Ez a cikk a következő forrásoknak köszönhető:



Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster