Разширяване и допълване на Kubernetes (преглед и видео отчет)

8 април на конференцията Saint HighLoad++ 2019, като част от раздела „DevOps и операции“, беше изнесен доклад „Разширяване и допълване на Kubernetes“, в създаването на който участваха трима служители на компанията Flant. В него говорим за множество ситуации, в които искахме да разширим и допълним възможностите на Kubernetes, но за които не намерихме готово и просто решение. Имаме нужните решения под формата на Open Source проекти и тази реч също е посветена на тях.

По традиция имаме удоволствието да ви представим видео на репортажа (50 минути, много по-информативно от статията) и основното резюме в текстова форма. Отивам!

Ядро и допълнения в K8s

Kubernetes променя индустрията и подходите към администрирането, които са установени отдавна:

• Благодарение на него абстракции, вече не оперираме с концепции като настройка на конфигурация или изпълнение на команда (Chef, Ansible...), а използваме групиране на контейнери, услуги и т.н.
• Можем да подготвим приложения, без да мислим за нюансите на конкретен сайт, на който ще се стартира: bare metal, облак на някой от доставчиците и др.
• С K8s никога не сте били по-достъпни най-добри практики върху организирането на инфраструктура: техники за мащабиране, самолечение, толерантност към грешки и др.

Но, разбира се, не всичко е толкова гладко: Kubernetes също донесе своите нови предизвикателства.

Kubernetes не е комбайн, който решава всички проблеми на всички потребители. Ядрото Kubernetes отговаря само за набор от минимално необходими функции, които присъстват в всеки клъстер:

Ядрото на Kubernetes дефинира основен набор от примитиви за групиране на контейнери, управление на трафик и т.н. Говорихме за тях по-подробно в отчет преди 2 години.

От друга страна, K8s предлага големи възможности за разширяване на наличните функции, които помагат за затваряне на други - специфичен — потребителски нужди. Добавките към Kubernetes са отговорност на клъстерните администратори, които трябва да инсталират и конфигурират всичко необходимо, за да приведат своя клъстер „в правилната форма“ [за решаване на техните специфични проблеми]. Що за допълнения са това? Нека да разгледаме някои примери.

Примери за добавки

След като инсталирахме Kubernetes, може да се изненадаме, че мрежата, която е толкова необходима за взаимодействието на pods както в рамките на възел, така и между възли, не работи сама по себе си. Ядрото на Kubernetes не гарантира необходимите връзки; вместо това то определя мрежата интерфейс (CNI) за добавки на трети страни. Трябва да инсталираме една от тези добавки, която ще отговаря за конфигурацията на мрежата.

Близък пример са решенията за съхранение на данни (локален диск, мрежово блоково устройство, Ceph...). Първоначално те бяха в ядрото, но с появата CSI ситуацията се променя в нещо подобно на вече описаното: интерфейсът е в Kubernetes, а внедряването му е в модули на трети страни.

Други примери включват:

• Влизане-контролери (вижте прегледа им в скорошната ни статия).
• CERT-мениджър:

  

• оператори е цял клас добавки (който включва споменатия cert-manager), те дефинират примитив(и) и контролер(и). Логиката на тяхната работа е ограничена само от нашето въображение и ни позволява да превърнем готовите инфраструктурни компоненти (например СУБД) в примитиви, с които се работи много по-лесно (отколкото с набор от контейнери и техните настройки). Написани са огромен брой оператори - дори ако много от тях все още не са готови за производство, това е само въпрос на време:

  

• Метрика - още една илюстрация на това как Kubernetes раздели интерфейса (API на Metrics) от имплементацията (добавки на трети страни като Prometheus adapter, Datadog cluster agent...).
• За мониторинг и статистика, където на практика са необходими не само Прометей и Графана, но също и kube-state-metrics, node-exporter и др.

И това не е пълен списък с допълнения... Например във фирма Flant, която инсталираме в момента 29 добавки (всички от които създават общо 249 Kubernetes обекта). Просто казано, не можем да видим живота на един клъстер без добавки.

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

Операторите са предназначени да автоматизират рутинни операции, с които се сблъскваме всеки ден. Ето примери от реалния живот, за които писането на оператор би било отлично решение:

1. Има частен (т.е. изискващ влизане) регистър с изображения за приложението. Предполага се, че на всяка капсула е присвоена специална тайна, която позволява удостоверяване в регистъра. Нашата задача е да гарантираме, че тази тайна се намира в пространството на имената, така че подовете да могат да изтеглят изображения. Може да има много приложения (всяко от които се нуждае от тайна) и е полезно самите тайни да се актуализират редовно, така че опцията за ръчно излагане на тайни се елиминира. Тук на помощ идва операторът: създаваме контролер, който ще изчака да се появи пространството от имена и въз основа на това събитие ще добави тайна към пространството от имена.
2. Нека по подразбиране достъпът от pods до интернет е забранен. Но понякога може да се наложи: логично е механизмът за разрешение за достъп да работи просто, без да изисква специфични умения, например чрез наличието на определен етикет в пространството от имена. Как операторът може да ни помогне тук? Създава се контролер, който чака етикетът да се появи в пространството на имената и добавя подходящата политика за достъп до Интернет.
3. Подобна ситуация: да предположим, че трябва да добавим определен замърсяване, ако има подобен етикет (с някакъв вид префикс). Действията с оператора са очевидни...

