Kubernetes'ти кеңейтүү жана толуктоо (сереп жана видео отчет)

8-апрелде конференцияда Saint HighLoad++ 2019, "DevOps жана Операциялар" бөлүмүнүн бир бөлүгү катары "Kubernetes кеңейтүү жана толуктоо" баяндамасы берилди, аны түзүүгө Flant компаниясынын үч кызматкери катышты. Анда биз Kubernetesтин мүмкүнчүлүктөрүн кеңейтүүнү жана толуктоону каалаган, бирок биз даяр жана жөнөкөй чечим таба албаган көптөгөн жагдайлар жөнүндө сүйлөшөбүз. Бизде Open Source долбоорлору түрүндө керектүү чечимдер бар жана бул сөз да аларга арналган.

Салт боюнча биз кубанычтабыз отчеттун видеосу (50 мүнөт, макалага караганда алда канча маалыматтуу) жана текст түрүндө негизги кыскача. Go!

K8sдеги негизги жана толуктоолор

Кубернетес көптөн бери калыптанып калган тармакты жана башкарууга болгон мамилени өзгөртүп жатат:

• Ага рахмат абстракциялар, биз мындан ары конфигурацияны орнотуу же буйрукту иштетүү (Chef, Ansible...) сыяктуу түшүнүктөр менен иштебейбиз, бирок контейнерлерди, кызматтарды ж.б. топторду колдонобуз.
• Биз нюанстар жөнүндө ойлонбостон арыздарды даярдай алабыз конкреттүү сайт, ал ишке киргизилет: жылаңач металл, провайдерлердин биринин булуту, ж.б.
• K8s менен сиз эч качан мынчалык жеткиликтүү болгон эмессиз мыкты практикалар инфраструктураны уюштуруу боюнча: масштабдоо ыкмалары, өзүн-өзү айыктыруу, каталарга чыдамдуулук ж.б.

Бирок, албетте, баары ушунчалык жылмакай эмес: Kubernetes да өзүнүн жаңы чакырыктарын алып келди.

Kubernetes жок бардык колдонуучулардын бардык көйгөйлөрүн чечүүчү комбайн болуп саналат. негизги Kubernetes камтылган минималдуу зарыл функциялардын жыйындысы үчүн гана жооптуу бардыгы кластер:

Kubernetes өзөгү контейнерлерди топтоо, трафикти башкаруу жана башкалар үчүн примитивдердин негизги топтомун аныктайт. Биз алар жөнүндө кененирээк сөз кылдык 2 жыл мурун отчет.

Башка жагынан алганда, K8s башкаларды жабууга жардам берген жеткиликтүү функцияларды кеңейтүү үчүн чоң мүмкүнчүлүктөрдү сунуш кылат - конкреттүү - колдонуучунун муктаждыктары. Kubernetes-ке кошумчалар кластердин администраторлорунун жоопкерчилигинде, алар кластерин "туура формада" алуу үчүн зарыл болгон нерселердин баарын орнотуп, конфигурациялашы керек [өзүнүн конкреттүү көйгөйлөрүн чечүү үчүн]. Булар кандай кошумчалар? Келгиле, кээ бир мисалдарды карап көрөлү.

Кошумчалардын мисалдары

Kubernetes орноткондон кийин, түйүн ичинде да, түйүндөрүнүн ортосунда да түйүндөрдүн өз ара аракеттенүүсү үчүн зарыл болгон тармак өз алдынча иштебей жатканына таң калышыбыз мүмкүн. Kubernetes ядросу анын ордуна керектүү байланыштарга кепилдик бербейт, ал тармакты аныктайт Interface (CNI) үчүнчү тараптын кошумчалары үчүн. Тармактын конфигурациясына жооп бере турган бул кошумчалардын бирин орнотушубуз керек.

Жакын мисал - маалыматтарды сактоо чечимдери (локалдык диск, тармак блок түзмөгү, Ceph...). Башында алар өзөктө болгон, бирок пайда болушу менен CSI кырдаал буга чейин сүрөттөлгөн окшош нерсеге өзгөрөт: интерфейс Kubernetesте, ал эми аны ишке ашыруу үчүнчү тараптын модулдарында.

Башка мисалдар төмөнкүлөрдү камтыйт:

• өтүшү- контролерлор (алардын кароосун караңыз биздин акыркы макала).
• сертификат менеджер:

  

