🥇Кубернетесті кеңейту және толықтыру (шолу және бейне есеп)

8 сәуірде конференцияда Saint HighLoad++ 2019, «DevOps және операциялар» бөлімінің бөлігі ретінде «Kubernetes кеңейту және толықтыру» баяндамасы берілді, оны құруға Flant компаниясының үш қызметкері қатысты. Онда біз Kubernetes мүмкіндіктерін кеңейтіп, толықтырғымыз келген, бірақ біз дайын және қарапайым шешім таба алмаған көптеген жағдайлар туралы айтамыз. Бізде Open Source жобалары түріндегі қажетті шешімдер бар және бұл сөз де соларға арналған.

Дәстүр бойынша біз қуана ұсынамыз есептің видеосы (50 минут, мақаладан әлдеқайда ақпараттылығы бар) және мәтін түріндегі негізгі түйіндеме. Бар!

K8-дегі негізгі және толықтырулар

Кубернетес бұрыннан қалыптасқан индустрия мен басқару тәсілдерін өзгертеді:

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

Дегенмен, әрине, бәрі соншалықты тегіс емес: Кубернетес өзінің жаңа қиындықтарын да әкелді.

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

Кубернетес өзегі контейнерлерді топтастыруға, трафикті басқаруға және т.б. үшін примитивтердің негізгі жинағын анықтайды. Біз олар туралы толығырақ әңгімелестік 2 жыл бұрын есеп.

Екінші жағынан, K8s басқаларды жабуға көмектесетін қол жетімді функцияларды кеңейту үшін үлкен мүмкіндіктер ұсынады - нақты — пайдаланушы қажеттіліктері. Kubernetes-ке толықтырулар кластер әкімшілерінің жауапкершілігі болып табылады, олар кластерін «дұрыс пішінде» [арнайы мәселелерін шешу үшін] алу үшін қажеттінің бәрін орнатуы және конфигурациялауы керек. Бұл қандай толықтырулар? Кейбір мысалдарды қарастырайық.

Қосымшалардың мысалдары

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

Жақын мысал - деректерді сақтау шешімдері (жергілікті диск, желілік блок құрылғысы, Ceph...). Бастапқыда олар өзегінде болды, бірақ пайда болуымен CSI жағдай бұрын сипатталғанға ұқсас нәрсеге өзгереді: интерфейс Kubernetes-те, ал оның орындалуы үшінші тарап модульдерінде.

Басқа мысалдарға мыналар жатады:

Кіріс- контроллер (олардың шолуын қараңыз біздің соңғы мақаламыз).
сертификат-менеджер:
Операторлар қондырмалардың тұтас класы (оған аталған сертификат-менеджер кіреді), олар қарабайыр(лар) мен контроллер(лар)ды анықтайды. Олардың жұмысының логикасы тек біздің қиялымызбен шектеледі және дайын инфрақұрылымдық құрамдастарды (мысалы, ДҚБЖ) қарапайым құралдарға айналдыруға мүмкіндік береді, олармен жұмыс істеу әлдеқайда оңай (контейнерлер жиынтығымен және олардың параметрлерімен салыстырғанда). Көптеген операторлар жазылды - олардың көпшілігі әлі өндіріске дайын болмаса да, бұл уақыт мәселесі:
Көрсеткіштер - Кубернетес интерфейсті (Metrics API) іске асырудан қалай бөлгенінің тағы бір суреті (Prometheus адаптері, Datadog кластер агенті сияқты үшінші тарап қондырмалары...).
үшін мониторинг және статистика, мұнда іс жүзінде қажет емес Прометей және Графана, сонымен қатар kube-state-meterics, node-exporter, т.б.

Және бұл толықтырулардың толық тізімі емес... Мысалы, біз қазір Флант компаниясында орнатып жатырмыз 29 толықтыру (олардың барлығы барлығы 249 Kubernetes нысанын жасайды). Қарапайым тілмен айтқанда, біз кластердің өмірін толықтыруларсыз көре алмаймыз.

Автоматтандыру

Операторлар біз күнделікті кездесетін күнделікті операцияларды автоматтандыруға арналған. Мұнда операторды жазу тамаша шешім болатын нақты мысалдар берілген:

