ProHoster > Блог > басқарма > Kubernetes кластерін тоқтаусыз жаңарту

Kubernetes кластерін тоқтаусыз жаңарту

Kubernetes кластерін тоқтаусыз жаңарту

Kubernetes кластері үшін жаңарту процесі

Бір сәтте Kubernetes кластерін пайдаланған кезде, іске қосылған түйіндерді жаңарту қажеттілігі туындайды. Бұл бума жаңартуларын, ядро ​​жаңартуларын немесе жаңа виртуалды машина кескіндерін орналастыруды қамтуы мүмкін. Кубернетес терминологиясында бұл деп аталады «Ерікті бұзу».

Бұл пост 4 хабарлама сериясының бөлігі:

  1. Бұл пост.
  2. Kubernetes кластеріндегі қосқыштарды дұрыс өшіру
  3. Пост жойылған кезде оны кешіктіріп тоқтату
  4. PodDisruptionBudgets көмегімен Kubernetes кластерінің тоқтап қалуын қалай болдырмауға болады

(шамамен. Сериядағы қалған мақалалардың аудармасы жақын арада күтіледі)

Бұл мақалада біз Kubernetes кластеріңізде жұмыс істейтін түйіндер үшін нөлдік тоқтау уақытына жету үшін ұсынатын барлық құралдарды сипаттаймыз.

Мәселені анықтау

Біз алдымен аңғал тәсілді қабылдаймыз, проблемаларды анықтаймыз және осы тәсілдің ықтимал тәуекелдерін бағалаймыз және цикл бойы кездесетін әрбір мәселені шешу үшін білім қалыптастырамыз. Нәтиже - нөлдік тоқтау мақсатына жету үшін өмірлік цикл ілмектерін, дайындық зондтарын және Pod үзіліс бюджеттерін пайдаланатын конфигурация.

Саяхатымызды бастау үшін нақты мысал келтірейік. Бізде екі түйіннен тұратын Кубернетес кластері бар делік, онда бағдарлама артында орналасқан екі түйінмен жұмыс істейді. Service:

Kubernetes кластерін тоқтаусыз жаңарту

Екі Kubernetes кластер түйіндерінде жұмыс істейтін Nginx және Service бар екі қосқыштан бастайық.

Біз кластердегі екі жұмысшы түйінінің ядро ​​нұсқасын жаңартқымыз келеді. Мұны қалай істейміз? Қарапайым шешім жаңартылған конфигурациямен жаңа түйіндерді жүктеп, жаңаларын іске қосу кезінде ескі түйіндерді өшіру болады. Бұл жұмыс істейтін болса да, бұл тәсілмен бірнеше проблемалар болады:

  • Ескі түйіндерді өшірген кезде, оларда жұмыс істейтін қосқыштар да өшіріледі. Әдемі өшіру үшін бөтелкелерді тазалау қажет болса ше? Сіз пайдаланып жатқан виртуализация жүйесі тазалау процесінің аяқталуын күтпеуі мүмкін.
  • Барлық түйіндерді бір уақытта өшірсеңіз ше? Бөлшектер жаңа түйіндерге ауысқанда, сіз лайықты тоқтау уақытын аласыз.

Біз түйінге өзгертулер енгізген кезде жұмысшы процестеріміздің ешқайсысы іске қосылмауын қамтамасыз ете отырып, ескі түйіндерден қондырмаларды әдемі көшіру тәсілі қажет. Немесе мысалдағыдай кластерді толық ауыстыруды орындаған кезде (яғни VM кескіндерін ауыстырамыз), біз жұмыс істеп тұрған қолданбаларды ескі түйіндерден жаңаларына тасымалдағымыз келеді. Екі жағдайда да, біз ескі түйіндерде жаңа қосқыштарды жоспарлауды болдырмаймыз, содан кейін олардан барлық іске қосылған қосқыштарды шығарғымыз келеді. Осы мақсаттарға жету үшін біз пәрменді пайдалана аламыз kubectl drain.

Түйіннен барлық қосқыштарды қайта бөлу

Суды төгу операциясы түйіннен барлық қосқыштарды қайта бөлуге мүмкіндік береді. Дренажды орындау кезінде түйін жоспарланбаған деп белгіленеді (жалауша NoSchedule). Бұл жаңа бөтелкелердің пайда болуына жол бермейді. Содан кейін дренаж түйіннен түйіршіктерді шығара бастайды, сигнал жібере отырып, түйінде жұмыс істеп тұрған контейнерлерді өшіреді. TERM қабықтағы контейнерлер.

Дегенмен kubectl drain шұңқырларды шығаруда жақсы жұмыс істейді, су төгу жұмысының сәтсіздігін тудыруы мүмкін тағы екі фактор бар:

  • Сіздің өтінішіңіз жіберілгеннен кейін жақсы аяқталуы керек TERM сигнал. Қондырғылар шығарылған кезде, Кубернетес сигнал жібереді TERM контейнерлерді ұстайды және олардың белгілі бір уақыт ішінде тоқтауын күтеді, содан кейін олар тоқтамаған болса, оларды мәжбүрлеп тоқтатады. Кез келген жағдайда, егер сіздің контейнеріңіз сигналды дұрыс қабылдамаса, егер олар қазір жұмыс істеп тұрса (мысалы, дерекқор транзакциясы орындалуда) қосқыштарды әлі де қате өшіре аласыз.
  • Қолданбаны қамтитын барлық бөлімдерді жоғалтасыз. Ол жаңа контейнерлер жаңа түйіндерде іске қосылғанда қолжетімсіз болуы мүмкін немесе подкасттар контроллерсіз орналастырылса, олар мүлде қайта қосылмауы мүмкін.

Тоқтау уақытын болдырмау

Түйіндегі төгу операциясы сияқты ерікті үзілістерден тоқтау уақытын азайту үшін Kubernetes келесі ақауларды өңдеу опцияларын ұсынады:

Серияның қалған бөлігінде біз осы Kubernetes мүмкіндіктерін подкольді тасымалдау әсерін азайту үшін қолданамыз. Негізгі идеяны орындауды жеңілдету үшін біз жоғарыдағы мысалды келесі ресурс конфигурациясымен қолданамыз:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Бұл конфигурация минималды мысал болып табылады Deploymentкластердегі nginx қосқыштарын басқаратын . Сонымен қатар, конфигурация ресурсты сипаттайды Service, ол кластердегі nginx қосқыштарына қол жеткізу үшін пайдаланылуы мүмкін.

Бүкіл цикл бойы біз бұл конфигурацияны ақырында Kubernetes тоқтау уақытын қысқарту үшін ұсынатын барлық мүмкіндіктерді қамтитындай етіп кеңейтеміз.

AWS және одан тыс жерде нөлдік үзіліс үшін Kubernetes кластері жаңартуларының толық енгізілген және тексерілген нұсқасын алу үшін мына сайтқа кіріңіз. Gruntwork.io.

Сондай-ақ біздің блогтағы басқа мақалаларды оқыңыз:

Ақпарат көзі: www.habr.com

пікір қалдыру