• операторлор бул толуктоолордун бүтүндөй классы (аталган сертификат-менеджерди камтыйт), алар примитив(терди) жана контроллерди(ларды) аныктайт. Алардын ишинин логикасы биздин элестетүүбүз менен гана чектелет жана даяр инфраструктуралык компоненттерди (мисалы, МББ) примитивдерге айлантууга мүмкүндүк берет, алар менен иштөө бир топ жеңил (контейнерлердин жана алардын жөндөөлөрүнүн жыйындысына караганда). Көптөгөн операторлор жазылган - алардын көбү өндүрүшкө даяр эмес болсо да, бул убакыт маселеси:

  

• Метрикалар - Кубернетес интерфейсти (Metrics API) ишке ашыруудан кантип ажыратканын дагы бир иллюстрация (Prometheus адаптери, Datadog кластер агенти сыяктуу үчүнчү тараптын кошумчалары...).
• үчүн мониторинг жана статистика, бул жерде иш жузундо гана керек эмес Прометей жана Графана, бирок ошондой эле кубе-стат-метрика, түйүн-экспорттоочу ж.б.

Ал эми бул толуктоолордун толук тизмеси эмес... Мисалы, биз азыр Флант фирмасында орнотуп жатабыз 29 кошумчалар (анын бардыгы 249 Kubernetes объектисин түзөт). Жөнөкөй сөз менен айтканда, кошумчаларсыз кластердин жашоосун көрө албайбыз.

автоматизация

Операторлор биз күн сайын кездешүүчү күнүмдүк операцияларды автоматташтыруу үчүн иштелип чыккан. Бул жерде операторду жазуу сонун чечим боло турган реалдуу мисалдар келтирилген:

1. Колдонмо үчүн сүрөттөрү бар жеке (б.а. логинди талап кылган) реестр бар. Ар бир подкастка реестрде аныктыгын текшерүүгө мүмкүндүк берген атайын сыр ыйгарылат деп болжолдонууда. Биздин милдет - бул сырдын аталыштар мейкиндигинде болушун камсыз кылуу, андыктан поддержка сүрөттөрдү жүктөй алат. Колдонмолор көп болушу мүмкүн (алардын ар бирине сыр керек) жана сырларды дайыма жаңыртып туруу пайдалуу, андыктан сырларды кол менен коюу варианты жокко чыгарылат. Мына ушул жерде оператор жардамга келет: биз аттар мейкиндигинин пайда болушун күтө турган контроллерди түзөбүз жана ушул окуянын негизинде аттар мейкиндигине сыр кошот.
2. Демейки боюнча, поддондордон Интернетке кирүүгө тыюу салынат. Бирок кээде талап кылынышы мүмкүн: кирүү уруксат механизминин жөн гана иштөөсү логикалык, конкреттүү көндүмдөрдү талап кылбастан, мисалы, аттар мейкиндигинде белгилүү белгинин болушу менен. Бул жерде оператор бизге кантип жардам бере алат? Аттар мейкиндигинде энбелги пайда болушун күткөн жана Интернетке кирүү үчүн тиешелүү саясатты кошо турган контроллер түзүлөт.
3. Окшош жагдай: биз белгилүү бир кошуу керек дейли кайырлуу, эгерде анын окшош энбелгиси болсо (кандайдыр бир префикс менен). Оператор менен болгон аракеттер ачык-айкын...

Кандай гана кластер болбосун, күнүмдүк милдеттерди чечүү керек, жана туура муну операторлор аркылуу жасоого болот.

Бардык сүрөттөлгөн окуяларды жыйынтыктап, биз мындай жыйынтыкка келдик Кубернетеде ыңгайлуу иштөө үчүн сизге керек: A) кошумчаларды орнотуу, б) операторлорду иштеп чыгуу (күнүмдүк администратордук тапшырмаларды чечүү үчүн).

Kubernetes үчүн арыз кантип жазуу керек?

Жалпысынан алганда, схема жөнөкөй:

... бирок андан кийин мындай болот:

• Kubernetes API - бул өздөштүрүү үчүн көп убакытты талап кылган анча маанилүү эмес нерсе;
• программалоо бардыгы үчүн эмес (Go тили артыкчылыктуу тил катары тандалган, анткени ал үчүн атайын алкак бар - Оператор SDK);
• Кырдаалдын өзү да ушундай.

