ProHoster > блог > адміністраванне > CRI-O як замена Docker у якасці выкананага асяроддзя для Kubernetes: налада на CentOS 8
CRI-O як замена Docker у якасці выкананага асяроддзя для Kubernetes: налада на CentOS 8
Прывітанне! Мяне клічуць Сяргей, я DevOps у Surf. DevOps-аддзел у Surf ставіць сваёй задачай не толькі наладжванне ўзаемадзеяння паміж адмыслоўцамі і інтэграцыю працоўных працэсаў, але і актыўныя даследаванні і ўкараненне актуальных тэхналогій як ва ўласную інфраструктуру, так і ў інфраструктуру замоўца.
Ніжэй я крыху раскажу пра змены ў тэхналагічным стэку для кантэйнераў, з якімі мы сустрэліся пры вывучэнні дыстрыбутыва CentOS 8 і пра тое, што такое CRI-O і як хутка наладзіць з яго дапамогай выкананае асяроддзе для Kubernetes.
Чаму 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 и 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, будзьце ўважлівыя.
На першым кроку наладзім АС, усталюем і наладзім папярэднія залежнасці для CRI-O.
Абновім АС:
dnf -y update
Далей патрабуецца наладзіць файрвол і SELinux. Тут у нас усё залежыць ад атачэння, у якім будуць працаваць наш хост ці хасты. Вы можаце альбо наладзіць файрвол па рэкамендацыях з дакументацыі, альбо, калі знаходзіцеся ў даверанай сетцы або ўжываеце іншы файрвол, змяніць зону па змаўчанні на давераную або выключыць файрвол:
задамо неабходную версію CRI-O (мажорная версія CRI-O, як ужо згадвалася, супадаюць з патрабаванай версіяй Kubernetes), так як апошняя стабільная версія Kubernetes на дадзены момант 1.18:
Звярніце ўвагу на першы нюанс, які мы сустракаем падчас усталёўкі: неабходна адрэдагаваць канфігурацыю CRI-O перад запускам сэрвісу, бо патрабаваны кампанент conmon мае адрознае ад паказанага месца размяшчэння:
sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf
Другі важны нюанс: бо мы не выкарыстоўваем дэман Докер, а выкарыстоўваем дэман CRI-O, да запуску і ініцыялізацыі Kubernetes патрабуецца ўнесці адпаведныя наладкі ў канфігурацыйны файл /var/lib/kubelet/config.yaml, папярэдне стварыўшы патрэбны каталог:
Трэці важны момант, з якім мы сутыкаемся пры ўсталёўцы: нягледзячы на тое, што мы паказалі выкарыстоўваны драйвер кантрольная група, і яго настройка праз аргументы перадаюцца кубелет састарэла (на што прама паказана ў дакументацыі), нам неабходна дадаць у файл аргументы, інакш наш кластар не ініцыялізуецца:
Каб настроіць плоскасць кіравання або працоўны ноды за лічаныя хвіліны, вы можаце скарыстацца гэтым скрыптам.
Час ініцыялізаваць наш кластар.
Для ініцыялізацыі кластара выканайце каманду:
kubeadm init --pod-network-cidr=10.244.0.0/16
Абавязкова запішыце каманду далучэння да кластара "kubeadm join …", якой прапануецца скарыстацца ў канцы вываду, або, як мінімум, названыя токены.
Усталюем убудову (CNI) для працы Pod network. Я рэкамендую выкарыстоўваць каленкор. Магчыма, больш папулярны фланель мае праблемы з сумяшчальнасцю з nftablesкаб і каленкор - адзіная рэалізацыя CNI, рэкамендуемая і цалкам пратэставаная праектам Kubernetes:
Для падлучэння worker ноды да нашага кластара яе патрабуецца наладзіць па пунктах інструкцыі 1 і 2, альбо скарыстацца скрыптам, Затым выканаць каманду з высновы «kubeadm init …», якую мы запісалі на папярэднім этапе:
Праверым, што наш кластар ініцыялізаваны і пачаў працу:
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
Гатова! Вы ўжо можаце размяшчаць на вашым K8s кластары карысную нагрузку.
Што нас чакае наперадзе
Спадзяюся, што інструкцыя вышэй дапамагла зэканоміць вам крыху часу і нерваў.
Зыход працэсаў, якія адбываюцца ў індустрыі, часцяком залежыць ад таго, як іх прымае асноўная маса канчатковых карыстачоў і распрацоўнікаў іншага ПА у якая адпавядае нішы. Пакуль не зусім зразумела, да якога выніку праз некалькі гадоў прывядуць ініцыятывы OCI, але мы будзем з задавальненнем за гэтым сачыць. Сваім меркаваннем вы можаце падзяліцца прама зараз у каментарах.
Сачыце за абнаўленнямі!
Гэты артыкул з'явіўся дзякуючы наступным крыніцам: