CRI-O як замена Docker у якасці выкананага асяроддзя для Kubernetes: налада на CentOS 8

Прывітанне! Мяне клічуць Сяргей, я DevOps у Surf. DevOps-аддзел у Surf ставіць сваёй задачай не толькі наладжванне ўзаемадзеяння паміж адмыслоўцамі і інтэграцыю працоўных працэсаў, але і актыўныя даследаванні і ўкараненне актуальных тэхналогій як ва ўласную інфраструктуру, так і ў інфраструктуру замоўца.

Ніжэй я крыху раскажу пра змены ў тэхналагічным стэку для кантэйнераў, з якімі мы сустрэліся пры вывучэнні дыстрыбутыва CentOS 8 і пра тое, што такое CRI-O і як хутка наладзіць з яго дапамогай выкананае асяроддзе для Kubernetes.

CRI-O як замена Docker у якасці выкананага асяроддзя для Kubernetes: налада на CentOS 8

Чаму Docker адсутнічае ў стандартнай пастаўцы CentOS 8

Пасля ўстаноўкі апошніх буйных рэлізаў RHEL 8 або CentOS 8 нельга не заўважыць: у гэтых дыстрыбутывах і афіцыйных рэпазітарах адсутнічае дадатак Докер, якое ідэалагічна і функцыянальна замяняюць сабой пакеты Падман, Buildah (прысутнічаюць у дыстрыбутыве па змаўчанні) і CRI-O. Гэта звязана з практычнай рэалізацыяй стандартаў, якія распрацоўваюцца, у тым ліку, і кампаніяй Red Hat у рамках праекта Open Container Initiative (OCI).

Мэта OCI, якая з'яўляецца часткай The Linux Foundation, – стварэнне адкрытых індустрыяльных стандартаў для фарматаў і выкананага асяроддзя кантэйнераў, якія б вырашалі адразу некалькі задач. Па-першае, не супярэчылі як філасофіі Linux (напрыклад, у той яе частцы, што кожная праграма павінна выконваць нейкае адно дзеянне, а Докер уяўляе сабой гэтакі камбайн усё-у-адным). Па-другое, маглі б ухіліць усе наяўныя недахопы ў праграмным забеспячэнні Докер. Па-трэцяе, былі б цалкам сумяшчальнымі з бізнес-патрабаваннямі, якія высоўваюцца вядучымі камерцыйнымі платформамі для разгортвання, кіравання і абслугоўвання кантэйнерызаваных прыкладанняў (напрыклад, Red Hat OpenShift).

Недахопы Докер і добрыя якасці новага ПЗ ужо былі даволі падрабязна апісаны ў гэтым артыкуле, а з падрабязным апісаннем як усяго прапанаванага ў рамках праекту OCI стэка ПЗ і яго архітэктурнымі асаблівасцямі можна азнаёміцца ​​ў афіцыйнай дакументацыі і артыкулах як ад самой Red Hat (нядрэнная артыкул у Red Hat blog), так і ў іншых аглядах.

Важна адзначыць, якую функцыянальнасць маюць кампаненты прапанаванага стэка:

  • Падман - непасрэднае ўзаемадзеянне з кантэйнерамі і сховішчам вобразаў праз працэс runC;
  • Buildah - зборка і загрузка ў рэестр вобразаў;
  • CRI-O - выкананае асяроддзе для сістэм аркестрацыі кантэйнераў (напрыклад, Kubernetes).

Думаю, што для разумення агульнай схемы ўзаемадзеяння паміж кампанентамі стэка мэтазгодна прывесці тут схему сувязяў. Kubernetes c runC і нізкаўзроўневымі бібліятэкамі з выкарыстаннем CRI-O:

CRI-O як замена Docker у якасці выкананага асяроддзя для Kubernetes: налада на CentOS 8