Қолданбаға арналған суреттері бар жеке (яғни кіруді қажет ететін) тізілім бар. Әрбір подводқа тізілімде аутентификацияға мүмкіндік беретін арнайы құпия тағайындалады деп болжанады. Біздің міндетіміз - бұл құпияның аттар кеңістігінде табылуын қамтамасыз ету, осылайша подкасттар кескіндерді жүктей алады. Қолданбалар көп болуы мүмкін (олардың әрқайсысы құпияны қажет етеді) және құпияларды үнемі жаңартып отыру пайдалы, сондықтан құпияларды қолмен орналастыру мүмкіндігі жойылады. Бұл жерде оператор көмекке келеді: біз аттар кеңістігінің пайда болуын күтетін және осы оқиғаның негізінде аттар кеңістігіне құпияны қосатын контроллерді жасаймыз.
Әдепкі бойынша подкасттардан Интернетке кіруге тыйым салынады. Бірақ кейде бұл талап етілуі мүмкін: қол жеткізуге рұқсат беру механизмінің нақты дағдыларды қажет етпей, мысалы, аттар кеңістігінде белгілі бір белгінің болуы арқылы қарапайым жұмыс істеуі қисынды. Оператор бізге мұнда қалай көмектесе алады? Жапсырманың аттар кеңістігінде пайда болуын күтетін және Интернетке кіру үшін сәйкес саясатты қосатын контроллер жасалады.
Ұқсас жағдай: белгілі бір қосу керек делік Мұз дәмі, егер оның ұқсас белгісі болса (бір түрдегі префикспен). Оператормен әрекеттері анық...

Кез келген кластерде күнделікті тапсырмалар шешілуі керек және құқық мұны операторлар арқылы жасауға болады.

Барлық сипатталған оқиғаларды қорытындылай келе, біз мынадай қорытындыға келдік Kubernetes-те ыңғайлы жұмыс үшін сізге қажет: A) қондырмаларды орнату, б) операторларды дамыту (күнделікті әкімші тапсырмаларын шешу үшін).

Кубернетес үшін мәлімдемені қалай жазуға болады?

Жалпы алғанда, схема қарапайым:

... бірақ содан кейін былай шығады:

Kubernetes API - бұл тривиальды емес нәрсе, оны игеруге көп уақыт кетеді;
бағдарламалау да барлығына жарамайды (Go тілі таңдаулы тіл ретінде таңдалды, өйткені ол үшін арнайы негіз бар - SDK операторы);
Жағдай рамканың өзіне ұқсас.

Астыңғы сызық: контроллерді жазу (оператор) міндетті қомақты ресурстарды жұмсайды материалды оқу. Бұл «үлкен» операторлар үшін, айталық, MySQL ДҚБЖ үшін ақталған болар еді. Бірақ біз жоғарыда сипатталған мысалдарды (құпияларды ашу, Интернетке кіру ...) еске түсірсек, біз де дұрыс жасағымыз келеді, онда жұмсалған күш қазір бізге қажет нәтижеден асып түсетінін түсінеміз:

Жалпы, дилемма туындайды: көп ресурстарды жұмсаңыз және мәлімдеме жазу үшін дұрыс құралды табыңыз немесе оны ескі әдіспен жасаңыз (бірақ тез). Оны шешу үшін - осы шектен шыққан ымыраға келу үшін - біз өз жобамызды жасадық: қабық операторы (сонымен қатар оның соңғы хабарландыру хабта).

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

Назар аударатын екі тармақ бар:

жаңадан жасалған бейнені көрсету;
Бұл (кем дегенде) Kubernetes ішіндегі оқиғаларға жазылу және аттар кеңістігіне құпияларды бөлу құқықтарын қажет ететін жүйе құрамдас бөлігі, сондықтан біз ілмек үшін ServiceAccount (және ережелер жинағын) жасаймыз.

Нәтиже – мәселемізді шештік туысқандар Кубернетес үшін құпияларды ыдырату операторын жасайтын жолмен.

Басқа қабық операторының мүмкіндіктері

Ілмек жұмыс істейтін таңдалған түрдегі нысандарды шектеу үшін, оларды сүзуге болады, белгілі бір белгілерге сәйкес таңдау (немесе пайдалану matchExpressions):

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