Жыйынтык: контролер жазуу (оператор) милдеттүү олуттуу ресурстарды жумшашат материалды окуу. Бул "чоң" операторлор үчүн - айталы, MySQL DBMS үчүн негиздүү болмок. Бирок жогоруда сүрөттөлгөн мисалдарды (сырларды ачуу, Интернетке кирүү...) эстесек, биз да туура кылгыбыз келет, анда сарпталган күч-аракет азыр бизге керектүү натыйжадан ашып түшөөрүн түшүнөбүз:

Жалпысынан алганда, дилемма пайда болот: көп ресурстарды коротуп, билдирүү жазуу үчүн туура куралды табыңыз же аны эски ыкма менен жасаңыз (бирок тез). Аны чечүү үчүн - бул экстремалдын ортосунда компромисс табуу үчүн - биз өзүбүздүн долбоорду түздүк: шел-оператор (ошондой эле анын кара акыркы билдирүү хабда).

Shell-оператор

Ал кантип иштейт? Кластерде Shell-оператору бар Go бинардык тутумун камтыган поддон бар. Анын жанында бир комплект турат илгичтер (алар жөнүндө көбүрөөк маалымат - төмөндө караңыз). Shell-оператор өзү белгилүү бир жазылат окуялар Kubernetes API'де, ал пайда болгондо тиешелүү илгичтерди ишке киргизет.

Снаряд-оператор кайсы окуяларга кайсы илгичтерди чакыруу керектигин кайдан билет? Бул маалымат снаряд-операторго илгичтердин өздөрү аркылуу берилет жана алар муну абдан жөнөкөй кылышат.

Илгич бул Bash скрипти же бир аргументти кабыл алган башка аткарылуучу файл --config жана JSON менен жооп берет. Акыркысы кайсы объекттерди кызыктырарын жана кайсы окуяларга (бул объекттер үчүн) жооп берүү керектигин аныктайт:

Мен биздин мисалдарыбыздын бири - тиркемелердин сүрөттөрү менен жеке реестрге кирүү үчүн сырларды ажыроочу оператордо ишке ашырууну сүрөттөп берем. Ал эки этаптан турат.

Көнүгүү: 1. Илгич жаз

Биринчиден, илгичте биз иштетебиз --config, биз аттар мейкиндигине, тагыраак айтканда, аларды түзүү учуруна кызыкдар экенибизди көрсөтүп:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

Логика кандай болмок? Ошондой эле абдан жөнөкөй:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

Биринчи кадам - ​​кайсы аттар мейкиндиги түзүлгөнүн билүү, экинчиси - аны колдонуу менен түзүү kubectl бул ысым мейкиндигинин сыры.

Көнүгүү: 2. Сүрөттү чогултуу

Болгону түзүлгөн илгичти снаряд операторуна өткөрүп берүү гана калды - муну кантип кылуу керек? Shell-оператордун өзү Docker сүрөтү катары келет, андыктан биздин милдетибиз бул сүрөттөгү атайын каталогго илгичти кошуу:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

Болгону аны чогултуп, түртүп коюу гана калды:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

Акыркы тийүү - бул сүрөттү кластерге жайгаштыруу. Бул үчүн, келгиле, жазалы жайылтуу:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

Көңүл бура турган эки жагдай бар:

1. жаңы түзүлгөн сүрөттү көрсөтүү;
2. Бул системанын курамдык бөлүгү, ал (кеминде) Kubernetesтеги окуяларга жазылуу жана аттар мейкиндигине сырларды бөлүштүрүү укуктарын талап кылат, ошондуктан биз илмек үчүн ServiceAccount (жана эрежелердин топтомун) түзөбүз.

Натыйжа - биз көйгөйүбүздү чечтик туугандар Кубернетес үчүн сырларды ажыратуу операторун түзгөн жол менен.

Башка кабык операторунун өзгөчөлүктөрү

