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

Биздин блогубузда буга чейин сөз болгон макалалар бар Kubernetes операторунун мүмкүнчүлүктөрү жана кантип жөнөкөй операторду өзүң жаз. Бул жолу биз сиздердин назарыңыздарга Операторлорду түзүүнү өтө жеңил деңгээлге жеткирген Open Source чечимибизди сунуштайбыз - текшерип көрүңүз шел-оператор!

Эмне үчүн?

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

Кластерлердин иштешинин жүрүшүндө биз чындап эле туура жол менен автоматташтырууну каалаган кичинекей тапшырмалар пайда боло баштаганда, анын зарылдыгы пайда болду. Бул кичинекей тапшырмалардын баары жөнөкөй bash скрипттеринин жардамы менен чечилген, бирок сиз билгендей, Голангда операторлорду жазуу жакшы. Албетте, ар бир мындай кичинекей тапшырма үчүн операторду толук масштабдуу өнүктүрүүгө инвестиция салуу натыйжасыз болот.

Оператор 15 мүнөттө

Келгиле, Kubernetes кластеринде эмнени автоматташтырууга болорун жана шел-оператор кантип жардам бере аларын мисалга карап көрөлү. Төмөнкү мисал боло алат: докер реестрине кирүү үчүн сырды репликациялоо.

Жеке реестрдеги сүрөттөрдү колдонгон подколор манифестте реестрге кирүү үчүн маалыматтар менен сырга шилтемени камтышы керек. Бул сырды ар бир аттар мейкиндигинде түзүш керек. Муну кол менен жасоого болот, бирок биз динамикалык чөйрөлөрдү орнотсок, анда бир тиркеме үчүн аттар мейкиндиги көп болуп калат. Ошондой эле 2-3 арыз жок болсо... сырлардын саны абдан чоң болуп калат. Жана сырлар жөнүндө дагы бир нерсе: мен реестрге кирүү үчүн ачкычты мезгил-мезгили менен өзгөрткүм келет. Жыйынтыгында, кол операциялары чечим катары толугу менен натыйжасыз — сырларды тузууну жана жанылоону автоматташтыруу керек.

Жөнөкөй автоматташтыруу

Келгиле, N секунд сайын бир жолу иштей турган жана аттар мейкиндигинде сырдын бар-жоктугун текшерген кабык сценарийин жазалы, эгер сыр жок болсо, анда ал түзүлөт. Бул чечимдин артыкчылыгы - бул cronдогу кабык скриптине окшош - классикалык жана баарына түшүнүктүү мамиле. Кемчилиги, анын ишке киришинин ортосундагы аралыкта жаңы аттар мейкиндиги түзүлүшү мүмкүн жана ал бир нече убакытка чейин сырсыз кала берет, бул поддондорду ишке киргизүүдө каталарга алып келет.

Шелл-оператор менен автоматташтыруу

Скриптибиздин туура иштеши үчүн классикалык cron ишке киргизүү аттар мейкиндиги кошулганда ишке киргизүү менен алмаштырылышы керек: бул учурда аны колдонуудан мурун сыр түзө аласыз. Келгиле, муну shell-operator аркылуу кантип ишке ашырууну карап көрөлү.

Биринчиден, сценарийди карап көрөлү. Shell-оператор терминдериндеги скрипттер илгичтер деп аталат. Желек менен чуркаганда ар бир илмек --config шелл-операторго анын байланыштары жөнүндө маалымдайт, б.а. кандай окуялар боюнча ишке киргизүү керек. Биздин учурда биз колдонобуз onKubernetesEvent:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
cat <<EOF
{
"onKubernetesEvent": [
  { "kind": "namespace",
    "event":["add"]
  }
]}
EOF
fi

Бул жерде биз окуяларды кошууга кызыкдар экендиги сүрөттөлгөн (add) типтеги объекттер namespace.

Эми сиз окуя болгондо аткарыла турган кодду кошушуңуз керек:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
  # конфигурация
cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "namespace",
  "event":["add"]
}
]}
EOF
else
  # реакция:
  # узнать, какой namespace появился
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  # создать в нём нужный секрет
  kubectl create -n ${createdNamespace} -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
EOF
fi

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

Илмек менен сүрөт даярдоо

Сценарийди карасаңыз, буйруктар колдонулганын көрө аласыз kubectl и jq. Бул сүрөттөлүштө төмөнкү нерселер болушу керек дегенди билдирет: биздин илгичибиз, окуяларды угуп, илгичти иштете турган шел-оператор жана илгич колдонгон буйруктар (kubectl жана jq). Hub.docker.com сайтында мурунтан эле кабык оператору, kubectl жана jq пакеттелген даяр сүрөт бар. Жөнөкөй илгичти кошуу гана калды Dockerfile:

$ cat Dockerfile
FROM flant/shell-operator:v1.0.0-beta.1-alpine3.9
ADD namespace-hook.sh /hooks

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

Кластерде чуркоо

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

1. аттар мейкиндигин түзүү окуяларына жазылат;
2. ал ишке киргизилгенден башка аттар мейкиндигинде сырды түзөт.

Көрсө, биздин сүрөт ишке киргизиле турган поддон бул аракеттерди жасоого уруксат алышы керек. Бул өзүңүздүн ServiceAccount түзүү аркылуу жасалышы мүмкүн. Уруксат ClusterRole жана ClusterRoleBinding түрүндө жасалышы керек, анткени биз бүткүл кластердеги объекттерге кызыгып жатабыз.