Берілген дедупликация механизмі, ол - jq сүзгісін пайдалану - үлкен JSON нысандарын кішігірім нысандарға түрлендіруге мүмкіндік береді, мұнда өзгерістерді бақылағымыз келетін параметрлер ғана қалады.

Ілмекті шақырғанда, қабықша операторы оны өткізеді объектінің деректері, оны кез келген қажеттілік үшін пайдалануға болады.

Ілмектерді тудыратын оқиғалар тек Кубернетес оқиғаларымен шектелмейді: қабық операторы қолдау көрсетеді. ілмектерді уақыт бойынша шақыру (дәстүрлі жоспарлаушыдағы crontab-ға ұқсас), сондай-ақ арнайы оқиға onStartup. Осы оқиғалардың барлығын біріктіріп, бір ілмекке тағайындауға болады.

Шелл-оператордың тағы екі мүмкіндігі:

Ол жұмыс істейді асинхронды түрде. Kubernetes оқиғасы (мысалы, жасалып жатқан нысан) алынғандықтан, кластерде басқа оқиғалар (жойылған бір нысан сияқты) орын алуы мүмкін және ілгектер мұны есепке алуы керек. Егер ілмек қатемен орындалса, әдепкі бойынша ол солай болады қайта қоңырау шалу сәтті аяқталғанға дейін (бұл әрекетті өзгертуге болады).
Экспорттайды көрсеткіштер Прометей үшін, оның көмегімен сіз қабықша-оператордың жұмыс істеп тұрғанын түсінуге болады, әр ілмек үшін қателер санын және ағымдағы кезек өлшемін біліңіз.

Есептің осы бөлігін қорытындылау үшін:

Қосымшаларды орнату

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

Біз Kubernetes-пен бірнеше кластерлермен жұмыс істей бастадық, олардың жалғыз қосымшасы Ingress болды. Оны әр кластерде басқаша орнату қажет болды және біз әртүрлі орталар үшін бірнеше YAML конфигурацияларын жасадық: жалаңаш металл, AWS...

Кластерлер көп болғандықтан, конфигурациялар да көп болды. Сонымен қатар, біз бұл конфигурацияларды өздері жетілдірдік, нәтижесінде олар біршама гетерогенді болды:

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

Қысқасы, біздің ары қарайғы жолымыз және оған байланысты пайымдауларымыз мынадай болды:

YAML конфигурацияларымен жұмыс істеу үшін үлгі қозғалтқышы қажет (алғашқы кезеңде бұл қарапайым sed);
кластерлер санының ұлғаюымен автоматты жаңарту қажеттілігі туындады (ең ерте шешім сценарийді Git-ке қою, оны cron арқылы жаңарту және оны іске қосу болды);
Прометейге де ұқсас сценарий қажет болды (install-prometheus.sh), дегенмен, ол әлдеқайда көп енгізу деректерін, сондай-ақ оларды сақтауды (жақсы түрде - орталықтандырылған және кластерде) қажет ететіндігімен ерекшеленеді және кейбір деректер (парольдер) автоматты түрде жасалуы мүмкін:
өсіп келе жатқан кластерлер санына дұрыс емес нәрсені шығару қаупі үнемі өсіп отырды, сондықтан біз орнатушылардың (яғни екі сценарий: Ингресс және Прометей үшін) сахналау қажет болды (Git-те бірнеше филиалдар, оларды сәйкесінше жаңарту үшін бірнеше крондар: тұрақты немесе сынақ кластерлері);
с kubectl apply онымен жұмыс істеу қиын болды, себебі ол декларативті емес және тек объектілерді жасай алады, бірақ олардың мәртебесі туралы шешім қабылдамайды/оларды жоя алмайды;
Бізде сол кезде мүлде іске асырмаған кейбір функциялар жетіспеді:
- кластерді жаңарту нәтижесін толық бақылау,
- кластерден алуға болатын деректер негізінде кейбір параметрлерді (орнату сценарийлеріне енгізу) автоматты түрде анықтау (ашу),
- оның үздіксіз ашылу түріндегі логикалық дамуы.

Осы жинақталған тәжірибенің барлығын біз басқа жобамыз аясында іске асырдық - қосымша операторы.

Қосымша оператор

Ол қазірдің өзінде аталған қабықша операторына негізделген. Бүкіл жүйе келесідей көрінеді:

Қабық операторының ілмектеріне келесілер қосылады:

құндылықтарды сақтау,
Руль диаграммасы,
құрамдас құндылықтар қоймасын бақылайды және - кез келген өзгерістер болған жағдайда - Хельмден диаграмманы қайта айналдыруды сұрайды.

Осылайша, біз Kubernetes-тегі оқиғаға әрекет ете аламыз, ілмекті іске қоса аламыз және осы ілмектен жадқа өзгертулер енгізе аламыз, содан кейін диаграмма қайта жүктеледі. Алынған диаграммада біз ілмектердің жиынтығын және диаграмманы бір құрамдас бөлікке бөлеміз, оны біз шақырамыз модуль:

Көптеген модульдер болуы мүмкін және оларға біз жаһандық ілмектерді, жаһандық құндылықтар қоймасын және осы жаһандық дүкенді бақылайтын компонентті қосамыз.

Енді Kubernetes-те бірдеңе болған кезде, біз оған жаһандық ілмек арқылы әрекет ете аламыз және ғаламдық дүкенде бір нәрсені өзгерте аламыз. Бұл өзгеріс байқалады және кластердегі барлық модульдердің шығарылуына әкеледі:

Бұл схема жоғарыда айтылған қондырмаларды орнатуға қойылатын барлық талаптарды қанағаттандырады:

Helm шаблондық және декларативтілік үшін жауап береді.
Автоматты жаңарту мәселесі кесте бойынша тізілімге түсетін жаһандық ілмектің көмегімен шешілді және егер ол жаңа жүйе кескінін көрсе, оны шығарады (яғни, «өзі»).
Кластерде параметрлерді сақтау арқылы жүзеге асырылады ConfigMap, ол қоймаларға арналған бастапқы деректерді қамтиды (іске қосу кезінде олар қоймаларға жүктеледі).
Құпия сөзді генерациялау, табу және үздіксіз табу мәселелері ілмектердің көмегімен шешілді.
Кезеңге Docker қораптан тыс қолдайтын тегтердің арқасында қол жеткізіледі.
Нәтиже күйді түсінуге болатын көрсеткіштер арқылы бақыланады.

Бұл бүкіл жүйе Go бағдарламасында addon-operator деп аталатын жалғыз екілік түрінде жүзеге асырылады. Бұл диаграмманы қарапайым етеді:

Бұл диаграммадағы негізгі компонент модульдер жиынтығы болып табылады (төменде сұр түспен белгіленген). Енді біз аздап күш жұмсап, қажетті қондырмаға модуль жаза аламыз және оның әрбір кластерде орнатылатынына, жаңартылатынына және кластердегі қажетті оқиғаларға жауап беретініне сенімді бола аламыз.

«Flant» пайдаланады қосымша операторы 70+ Kubernetes кластерінде. Ағымдағы күй - альфа нұсқасы. Қазір біз бета нұсқасын шығару үшін құжаттаманы дайындап жатырмыз, бірақ қазір репозиторийде мысалдар қол жетімді, оның негізінде сіз өзіңіздің қондырмаңызды жасай аласыз.

Addon-operator модульдерін қайдан алуға болады? Кітапхананы басып шығару біз үшін келесі кезең, біз мұны жазда жасауды жоспарлап отырмыз.

Бейнелер мен слайдтар

Спектакльден бейне (~50 минут):

Баяндаманы көрсету:

PS

Біздің блогтағы басқа есептер:

«Мәліметтер базасы және Кубернет«; (Дмитрий Столяров; 8 жылғы 2018 қарашада HighLoad++);
«Мониторинг және Kubernetes«; (Дмитрий Столяров; 28 жылғы 2018 мамырда RootConf сайтында);
«Kubernetes және GitLab көмегімен CI/CD үздік тәжірибелері«; (Дмитрий Столяров; 7 жылғы 2017 қарашада HighLoad++);
«Біздің Кубернетеспен шағын жобалардағы тәжірибеміз«; (Дмитрий Столяров; 6 жылғы 2017 маусымда RootConf сайтында).

Сізді келесі жарияланымдар қызықтыруы мүмкін:

«Shell-оператормен таныстыру: Kubernetes үшін операторларды жасау оңайырақ болды«.

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

Kubernetes кеңейту және толықтыру (шолу және бейне есеп)