CRI-O, როგორც Docker-ის შემცვლელი, როგორც Kubernetes-ის გაშვების გარემო: დაყენება CentOS 8-ზე

გამარჯობა! მე მქვია სერგეი, მე ვარ DevOps Surf-ში. DevOps დეპარტამენტი Surf-ში მიზნად ისახავს არა მხოლოდ სპეციალისტებს შორის ურთიერთქმედების დამყარებას და სამუშაო პროცესების ინტეგრირებას, არამედ ასევე აქტიურად შეისწავლოს და დანერგოს მიმდინარე ტექნოლოგიები როგორც საკუთარ ინფრასტრუქტურაში, ასევე მომხმარებლის ინფრასტრუქტურაში.

ქვემოთ ცოტას ვისაუბრებ კონტეინერების ტექნოლოგიის დასტაში არსებულ ცვლილებებზე, რომლებიც შეგვხვდა განაწილების შესწავლისას CentOS 8 და იმის შესახებ, თუ რა არის CRI-O და როგორ სწრაფად დააყენოთ შესრულებადი გარემო კუბერნეტები.

რატომ არ შედის Docker CentOS 8-ში?

უახლესი ძირითადი გამოშვებების დაყენების შემდეგ rhel 8 ან CentOS 8 არ შეიძლება არ შეამჩნიოთ: ეს დისტრიბუციები და ოფიციალური საცავი არ შეიცავს აპლიკაციას docker, რომელიც იდეოლოგიურად და ფუნქციურად ცვლის პაკეტებს პოდმანი, ბილდაჰ (ნაგულისხმევად წარმოდგენილია განაწილებაში) და CRI-O. ეს განპირობებულია სტანდარტების პრაქტიკული განხორციელებით, რომლებიც შემუშავებულია, სხვა საკითხებთან ერთად, Red Hat-ის მიერ Open Container Initiative (OCI) პროექტის ფარგლებში.

OCI-ის მიზანი, რომელიც არის Linux Foundation-ის ნაწილი, არის შექმნას ღია ინდუსტრიის სტანდარტები კონტეინერის ფორმატებისთვის და გაშვების დროებისთვის, რომლებიც ერთდროულად რამდენიმე პრობლემას გადაჭრის. ჯერ ერთი, ისინი არ ეწინააღმდეგებოდნენ Linux-ის ფილოსოფიას (მაგალითად, იმ ნაწილში, რომ თითოეულმა პროგრამამ უნდა შეასრულოს ერთი მოქმედება და docker არის ერთგვარი „ერთში“ კომბაინი). მეორეც, მათ შეეძლოთ პროგრამული უზრუნველყოფის ყველა არსებული ხარვეზის აღმოფხვრა docker. მესამე, ისინი სრულად თავსებადია წამყვანი კომერციული პლატფორმების ბიზნეს მოთხოვნებთან კონტეინერირებული აპლიკაციების განლაგების, მართვისა და მომსახურებისთვის (მაგალითად, Red Hat OpenShift).

შეზღუდვები docker და ახალი პროგრამული უზრუნველყოფის უპირატესობები უკვე დეტალურად არის აღწერილი ეს მუხლიდა OCI პროექტის ფარგლებში შემოთავაზებული პროგრამული უზრუნველყოფის მთელი დატის დეტალური აღწერა და მისი არქიტექტურული მახასიათებლები შეგიძლიათ იხილოთ ოფიციალურ დოკუმენტაციაში და თავად Red Hat-ის სტატიებში (ცუდი არ არის სტატიის Red Hat ბლოგზე) და მესამე მხარის მიმოხილვები.

მნიშვნელოვანია აღინიშნოს, რა ფუნქციონირება აქვს შემოთავაზებული სტეკის კომპონენტებს:

• პოდმანი — პირდაპირი ურთიერთქმედება კონტეინერებთან და გამოსახულების შენახვა runC პროცესის მეშვეობით;
• ბილდაჰ - სურათების შეკრება და რეესტრში ატვირთვა;
• CRI-O — შესასრულებელი გარემო კონტეინერის ორკესტრირების სისტემებისთვის (მაგალითად, Kubernetes).

მე ვფიქრობ, რომ სტეკის კომპონენტებს შორის ურთიერთქმედების ზოგადი სქემის გასაგებად, მიზანშეწონილია აქ კავშირის დიაგრამა. კუბერნეტები c runC და დაბალი დონის ბიბლიოთეკების გამოყენებით CRI-O:

CRI-O и კუბერნეტები დაიცავით იგივე გამოშვების და მხარდაჭერის ციკლი (თავსებადობის მატრიცა ძალიან მარტივია: ძირითადი ვერსიები კუბერნეტები и CRI-O ემთხვევა) და ეს, დეველოპერების მიერ ამ სტეკის მუშაობის სრულ და ყოვლისმომცველ ტესტირებაზე ფოკუსირების გათვალისწინებით, გვაძლევს უფლებას ველოდოთ ექსპლუატაციაში მაქსიმალურ მიღწევად სტაბილურობას ნებისმიერი გამოყენების სცენარის პირობებში (აქ ასევე სასარგებლოა შედარებითი სიმსუბუქე. CRI-O შედარებით docker ფუნქციონირების მიზანმიმართული შეზღუდვის გამო).

ინსტალაციისას კუბერნეტები „სწორი გზა“ (OCI-ის მიხედვით, რა თქმა უნდა) გამოყენებით CRI-O on CentOS 8 შეგვხვდა მცირე სირთულეები, რომლებიც, თუმცა, წარმატებით დავძლიეთ. სიამოვნებით გაგიზიარებთ ინსტალაციისა და კონფიგურაციის ინსტრუქციებს, რაც ჯამში დაახლოებით 10 წუთს მიიღებს.