CRI-O и Kubernetes прытрымліваюцца аднаго і таго ж цыклу выпуску і падтрымкі (матрыца сумяшчальнасці вельмі простая: мажорныя версіі Kubernetes и CRI-O супадаюць), а гэта, з улікам арыенціра на поўнае і ўсебаковае тэставанне працы дадзенага стэка распрацоўшчыкамі, дае нам права чакаць максімальна дасягальнай стабільнасці ў працы пры любых сцэнарах выкарыстання (тут на карысць ідзе і адносная легкаважнасць CRI-O у параўнанні з Докер у сілу мэтанакіраванага абмежавання функцыянальнасці).

Пры ўстаноўцы Kubernetes "right way" спосабам (па меркаванні OCI, вядома) з выкарыстаннем CRI-O на CentOS 8 мы сутыкнуліся з невялікімі цяжкасцямі, якія, аднак, паспяхова пераадолелі. Буду рады падзяліцца з вамі інструкцыяй па ўстаноўцы і наладзе, якія ў сукупнасці зоймуць ад сілы 10 хвілін.

Як разгарнуць Kubernetes на CentOS 8 з выкарыстаннем асяроддзя CRI-O

Папярэднія ўмовы: наяўнасць як мінімум аднаго хаста (2 cores, 4 GB RAM, назапашвальнік не менш за 15 GB) з усталяванай CentOS 8 (рэкамендуецца профіль усталёўкі «Server»), а таксама запісы для яго ў лакальным DNS (у крайнім выпадку можна абыйсціся запісам у /etc/hosts). І не забудзьцеся адключыць swap.