Сиз тандаган түрдөгү илгич менен иштей турган объекттерди чектөө үчүн, аларды чыпкалоого болот, белгилүү бир белгилерге ылайык тандоо (же колдонуу matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

Берилген дедупликация механизми, бул - jq чыпкасын колдонуу - чоң JSON объектилерин кичинекей объекттерге айлантууга мүмкүндүк берет, мында биз өзгөрүүлөргө байкоо салгыбыз келген параметрлер гана калат.

Илгичти чакырганда, снаряд-оператор аны өткөрүп берет объект маалыматтары, ар кандай муктаждыктар үчүн колдонулушу мүмкүн.

Илгичтерди козгогон окуялар Kubernetes окуялары менен эле чектелбейт: кабык оператору колдоо көрсөтөт. убакыт боюнча илгичтерди чакыруу (салттуу пландаштыргычтагы crontabга окшош), ошондой эле өзгөчө окуя onStartup. Бул окуялардын бардыгын бириктирип, бир эле илгичке ыйгарса болот.

Жана шел-оператордун дагы эки өзгөчөлүгү:

1. Ал иштейт асинхрондуу. Kubernetes окуясы (мисалы, түзүлүп жаткан объект) алынгандыктан, кластерде башка окуялар (мисалы, жок кылынган объект) болушу мүмкүн жана илгичтер муну эсепке алышы керек. Эгерде илгич ката менен аткарылган болсо, демейки боюнча ал болот кайра чалуу ийгиликтүү аяктаганга чейин (бул жүрүм-турумду өзгөртүүгө болот).
2. Экспорт кылат метрикалар Прометей үчүн, анын жардамы менен сиз кабык-оператор иштеп жатканын түшүнө аласыз, ар бир илгич үчүн каталардын санын жана учурдагы кезектин өлчөмүн билип алыңыз.

Отчеттун бул бөлүгүн жыйынтыктоо үчүн:

Кошумчалар орнотулууда

Kubernetes менен ыңгайлуу иштөө үчүн кошумчаларды орнотуу зарылчылыгы да айтылды. Мен бул тууралуу биздин компаниянын жолунун мисалында айтып берем, биз азыр аны кантип жасайбыз.

Биз Kubernetes менен бир нече кластерлер менен иштей баштадык, алардын жалгыз кошумчасы Ingress болду. Аны ар бир кластерде башкача орнотуу керек болчу жана биз ар кандай чөйрөлөр үчүн бир нече YAML конфигурацияларын жасадык: жылаңач металл, AWS...

Кластерлер көп болгондуктан, конфигурациялар дагы көп болду. Мындан тышкары, биз бул конфигурацияларды өзүбүз жакшырттык, натыйжада алар кыйла гетерогендүү болуп калды:

Баарын иретке келтирүү үчүн, биз сценарийден баштадык (install-ingress.sh), аргумент катары биз жайгаштыра турган кластердин түрүн алып, керектүү YAML конфигурациясын түзүп, аны Kubernetesке жайылтты.

Кыскасы, биздин мындан аркы жолубуз жана ага байланыштуу ой жүгүртүүлөр төмөнкүчө болду:

• YAML конфигурациялары менен иштөө үчүн шаблон кыймылдаткычы талап кылынат (биринчи этапта бул жөнөкөй sed);
• кластерлердин санынын көбөйүшү менен автоматтык жаңыртуу зарылдыгы келип чыкты (эң алгачкы чечим скриптти Gitке коюу, аны cron аркылуу жаңыртуу жана аны иштетүү);
• Прометей үчүн да ушундай сценарий талап кылынган (install-prometheus.sh), бирок, ал бир топ көбүрөөк киргизүү маалыматтарын талап кылгандыгы, ошондой эле аларды сактоону (жакшы мааниде - борборлоштурулган жана кластерде) жана кээ бир маалыматтар (паролдор) автоматтык түрдө түзүлүшү мүмкүн экендиги менен айырмаланат:

  

• өсүп келе жаткан кластерлердин санына туура эмес нерсени жайылтуу коркунучу тынымсыз өсүп жатты, ошондуктан биз орнотуучулар (б.а. эки скрипт: Ingress жана Prometheus үчүн) сахналаштыруу керек болчу (Гитте бир нече бутактар, аларды тийиштүү түрдө жаңыртуу үчүн бир нече крон: туруктуу же сыноо кластерлери);
• с kubectl apply аны менен иштөө кыйын болуп калды, анткени ал декларативдик эмес жана объекттерди гана түзө алат, бирок алардын статусу боюнча чечим кабыл албайт/аларды жок кылат;
• Бизде ошол убакта такыр ишке ашыра элек кээ бир функциялар жетишпей жатты:
  • кластердик жаңыртуулардын натыйжасын толук көзөмөлдөө,
  • кластерден алынуучу маалыматтардын негизинде кээ бир параметрлерди автоматтык түрдө аныктоо (орнотуу скрипттери үчүн киргизүү),
  • үзгүлтүксүз ачылыш түрүндө анын логикалык өнүгүшү.

Бул топтолгон тажрыйбанын баарын биз башка долбоордун алкагында ишке ашырдык - addon-operator.

Addon-operator

Ал буга чейин айтылган кабык операторуна негизделген. Бүт система мындай көрүнөт:

Кабат операторунун илгичтерине төмөнкүлөр кошулат:

• баалуулуктарды сактоо,
• Руль диаграммасы,
• деген компонент баалуулуктар дүкөнүн көзөмөлдөйт жана - кандайдыр бир өзгөрүү болгон учурда - Хелмден диаграмманы кайра жылдырууну суранат.

Ошентип, биз Kubernetesтеги окуяга реакция кылып, илгичти ишке киргизе алабыз жана бул илгичтен сактагычка өзгөртүүлөрдү киргизе алабыз, андан кийин диаграмма кайра жүктөлөт. Алынган диаграммада биз илгичтердин топтомун жана диаграмманы бир компонентке бөлөбүз, аны биз чакырабыз модулу:

Көптөгөн модулдар болушу мүмкүн жана аларга биз глобалдык илгичтерди, глобалдык баалуулуктар дүкөнүн жана бул дүйнөлүк дүкөндү көзөмөлдөгөн компонентти кошобуз.

Эми, Kubernetesте бир нерсе болгондо, биз ага глобалдык илгич аркылуу жооп кайтарып, дүйнөлүк дүкөндө бир нерсени өзгөртө алабыз. Бул өзгөрүү байкалып, кластердеги бардык модулдардын жайылышына алып келет:

Бул схема жогоруда айтылган кошумчаларды орнотуу үчүн бардык талаптарды канааттандырат:

• Helm шаблон жана декларативдүүлүк үчүн жооптуу.
• Автоматтык жаңыртуу маселеси глобалдык илгичтин жардамы менен чечилди, ал график боюнча реестрге барат жана ал жерден жаңы системанын сүрөтүн көрсө, аны чыгарат (б.а. "өзү").
• Кластерде орнотууларды сактоо аркылуу ишке ашырылат ConfigMap, анда сактагычтар үчүн негизги маалыматтарды камтыган (башталганда алар сактагычтарга жүктөлөт).
• Сырсөздү түзүү, табуу жана үзгүлтүксүз табуу көйгөйлөрү илгичтердин жардамы менен чечилди.
• Докер кутудан тышкары колдогон тегдердин аркасында стадияга жетишилет.
• Натыйжа көрсөткүчтөрдү колдонуу менен көзөмөлдөнөт, алар аркылуу биз статусту түшүнөбүз.

Бул бүт система Go'до бир бинардык формада ишке ашырылат, ал addon-operator деп аталат. Бул диаграмманы жөнөкөйлөтөт:

Бул диаграммада негизги компонент модулдардын жыйындысы болуп саналат (төмөндө боз түс менен белгиленген). Эми биз бир аз аракет менен керектүү кошумча модулун жаза алабыз жана ал ар бир кластерге орнотулуп, жаңыланып, кластерде керектүү окуяларга жооп берерине ишенсек болот.

"Flant" колдонот addon-operator 70+ Kubernetes кластеринде. Учурдагы абалы - альфа версиясы. Азыр биз бета версиясын чыгаруу үчүн документтерди даярдап жатабыз, бирок азыр репозиторийде мисалдар жеткиликтүү, анын негизинде сиз өзүңүздүн кошумча түзө аласыз.

Addon-operator модулдарын кайдан алсам болот? Биздин китепкананы басып чыгаруу биз үчүн кийинки этап болуп саналат, биз муну жайында жасайбыз;

Видеолор жана слайддар

Спектаклден видео (~50 мүнөт):

Докладдын презентациясы:

PS

Биздин блогдогу башка отчеттор:

• «Берилиштер базалары жана Kubernetes"; (Дмитрий Столяров; 8-жылдын 2018-ноябрында HighLoad++ боюнча);
• «Мониторинг жана Kubernetes"; (Дмитрий Столяров; 28-жылдын 2018-майы, RootConf сайтында);
• «Kubernetes жана GitLab менен CI/CD мыкты тажрыйбалары"; (Дмитрий Столяров; 7-жылдын 2017-ноябрында HighLoad++ боюнча);
• «Чакан долбоорлордо Kubernetes менен болгон тажрыйбабыз"; (Дмитрий Столяров; 6-жылдын 2017-июнунда RootConf сайтында).

Сизди төмөнкү басылмалар да кызыктырышы мүмкүн:

• «Shell-операторду тааныштыруу: Kubernetes үчүн операторлорду түзүү оңойлоду«.

Source: www.habr.com