🥇Kubernetes колдонуудагы 10 кеңири таралган каталар

Эскертүү. котормо.: Бул макаланын авторлору кичинекей чехиялык компаниянын инженерлери, pipetail. Алар Kubernetes кластерлеринин иштешине байланыштуу [кээде баналдык, бирок дагы деле] абдан актуалдуу көйгөйлөрдүн жана туура эмес түшүнүктөрдүн эң сонун тизмесин түзө алышты.

Kubernetesти колдонгон жылдар бою биз көп сандагы кластерлер менен иштедик (башкарылган жана башкарылбаган - GCP, AWS жана Azureде). Убакыттын өтүшү менен кээ бир каталар тынымсыз кайталанып жатканын байкай баштадык. Бирок, бул жерде эч кандай уят жок: алардын көбүн өзүбүз жасадык!

Макалада эң кеңири таралган каталар камтылган жана аларды кантип оңдоо керектиги айтылат.

1. Ресурстар: суроо-талаптар жана чектөөлөр

Бул нерсе эң жакын көңүл бурууга жана тизмедеги биринчи орунга татыктуу.

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

BestEffort (өтө жок сунушталат):

resources: {}

Өтө төмөн CPU талабы (өтө жок сунушталат):

   resources:
      Requests:
        cpu: "1m"

Башка жагынан алганда, CPU чегинин болушу түйүн процессору толук жүктөлбөсө дагы, саат циклдерин подъезддер тарабынан негизсиз өткөрүп жиберүүгө алып келиши мүмкүн. Дагы, бул кечигүүлөр көбөйүшүнө алып келиши мүмкүн. Параметрдин тегерегинде талаш-тартыш уланууда CPU CFS квотасы Linux өзөгүндө жана CPU белгиленген чектерге жараша тескөө, ошондой эле CFS квотасын өчүрүү... Тилекке каршы, CPU чектөөлөрү алар чече албагандан да көп көйгөйлөрдү жаратышы мүмкүн. Бул тууралуу кененирээк маалыматты төмөнкү шилтемеден тапса болот.

Ашыкча тандоо (ашыкча милдеттенме) эстутум көйгөйлөрү чоң көйгөйлөргө алып келиши мүмкүн. Процессордун чегине жетүү саат циклдерин өткөрүп жиберүүнү талап кылат, ал эми эстутум чегине жетүү поддонду өлтүрүүгө алып келет. Сиз байкадыңызбы OOMkill? Ооба, биз дал ушул жөнүндө айтып жатабыз.

Сиз мунун ыктымалдыгын азайткыңыз келеби? Эстутумду ашыкча бөлүштүрбөңүз жана эстутум суроо-талабын чекке коюу менен Кепилденген QoS (Кызматтын сапаты) колдонбоңуз (төмөндөгү мисалдагыдай). Бул тууралуу көбүрөөк окуңуз Henning Jacobs презентациялары (Заландодогу башкы инженер).

Burstable (OOMkilled алуу мүмкүнчүлүгү жогору):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

кепилденген:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

Ресурстарды орнотууда эмне жардам берет?

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

kubectl top pods
kubectl top pods --containers
kubectl top nodes

Бирок, алар учурдагы колдонууну гана көрсөтөт. Бул сизге чоңдук тартиби жөнүндө болжолдуу түшүнүк бере алат, бирок акыры сизге керек болот убакыттын өтүшү менен көрсөткүчтөрдүн өзгөрүү тарыхы (мисалы суроолорго жооп берүү үчүн: "Процессордун эң жогорку жүгү кандай болду?", "Кечээ эртең менен жүк кандай болду?" ж.б.). Бул үчүн сиз колдоно аласыз Prometheus, DataDog жана башка куралдар. Алар жөн гана метрика-серверден метрикаларды алышат жана аларды сакташат жана колдонуучу аларды сурап, ошого жараша графигин түзө алат.

VerticalPodAutoscaler Бул берет автоматташтыруу бул процесс. Ал CPU жана эстутумду колдонуу тарыхына көз салат жана бул маалыматтын негизинде жаңы суроо-талаптарды жана чектөөлөрдү орнотот.

Эсептөө күчүн натыйжалуу пайдалануу оңой иш эмес. Бул дайыма Тетрис ойногон сыяктуу. Эгер сиз орточо керектөө (мисалы, ~10%) менен эсептөө күчү үчүн өтө көп төлөп жатсаңыз, AWS Fargate же Virtual Kubelet негизиндеги өнүмдөрдү карап чыгууну сунуштайбыз. Алар серверсиз/колдонуу үчүн төлөө моделинде курулган, мындай шарттарда арзаныраак болушу мүмкүн.