Във всеки клъстер трябва да се решават рутинни задачи и правилно това може да стане с помощта на оператори.

Обобщавайки всички описани истории, стигнахме до извода, че за удобна работа в Kubernetes, от която се нуждаете: А) инсталирайте добавки, б) разработване на оператори (за решаване на ежедневни администраторски задачи).

Как да напиша изявление за Kubernetes?

Като цяло схемата е проста:

... но тогава се оказва, че:

• Kubernetes API е доста нетривиално нещо, което отнема много време за овладяване;
• програмирането също не е за всеки (езика Go беше избран като предпочитан език, защото има специална рамка за него - Оператор SDK);
• Подобна е ситуацията и със самата рамка.

В крайна сметка: да напиша контролер (оператор) трябва харчат значителни ресурси да изучава материал. Това би било оправдано за „големи“ оператори - да речем, за СУБД MySQL. Но ако си спомним примерите, описани по-горе (разгръщане на тайни, достъп до капсули до интернет...), които също искаме да направим правилно, тогава ще разберем, че изразходваните усилия ще надвишат резултата, от който се нуждаем сега:

Като цяло възниква дилема: похарчете много ресурси и намерете правилния инструмент за писане на отчети или го направете по старомодния начин (но бързо). За да го разрешим - да намерим компромис между тези крайности - създадохме наш собствен проект: shell-оператор (вижте също неговия скорошно съобщение на хъба).

Shell-оператор

Как работи той? Клъстерът има под, съдържащ Go двоичен файл с оператор на обвивка. До него има набор от кукички (повече подробности за тях - вижте по-долу). Самият шел-оператор се абонира за определени развитие в Kubernetes API, при възникването на което стартира съответните кукички.

Как операторът на обвивката знае кои кукички да извика при кои събития? Тази информация се предава на оператора на черупката от самите куки и те го правят много просто.

Хук е Bash скрипт или всеки друг изпълним файл, който приема един аргумент --config и отговаря с JSON. Последният определя кои обекти представляват интерес за него и на кои събития (за тези обекти) трябва да се отговори:

Ще илюстрирам имплементацията върху shell-оператора на един от нашите примери - декомпозиране на тайни за достъп до частен регистър с изображения на приложения. Състои се от два етапа.

Упражнение: 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-оператора - как да направите това? Самият shell-operator идва като 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 (и набор от правила) за куката.

Резултат - решихме проблема си роднини за Kubernetes по начин, който създава оператор за разлагане на тайни.

Други характеристики на shell-оператора

За да ограничите обектите от избрания от вас тип, с които куката ще работи, могат да се филтрират, избирайки според определени етикети (или използвайки matchExpressions):

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

При условие механизъм за дедупликация, който - с помощта на jq филтър - ви позволява да конвертирате големи JSON обекти в малки, където остават само онези параметри, които искаме да наблюдаваме за промени.

Когато се извика кука, операторът на обвивката я предава обектни данни, който може да се използва за всякакви нужди.

Събитията, които задействат кукички, не са ограничени до събития на Kubernetes: операторът на обвивката осигурява поддръжка за извикване на куки по време (подобно на crontab в традиционен планировчик), както и специално събитие onStartup. Всички тези събития могат да бъдат комбинирани и присвоени на една и съща кука.

И още две функции на shell-оператора:

1. Работи асинхронно. Тъй като е получено събитие на Kubernetes (като например създаване на обект), други събития (като изтриване на същия обект) може да са възникнали в клъстера и куките трябва да отчитат това. Ако куката е била изпълнена с грешка, тогава по подразбиране ще бъде припомням си до успешно завършване (това поведение може да бъде променено).
2. Изнася метрика за Prometheus, с който можете да разберете дали shell-операторът работи, да разберете броя на грешките за всяка кука и текущия размер на опашката.

За да обобщим тази част от доклада:

Инсталиране на добавки

За удобна работа с Kubernetes беше спомената и необходимостта от инсталиране на добавки. Ще ви разкажа за това, използвайки примера на пътя на нашата компания към това как го правим сега.

Започнахме да работим с Kubernetes с няколко клъстера, единственото допълнение към които беше Ingress. Трябваше да се инсталира по различен начин във всеки клъстер и ние направихме няколко YAML конфигурации за различни среди: гол метал, AWS...