როგორ განვათავსოთ Kubernetes CentOS 8-ზე CRI-O ჩარჩოს გამოყენებით

წინაპირობები: მინიმუმ ერთი ჰოსტის არსებობა (2 ბირთვი, 4 GB ოპერატიული მეხსიერება, მინიმუმ 15 GB მეხსიერება) დაინსტალირებული CentOS 8 (რეკომენდებულია "სერვერის" ინსტალაციის პროფილი), ისევე როგორც მასში ჩანაწერები ადგილობრივ DNS-ში (როგორც უკანასკნელი საშუალება, შეგიძლიათ მიიღოთ ჩანაწერი /etc/hosts-ში). და არ დაგავიწყდეს გაცვლა-გამორთვა.

ჩვენ ვასრულებთ ყველა ოპერაციას ჰოსტზე, როგორც root მომხმარებელი, ფრთხილად იყავით.

1. პირველ ეტაპზე ჩვენ დავაკონფიგურირებთ OS-ს, დავაინსტალირებთ და დავაკონფიგურირებთ წინასწარ დამოკიდებულებებს CRI-O-სთვის.
   • მოდით განაახლოთ OS:

     dnf -y update
     

   • შემდეგ თქვენ უნდა დააკონფიგურიროთ firewall და SELinux. აქ ყველაფერი დამოკიდებულია გარემოზე, რომელშიც ჩვენი მასპინძელი ან მასპინძლები იმუშავებენ. თქვენ შეგიძლიათ დააყენოთ firewall რეკომენდაციების შესაბამისად დოკუმენტაცია, ან, თუ თქვენ ხართ სანდო ქსელში ან იყენებთ მესამე მხარის ფეიერვოლს, შეცვალეთ ნაგულისხმევი ზონა სანდოზე ან გამორთეთ ბუხარი:

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

     Firewall-ის გამორთვისთვის შეგიძლიათ გამოიყენოთ შემდეგი ბრძანება:

     systemctl disable --now firewalld
     

     SELinux უნდა გამორთოთ ან გადართოთ "ნებადართული" რეჟიმში:

     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, როგორც უკვე აღვნიშნეთ, ემთხვევა საჭირო ვერსიას კუბერნეტები), უახლესი სტაბილური ვერსიიდან კუბერნეტები ამჟამად 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 სერვისის დაწყებამდე, რადგან საჭირო საერთო კომპონენტს აქვს განსხვავებული მდებარეობა, ვიდრე მითითებული:

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

     ახლა თქვენ შეგიძლიათ გაააქტიუროთ და დაიწყოთ დემონი CRI-O:

     systemctl enable --now crio
     

     თქვენ შეგიძლიათ შეამოწმოთ დემონის სტატუსი:

     systemctl status crio
     

2. ინსტალაცია და გააქტიურება კუბერნეტები.
   • მოდით დავამატოთ საჭირო საცავი:

     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
     

     ახლა ჩვენ შეგვიძლია დავაყენოთ კუბერნეტები (ვერსია 1.18, როგორც ზემოთ აღინიშნა):

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

   • მეორე მნიშვნელოვანი ნიუანსი: რადგან ჩვენ არ ვიყენებთ დემონს docker, მაგრამ ჩვენ ვიყენებთ დემონს CRI-O, გაშვებამდე და ინიციალიზაციამდე კუბერნეტები თქვენ უნდა გააკეთოთ შესაბამისი პარამეტრები კონფიგურაციის ფაილში /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

   • მესამე მნიშვნელოვანი წერტილი, რომელსაც ვხვდებით ინსტალაციის დროს: მიუხედავად იმისა, რომ ჩვენ მივუთითეთ გამოყენებული დრაივერი cgroup, და მისი კონფიგურაცია გავლილი არგუმენტების მეშვეობით კუბელეტი მოძველებულია (როგორც ცალსახად არის ნათქვამი დოკუმენტაციაში), ჩვენ უნდა დავამატოთ არგუმენტები ფაილში, წინააღმდეგ შემთხვევაში ჩვენი კლასტერი არ იქნება ინიციალიზებული:

     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 ქსელისთვის. გირჩევთ გამოიყენოთ კალიკო. შესაძლოა უფრო პოპულარული ფლანელი აქვს თავსებადობის პრობლემა nftablesდიახ და დიახ კალიკო - ერთადერთი CNI იმპლემენტაცია, რომელიც რეკომენდებულია და სრულად გამოცდილია პროექტის მიერ კუბერნეტები:

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

   • მუშა კვანძის ჩვენს კლასტერთან დასაკავშირებლად, თქვენ უნდა დააკონფიგურიროთ ის 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 ინიციატივები რამდენიმე წელიწადში, მაგრამ ჩვენ სიამოვნებით ვადევნებთ თვალს. თქვენ შეგიძლიათ გააზიაროთ თქვენი აზრი ახლავე კომენტარებში.

ადევნეთ თვალყური!

ეს სტატია გამოჩნდა შემდეგი წყაროების წყალობით:

• განყოფილება კონტეინერის მუშაობის დროის შესახებ Kubernetes დოკუმენტაცია
• გვერდი CRI-O პროექტი ინტერნეტში
• Red Hat ბლოგის სტატიები: ეს ერთი, ამ და მრავალი სხვა

წყარო: www.habr.com