2. Жандуулукту жана даярдыкты текшерүү

Демейки боюнча, Kubernetes'те жандуулукту жана даярдуулукту текшерүү иштетилген эмес. Кээде аларды күйгүзүүнү унутуп калышат...

Бирок ката кетирилген учурда кызматты кайра кантип баштоого болот? Жана жүктү тең салмактоочу подряд трафикти кабыл алууга даяр экенин кайдан билет? Же ал көбүрөөк трафикти көтөрө алабы?

Бул тесттер көп учурда бири-бири менен чаташтырылып жатат:

Жашоо — "жашоо жөндөмдүүлүгүн" текшерүү, ал иштебей калса, подкукту кайра иштетет;
даярдык — даярдыгын текшерүү, эгер ал ишке ашпай калса, подкукту Kubernetes кызматынан ажыратат (бул аркылуу текшерүүгө болот kubectl get endpoints) жана трафик кийинки текшерүү ийгиликтүү аяктаганга чейин ага келбейт.

Бул эки текшерүү ПОДОНУН БУТКУЛ ЖАШОО ЦИКЛИНДЕ АТКАРЫЛГАН. Бул өтө маанилүү.

Жалпы жаңылыштык - даярдык зонддору ишке киргенде гана иштетилет, андыктан баланстоочу поддондун даяр экенин билиши үчүн (Ready) жана трафикти иштетүүнү башташы мүмкүн. Бирок, бул аларды колдонуунун варианттарынын бири гана.

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

Ошондуктан, кээ бир учурларда, эч кандай текшерүү туура эмес конфигурацияланган параметрлер менен аларды иштетүүгө караганда жакшыраак. Жогоруда айтылгандай, эгерде liveness check copies даярдыгын текшерүү, анда сиз чоң кыйынчылыкка кабыласыз. Мүмкүн болгон параметр - конфигурациялоо даярдыгын текшерүү ганажана коркунучтуу жашоо четте калтыр.

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

3. Ар бир HTTP кызматы үчүн LoadBalancer

Кыязы, сиздин кластериңизде тышкы дүйнөгө жөнөткүңүз келген HTTP кызматтары бар.

Эгер сиз кызматты катары ачсаңыз type: LoadBalancer, анын контроллери (кызмат провайдерине жараша) тышкы LoadBalancerти (сөзсүз L7де иштебейт, тескерисинче L4де иштешет) камсыздайт жана сүйлөшөт жана бул баага таасир этиши мүмкүн (тышкы статикалык IPv4 дареги, эсептөө күчү, секундасына эсептешүү ) мындай ресурстарды коп санда тузуунун зарылдыгынан улам.

Бул учурда, бир тышкы жүк балансын колдонуу алда канча логикалык, ачуу кызматтары катары type: NodePort. Же дагы жакшыраак, бир нерсени кеңейтүү nginx-ingress-controller (же траефик), ким гана болот NodePort тышкы жүк баланстоочу менен байланышкан акыркы чекит жана кластердеги трафикти колдонуу менен багыттайт кирүү- Kubernetes ресурстары.

Бири-бири менен өз ара аракеттенген башка кластер ичиндеги (микро) кызматтар сыяктуу кызматтарды колдонуу менен "байланышууга" болот ClusterIP жана DNS аркылуу камтылган кызмат табуу механизми. Жөн гана алардын коомдук DNS/IP'ин колдонбоңуз, анткени бул күтүү убактысына таасирин тийгизип, булут кызматтарынын баасын жогорулатат.

4. Кластерди анын өзгөчөлүктөрүн эске албастан автомасштабдоо

Түйүндөрдү кошууда жана аларды кластерге алып салууда, ал түйүндөрдө CPU колдонулушу сыяктуу кээ бир негизги көрсөткүчтөргө ишенбешиңиз керек. Pod пландаштыруу көп эске алуу керек чектөөлөр, мисалы, поддон/түйүн жакындыгы, бузулуулар жана чыдамдуулук, ресурстук суроо-талаптар, QoS ж.б. Бул нюанстарды эске албаган тышкы автошкалаларды колдонуу көйгөйлөргө алып келиши мүмкүн.

Элестеткиле, белгилүү бир поддон пландаштырылышы керек, бирок бардык колдо болгон CPU кубаттуулугу талап кылынат/демонтаждалган жана подк абалда тыгылып калат Pending. Тышкы автошкалалоочу орточо учурдагы CPU жүгүн көрөт (суралган эмес) жана кеңейтүүнү баштабайт (кеңейтүү) - башка түйүн кошпойт. Натыйжада, бул подкаст пландаштырылган эмес.