Усе аперацыі на хасце вырабляем ад імя карыстальніка root, будзьце ўважлівыя.

  1. На першым кроку наладзім АС, усталюем і наладзім папярэднія залежнасці для CRI-O.
    • Абновім АС:
      dnf -y update
      

    • Далей патрабуецца наладзіць файрвол і SELinux. Тут у нас усё залежыць ад атачэння, у якім будуць працаваць наш хост ці хасты. Вы можаце альбо наладзіць файрвол па рэкамендацыях з дакументацыі, альбо, калі знаходзіцеся ў даверанай сетцы або ўжываеце іншы файрвол, змяніць зону па змаўчанні на давераную або выключыць файрвол:
      firewall-cmd --set-default-zone trusted
      
      firewall-cmd --reload

      Каб выключыць файрвол можна выкарыстоўваць наступную каманду:

      systemctl disable --now firewalld
      

      SELinux патрабуецца выключыць або перавесці ў рэжым "permissive":

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

    • загрузім неабходныя модулі ядра і пакеты, наладзім аўтаматычную загрузку модуля "br_netfilter" пры старце сістэмы:
      modprobe overlay
      
      modprobe br_netfilter
      
      echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf
      
      dnf -y install iproute-tc
      

    • для актывацыі форвардынгу пакетаў і карэктнай апрацоўкі трафіку зробім адпаведныя наладкі:
      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
      

      ужыем зробленыя налады:

      sysctl --system

    • задамо неабходную версію CRI-O (мажорная версія CRI-O, як ужо згадвалася, супадаюць з патрабаванай версіяй Kubernetes), так як апошняя стабільная версія Kubernetes на дадзены момант 1.18:
      export REQUIRED_VERSION=1.18
      

      дадамо неабходныя рэпазітары:

      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

    • зараз мы можам усталяваць CRI-O:
      dnf -y install cri-o
      

      Звярніце ўвагу на першы нюанс, які мы сустракаем падчас усталёўкі: неабходна адрэдагаваць канфігурацыю CRI-O перад запускам сэрвісу, бо патрабаваны кампанент conmon мае адрознае ад паказанага месца размяшчэння:

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

      Цяпер можна актываваць і запусціць дэман CRI-O:

      systemctl enable --now crio
      

      Можна праверыць статус дэмана:

      systemctl status crio
      

  2. Ўстаноўка і актывацыя Kubernetes.
    • Дадамо патрабаваны рэпазітар:
      cat <<EOF > /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
      

      Цяпер мы можам усталяваць Kubernetes (версіі 1.18, як ужо адзначалася вышэй):

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

    • Другі важны нюанс: бо мы не выкарыстоўваем дэман Докер, а выкарыстоўваем дэман CRI-O, да запуску і ініцыялізацыі Kubernetes патрабуецца ўнесці адпаведныя наладкі ў канфігурацыйны файл /var/lib/kubelet/config.yaml, папярэдне стварыўшы патрэбны каталог:
      mkdir /var/lib/kubelet
      
      cat <<EOF > /var/lib/kubelet/config.yaml
      apiVersion: kubelet.config.k8s.io/v1beta1
      kind: KubeletConfiguration
      cgroupDriver: systemd
      EOF

    • Трэці важны момант, з якім мы сутыкаемся пры ўсталёўцы: нягледзячы на ​​тое, што мы паказалі выкарыстоўваны драйвер кантрольная група, і яго настройка праз аргументы перадаюцца кубелет састарэла (на што прама паказана ў дакументацыі), нам неабходна дадаць у файл аргументы, інакш наш кластар не ініцыялізуецца:
      cat /dev/null > /etc/sysconfig/kubelet
      
      cat <<EOF > /etc/sysconfig/kubelet
      KUBELET_EXTRA_ARGS=--container-runtime=remote --cgroup-driver=systemd --container-runtime-endpoint='unix:///var/run/crio/crio.sock'
      EOF

    • Цяпер мы можам актываваць дэман кубелет:
      sudo systemctl enable --now kubelet
      

      Каб настроіць плоскасць кіравання або працоўны ноды за лічаныя хвіліны, вы можаце скарыстацца гэтым скрыптам.

  3. Час ініцыялізаваць наш кластар.
    • Для ініцыялізацыі кластара выканайце каманду:
      kubeadm init --pod-network-cidr=10.244.0.0/16
      

      Абавязкова запішыце каманду далучэння да кластара "kubeadm join …", якой прапануецца скарыстацца ў канцы вываду, або, як мінімум, названыя токены.

    • Усталюем убудову (CNI) для працы Pod network. Я рэкамендую выкарыстоўваць каленкор. Магчыма, больш папулярны фланель мае праблемы з сумяшчальнасцю з nftablesкаб і каленкор - адзіная рэалізацыя CNI, рэкамендуемая і цалкам пратэставаная праектам Kubernetes:
      kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 

    • Для падлучэння worker ноды да нашага кластара яе патрабуецца наладзіць па пунктах інструкцыі 1 і 2, альбо скарыстацца скрыптам, Затым выканаць каманду з высновы «kubeadm init …», якую мы запісалі на папярэднім этапе:
      kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
          --discovery-token-ca-cert-hash $TOKEN_HASH

    • Праверым, што наш кластар ініцыялізаваны і пачаў працу:
      kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
      

    Гатова! Вы ўжо можаце размяшчаць на вашым K8s кластары карысную нагрузку.

Што нас чакае наперадзе

Спадзяюся, што інструкцыя вышэй дапамагла зэканоміць вам крыху часу і нерваў.
Зыход працэсаў, якія адбываюцца ў індустрыі, часцяком залежыць ад таго, як іх прымае асноўная маса канчатковых карыстачоў і распрацоўнікаў іншага ПА у якая адпавядае нішы. Пакуль не зусім зразумела, да якога выніку праз некалькі гадоў прывядуць ініцыятывы OCI, але мы будзем з задавальненнем за гэтым сачыць. Сваім меркаваннем вы можаце падзяліцца прама зараз у каментарах.

Сачыце за абнаўленнямі!

Гэты артыкул з'явіўся дзякуючы наступным крыніцам:



Крыніца: habr.com

Дадаць каментар