YAMLдеги акыркы сүрөттөмө төмөнкүдөй болот:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitor-namespaces-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: monitor-namespaces
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: monitor-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: monitor-namespaces
subjects:
  - kind: ServiceAccount
    name: monitor-namespaces-acc
    namespace: example-monitor-namespaces

Сиз чогултулган сүрөттү жөнөкөй Жайгаштыруу катары ишке киргизсеңиз болот:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1
      serviceAccountName: monitor-namespaces-acc

Ыңгайлуу болуу үчүн өзүнчө аттар мейкиндиги түзүлөт, анда shell-оператор ишке киргизилет жана түзүлгөн манифесттер колдонулат:

$ kubectl create ns example-monitor-namespaces
$ kubectl -n example-monitor-namespaces apply -f rbac.yaml
$ kubectl -n example-monitor-namespaces apply -f deployment.yaml

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

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

Бул маселе боюнча дагы бир мисал бар ...

Анын маанисин кийинки басылмалардын биринде кененирээк ачып беребиз.

Чыпкалоо

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

Окуя келгенде, shell-оператор объекттин JSON манифестин алат. Биз бул JSONда бизди кызыктырган касиеттерди тандап, илгичти иштете алабыз гана алар өзгөргөндө. Бул үчүн талаа бар jqFilter, бул жерде JSON манифестине колдонула турган jq туюнтмасын көрсөтүшүңүз керек.

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

cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "deployment",
  "event":["update"],
  "jqFilter": ".metadata.labels"
}
]}
EOF

Бул jqFilter туюнтмасы Deployment'тин узун JSON манифестин энбелгилери бар кыска JSONга айлантат:

shell-operator бул кыска JSON өзгөргөндө гана илгичти иштетет жана башка касиеттерге өзгөртүүлөр этибарга алынбайт.

Hook ишке киргизүү контексти

Илгич конфигурациясы окуялардын бир нече варианттарын көрсөтүүгө мүмкүндүк берет - мисалы, Kubernetes окуяларынын 2 варианты жана 2 графиги:

{"onKubernetesEvent":[
  {"name":"OnCreatePod",
  "kind": "pod",
  "event":["add"]
  },
  {"name":"OnModifiedNamespace",
  "kind": "namespace",
  "event":["update"],
  "jqFilter": ".metadata.labels"
  }
],
"schedule": [
{ "name":"every 10 min",
  "crontab":"* */10 * * * *"
}, {"name":"on Mondays at 12:10",
"crontab": "* 10 12 * * 1"
]}

Кичинекей чегинүү: ооба, снаряд оператору колдойт crontab стилиндеги скрипттерди иштетүү. Кененирээк маалымат менен таанышууга болот документтер.

Илгичтин эмне үчүн ишке киргизилгендигин аныктоо үчүн, shell-оператор убактылуу файлды түзүп, ага жолду кайырмакка өзгөрмө аркылуу өткөрүп берет. BINDING_CONTEXT_TYPE. Файлда илгичти иштетүүнүн себебинин JSON сүрөттөмөсү бар. Мисалы, ар бир 10 мүнөт сайын илгич төмөнкү мазмун менен иштейт:

[{ "binding": "every 10 min"}]

... жана дүйшөмбү күнү бул менен башталат:

[{ "binding": "every 10 min"}, { "binding": "on Mondays at 12:10"}]

үчүн onKubernetesEvent JSON триггерлери көбүрөөк болот, анткени ал объекттин сүрөттөлүшүн камтыйт:

[
 {
 "binding": "onCreatePod",
 "resourceEvent": "add",
 "resourceKind": "pod",
 "resourceName": "foo",
 "resourceNamespace": "bar"
 }
]

Талаалардын мазмунун алардын аттарынан түшүнсө болот, жана андан көбүрөөк маалымат окуса болот документтер. Талаадан ресурстун аталышын алуунун мисалы resourceName jq колдонуу мурунтан эле сырларды кайталаган илгичте көрсөтүлгөн:

jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH

Ушундай эле жол менен башка талааларды ала аласыз.

Кийинкиси эмне?

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

Prometheus аркылуу метрикаларды чогултуу үчүн колдоо бар - жеткиликтүү көрсөткүчтөр бөлүмдө сүрөттөлгөн МЕТРИКА.

Сиз ойлогондой, shell-оператор Go программасында жазылган жана Open Source лицензиясынын (Apache 2.0) астында таратылган. Өнүктүрүү жардамына ыраазы болобуз GitHub боюнча долбоор: жана жылдыздар, жана маселелер, жана тартуу өтүнүчтөрү.

Жашыруун парданы алып, биз снаряд-оператор экенин да билдиребиз кичине Кубернетес кластеринде орнотулган кошумчаларды жаңыртып, ар кандай автоматтык аракеттерди аткара турган тутумубуздун бир бөлүгү. Бул система жөнүндө көбүрөөк оку айтып түзмө-түз дүйшөмбү күнү HighLoad++ 2019 Санкт-Петербургда - биз жакында бул отчеттун видеосун жана стенограммасын жарыялайбыз.

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

Тууганичкаларым!

PS

Биздин блогдон дагы окуңуз:

• «Kubernetes үчүн операторлор: мамлекеттик тиркемелерди кантип иштетүү керек";
• «Голангдагы Kubernetes үчүн оператор жазуу";
• «Grafana үчүн жаңы плагинди киргизүү - Statusmap панели";
• «Loghouse менен таанышуу - Kubernetes'те журналдар менен иштөө үчүн ачык булак системасы";
• «Биз расмий түрдө dappти сунуштайбыз - CI/CDди тейлөө үчүн DevOps утилитасы«.

Source: www.habr.com