Бул учурда, тескери масштабдоо (масштаб) — кластерден түйүндү алып салуу дайыма ишке ашыруу кыйыныраак. Элестетиңиз, сизде штаттык подключ бар (туруктуу сактагыч туташтырылган). Туруктуу томдор адатта таандык белгилүү бир жеткиликтүүлүк зонасы жана региондо кайталанбайт. Ошентип, эгерде тышкы автомасштабдоочу түйүндү бул подколь менен жок кылса, пландоочу бул подкукту башка түйүндө пландаштыра албайт, анткени муну туруктуу сактагыч жайгашкан жеткиликтүүлүк зонасында гана жасоого болот. Подго штатка тыгылып калат Pending.

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

5. IAM/RBAC мүмкүнчүлүктөрүнө көңүл бурбоо

үчүн туруктуу сырлары бар IAM колдонуучуларын колдонуудан сак болуңуз машиналар жана колдонмолор. Ролдорду жана кызмат эсептерин колдонуу менен убактылуу кирүүнү уюштуруңуз (кызмат эсептери).

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

kube2iam жөнүндө унутуп, түз эле кызмат эсептери үчүн IAM ролдоруна өтүңүз (бар ошол эле аталыштагы нота Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

Бир аннотация. Мынча кыйын эмес, туурабы?

Ошондой эле, кызмат эсептерине жана инстанция профилдерине артыкчылыктарды бербеңиз admin и cluster-adminэгерде аларга кереги жок болсо. Бул ишке ашыруу бир аз кыйыныраак, айрыкча RBAC K8s, бирок, албетте, күч-аракет жумшаш керек.

6. Кошумчалар үчүн автоматтык антифиндүүлүккө ишенбеңиз

Түйүндө кандайдыр бир жайгаштыруунун үч репликасы бар деп элестетиңиз. Түйүн түшөт, аны менен бирге бардык репликалар. Жагымсыз жагдай, туурабы? Бирок эмне үчүн бардык репликалар бир түйүндө болгон? Kubernetes жогорку жеткиликтүүлүктү (HA) камсыз кылышы керек эмеспи?!

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

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

Баары болду. Эми поддондор ар кандай түйүндөрдө пландаштырылат (бул шарт графиктөө учурунда гана текшерилет, бирок алардын иштөө учурунда эмес - демек, requiredDuringSchedulingIgnoredDuringExecution).

Бул жерде сөз болуп жатат podAntiAffinity ар кандай түйүндөр боюнча: topologyKey: "kubernetes.io/hostname", - жана ар кандай жеткиликтүү зоналар жөнүндө эмес. толук кандуу HA ишке ашыруу үчүн, бул теманы тереңирээк казып алууга туура келет.

7. PodDisruptionBudgets'ке көңүл бурбоо

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

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

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

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

Бул тууралуу кененирээк окуй аласыз бул жерде.

8. Жалпы кластерде бир нече колдонуучулар же чөйрөлөр

Kubernetes аттар мейкиндиктери (ат мейкиндиктери) күчтүү изоляцияны камсыз кылбаңыз.

Кеңири таралган жаңылыш түшүнүк, эгерде сиз бир аттар мейкиндигине өндүрүштүк эмес жүктү, экинчисине өндүрүштүк жүктү жайгаштырсаңыз, анда алар бири-бирине эч кандай таасир тийгизбейт... Бирок, обочолонуунун белгилүү бир деңгээлине ресурстук суроо-талаптар/чектөөлөр, квоталарды коюу жана priorityClasses коюу аркылуу жетишүүгө болот. Берилиштер тегиздигинде кээ бир “физикалык” изоляция жакындыктар, толерациялар, тактар (же түйүн тандагычтар) менен камсыз кылынат, бирок мындай бөлүү кыйла татаал ишке ашыруу.

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

9. тышкы TrafficPolicy: Кластер

Көп учурда биз кластердин ичиндеги бардык трафик демейки саясат коюлган NodePort сыяктуу кызмат аркылуу келгенин көрөбүз. externalTrafficPolicy: Cluster... Бул ошону билдирет NodePort кластердин ар бир түйүнүндө ачык жана сиз каалаган кызмат менен иштешүү үчүн алардын каалаганын колдоно аласыз (подтар топтому).

Ошол эле учурда, жогоруда аталган NodePort кызматы менен байланышкан чыныгы подколор, адатта, белгилүү бир жерде гана жеткиликтүү. бул түйүндөрдүн чакан жыйындысы. Башкача айтканда, эгер мен талап кылынган подкокко ээ эмес түйүнгө туташсам, ал трафикти башка түйүнгө багыттайт, хоп кошуу жана көбөйүп жаткан кечигүү (эгерде түйүндөр ар кандай жеткиликтүүлүк зоналарында/маалымат борборлорунда жайгашкан болсо, кечигүү кыйла жогору болушу мүмкүн; андан тышкары, чыгуу трафиктин чыгымдары көбөйөт).

Башка жагынан алганда, белгилүү бир Kubernetes кызматында саясат топтому болсо externalTrafficPolicy: Local, анда NodePort талап кылынган подъезддер иш жүзүндө иштеп жаткан түйүндөрдө гана ачылат. абалын текшерген тышкы жүк балансын колдонууда (ден соолукту текшерүү) акыркы чекиттер (бул кантип кылат AWS ELB), Ал трафикти керектүү түйүндөргө гана жөнөтөт, бул кечигүүлөргө, эсептөө муктаждыктарына, чыгуу эсептерине жакшы таасир этет (жана жалпы акыл-эс ушуну талап кылат).

Сиз буга окшогон нерсени колдонуп жатканыңызга чоң мүмкүнчүлүк бар траефик же nginx-ingress-controller HTTP кирүүчү трафикти багыттоо үчүн NodePort акыркы чекити (же LoadBalancer, ошондой эле NodePort колдонот) катары жана бул параметрди коюу мындай суроо-талаптар үчүн күтүү убактысын бир топ азайтышы мүмкүн.

В бул китеп Сиз externalTrafficPolicy, анын артыкчылыктары жана кемчиликтери тууралуу көбүрөөк биле аласыз.

10. Кластерлерге байланбаңыз жана башкаруу тегиздигине кыянаттык кылбаңыз

Мурда серверлерди тиешелүү аттар менен чакыруу салт болгон: Антон, HAL9000 жана Colossus... Бүгүнкү күндө алар туш келди түзүлгөн идентификаторлор менен алмаштырылды. Бирок, адат калып, азыр энчилүү аттар кластерлерге барат.

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

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

Башка жагынан алганда, сиз аны манипуляциялоо менен алек болбошуңуз керек. Убакыт өткөн сайын башкаруу катмары жай болушу мүмкүн. Кыязы, бул көп сандагы объекттердин айлануусуз түзүлүүсү менен шартталган ( Helmди демейки жөндөөлөр менен колдонууда кеңири таралган жагдай, ошондуктан анын конфигматикадагы/сырлардагы абалы жаңыртылган эмес - натыйжада миңдеген объекттер топтолот. башкаруу катмары) же kube-api объектилерин туруктуу редакциялоо менен (автоматтык масштабдоо үчүн, CI/CD үчүн, мониторинг үчүн, окуялар журналдары, контроллерлор ж.б.).

Андан тышкары, башкарылган Kubernetes провайдери менен SLA/SLO келишимдерин текшерүүнү жана кепилдиктерге көңүл бурууну сунуштайбыз. Сатуучу кепилдик бере алат катмардын жеткиликтүүлүгүн көзөмөлдөө (же анын субкомпоненттери), бирок сиз ага жөнөткөн суроо-талаптардын p99 кечигүүсү эмес. Башкача айтканда, сиз кире аласыз kubectl get nodes, жана 10 мүнөттөн кийин гана жооп аласыз, жана бул тейлөө келишиминин шарттарын бузуу болуп эсептелбейт.

11. Бонус: акыркы тэгди колдонуу

Бирок бул классикалык. Акыркы убакта биз бул ыкманы сейрек кездештирдик, анткени көптөр ачуу тажрыйбадан үйрөнүп, тегди колдонууну токтотушкан. :latest жана версияларын кадап баштады. Жашасын!

ККМ сүрөт тегтеринин өзгөрбөстүгүн сактайт; Бул кереметтүү өзгөчөлүк менен таанышууну сунуштайбыз.

на

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

Сиз ар кандай командалардын ийгиликсиз тажрыйбасы менен тааныша аласыз окуялардын бул жыйнагы Хеннинг Джейкобс тарабынан.

Бул макалада келтирилген каталардын тизмесине кошууну каалагандар биз менен Twitter аркылуу байланыша алышат (@MarekBartik, @MstrsObserver).

Котормочудан PS

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

«Kubernetes кластерлерин долбоорлоо: канча болушу керек?";
«Kubernetes коопсуздук ABC: аутентификация, авторизация, аудит";
«Kubernetes'те автомасштабтоо жана ресурстарды башкаруу"(кароо жана видео отчет);
«Kubernetesтеги ConfigMaps: билүүгө арзырлык нюанстар«.

Source: www.habr.com

Kubernetes колдонууда 10 жалпы каталар