Тъй като имаше повече клъстери, имаше повече конфигурации. Освен това подобрихме самите тези конфигурации, в резултат на което те станаха доста разнородни:

За да подредим всичко, започнахме със скрипт (install-ingress.sh), който взе като аргумент типа клъстер, към който ще внедрим, генерира необходимата конфигурация на YAML и я внедри в Kubernetes.

Накратко, по-нататъшният ни път и свързаните с него разсъждения бяха следните:

• за работа с YAML конфигурации е необходим шаблонен двигател (на първите етапи това е просто sed);
• с увеличаването на броя на клъстерите се появи необходимостта от автоматично актуализиране (най-ранното решение беше да поставите скрипта в Git, да го актуализирате с cron и да го стартирате);
• подобен скрипт беше необходим за Prometheus (install-prometheus.sh), но се отличава с факта, че изисква много повече входни данни, както и тяхното съхранение (в добрия смисъл - централизирано и в клъстер), а някои данни (пароли) могат да се генерират автоматично:

  

• рискът от внедряване на нещо нередно към нарастващ брой клъстери непрекъснато нарастваше, така че осъзнахме, че инсталаторите (т.е. два скрипта: за Ingress и Prometheus) необходима беше етапност (няколко клона в Git, няколко crons за актуализирането им в съответните: стабилни или тестови клъстери);
• с kubectl apply стана труден за работа, защото не е декларативен и може само да създава обекти, но не и да взема решения за техния статус/да ги изтрива;
• Липсваха ни някои функции, които изобщо не бяхме внедрили по това време:
  • пълен контрол върху резултата от актуализациите на клъстера,
  • автоматично определяне на някои параметри (вход за инсталационни скриптове) въз основа на данни, които могат да бъдат получени от клъстера (откриване),
  • неговото логично развитие под формата на непрекъснато откриване.

Целият този натрупан опит внедрихме в рамките на другия ни проект - addon-оператор.

Addon-оператор

Базиран е на вече споменатия shell-оператор. Цялата система изглежда така:

Следното се добавя към куките на shell-operator:

• съхранение на ценности,
• Диаграма на кормилото,
• компонент, който следи съхраняването на стойности и - в случай на някакви промени - моли Helm да превърти отново графиката.

Така можем да реагираме на събитие в Kubernetes, да стартираме кука и от тази кука да правим промени в хранилището, след което графиката ще бъде изтеглена отново. В получената диаграма разделяме набора от кукички и диаграмата в един компонент, който наричаме модул:

Може да има много модули и към тях добавяме глобални кукички, глобално хранилище за стойности и компонент, който наблюдава това глобално хранилище.

Сега, когато нещо се случи в Kubernetes, можем да реагираме на това с помощта на глобална кука и да променим нещо в глобалния магазин. Тази промяна ще бъде забелязана и ще доведе до внедряване на всички модули в клъстера:

Тази схема отговаря на всички изисквания за инсталиране на добавки, посочени по-горе:

• Helm отговаря за шаблоните и декларативността.
• Проблемът с автоматичното актуализиране беше решен с помощта на глобална кука, която отива в регистъра по график и, ако види ново системно изображение там, го пуска (т.е. „само себе си“).
• Съхраняването на настройките в клъстера се осъществява с помощта на ConfigMap, който съдържа първичните данни за хранилищата (при стартиране те се зареждат в хранилищата).
• Проблемите с генерирането на парола, откриването и непрекъснатото откриване бяха решени с помощта на куки.
• Етапирането се постига благодарение на тагове, които Docker поддържа от кутията.
• Резултатът се следи с помощта на метрики, чрез които можем да разберем състоянието.

Цялата тази система е внедрена под формата на единичен двоичен файл в Go, който се нарича addon-operator. Това прави диаграмата по-проста:

Основният компонент в тази диаграма е набор от модули (маркирани в сиво по-долу). Сега можем да напишем модул за необходимата добавка с малко усилия и да сме сигурни, че той ще бъде инсталиран във всеки клъстер, ще се актуализира и ще отговаря на събитията, от които има нужда в клъстера.

"Flant" използва addon-оператор на 70+ Kubernetes клъстера. Актуално състояние - алфа версия. Сега подготвяме документация за пускане на бета версията, но засега в хранилището налични примери, въз основа на които можете да създадете свой собствен адон.

Къде мога да взема модулите за addon-operator? Издаването на нашата библиотека е следващият етап за нас, планираме да го направим през лятото.

Видеоклипове и слайдове

Видео от представлението (~50 минути):

Представяне на доклада:

PS

Други доклади в нашия блог:

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

Може да се интересувате и от следните публикации:

• «Представяме ви shell-operator: създаването на оператори за Kubernetes току-що стана по-лесно".

Източник: www.habr.com