Kubernetes-ийн өсөн нэмэгдэж буй алдар нэрийн тухай

Хөөе Хабр!

Зуны төгсгөлд бид энэ сэдвээр үргэлжлүүлэн ажиллахаа сануулахыг хүсч байна Kubernetes XNUMX-р сарын эхээр Stackoverflow-аас энэ төслийн нөхцөл байдлыг харуулсан нийтлэлийг нийтлэхээр шийджээ.

Уншаад үзээрэй!

Энэ нийтлэлийг бичиж байх үед Кубернетесийн нас ойролцоогоор байна. зургаан настай, мөн сүүлийн хоёр жилийн хугацаанд түүний алдар нэр нь маш их өссөн тул байнга жагсаж байна хамгийн дуртай платформууд. Кубернетес энэ жил гуравдугаарт бичигдэж байна. Товчхондоо: Кубернетес бол чингэлэгтэй ачааллыг ажиллуулах, зохицуулахад зориулагдсан платформ юм.

Контейнер нь Линукс дахь процессуудыг тусгаарлах тусгай загвар болж эхэлсэн; савыг 2007 оноос хойш оруулж ирсэн бүлэг, 2002 оноос хойш - нэрийн орон зай. 2008 он гэхэд савнууд бэлэн болсон үед бүр илүү сайн хийгдсэн LXC, мөн Google нь өөрийн байгууллагын дотоод механизмыг боловсруулсан Борг, "бүх ажлыг саванд хийдэг." Эндээс бид 2013 он хүртэл урагшилсаар, Docker-ийн анхны хувилбар гарч, контейнерууд эцэст нь түгээмэл шийдэл болсон. Тэр үед чингэлэг найрал хөгжмийн гол хэрэгсэл байсан Мезос, тэр тийм ч алдартай биш байсан ч. Kubernetes нь 2015 онд анх худалдаанд гарсан бөгөөд дараа нь энэ хэрэгсэл нь чингэлэг найрал хөгжмийн салбарт де факто стандарт болсон.

Кубернетес яагаад ийм алдартай болохыг ойлгохын тулд хэд хэдэн асуултанд хариулахыг хичээцгээе. Хамгийн сүүлд хэзээ хөгжүүлэгчид программуудыг үйлдвэрлэлд хэрхэн нэвтрүүлэх талаар тохиролцож чадсан бэ? Хэрэгслийг хайрцагнаас нь гаргаж өгснөөр ашигладаг хэдэн хөгжүүлэгчийг та мэдэх вэ? Өнөөдөр програмууд хэрхэн ажилладагийг ойлгодоггүй үүлний админ хэр олон байна вэ? Бид энэ нийтлэлд эдгээр асуултын хариултыг авч үзэх болно.

YAML шиг дэд бүтэц

Хүүхэлдэйн тогооч, тогоочоос Кубернетес рүү шилжсэн дэлхийн хамгийн том өөрчлөлтүүдийн нэг нь "код шиг дэд бүтэц"-ээс "өгөгдлийн дэд бүтэц" рүү, тухайлбал YAML-д шилжих явдал байв. Pod, тохиргоо, байршуулсан жишээ, хэмжээ гэх мэт Кубернетес дэх бүх нөөцийг YAML файлд хялбархан тайлбарлаж болно. Жишээлбэл:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

Энэхүү харагдац нь DevOps эсвэл SRE мэргэжилтнүүдэд Python эсвэл Javascript зэрэг хэлээр код бичих шаардлагагүйгээр ажлын ачааллаа бүрэн илэрхийлэхэд хялбар болгодог.

Дэд бүтцийг өгөгдөл болгон зохион байгуулах бусад давуу талууд нь:

• GitOps эсвэл Git Operations Version Control. Энэ арга нь бүх Kubernetes YAML файлуудыг git репозиторуудад хадгалах боломжийг олгодог бөгөөд ингэснээр та өөрчлөлтийг яг хэзээ, хэн хийсэн, яг юу өөрчлөгдсөнийг хянах боломжтой. Энэ нь байгууллагын хэмжээнд үйл ажиллагааны ил тод байдлыг нэмэгдүүлж, тодорхой бус байдлыг арилгах замаар үйл ажиллагааны үр ашгийг дээшлүүлдэг. Үүний зэрэгцээ татах хүсэлтийг нэгтгэснээр Kubernetes нөөцөд автоматаар өөрчлөлт оруулах нь илүү хялбар болно.
• Өргөтгөх чадвар. Нөөцүүдийг YAML гэж тодорхойлсон тохиолдолд кластерын операторууд Кубернетес нөөцийн нэг эсвэл хоёр тоог өөрчлөхөд маш хялбар болж, ингэснээр түүний масштабыг өөрчлөх боломжтой болно. Kubernetes нь бага ба өндөр түвшний урсгалыг зохицуулахын тулд тодорхой байршуулалтын тохиргоонд хамгийн бага ба дээд тал нь хэдэн ширхэг хонхорцог шаардлагатайг хялбархан тодорхойлоход ашиглагдаж байгаа pods-ийн хэвтээ автомат масштабын механизмыг хангадаг. Жишээлбэл, хэрэв та замын хөдөлгөөний гэнэтийн огцом өсөлтийн улмаас нэмэлт хүчин чадал шаардагдах тохиргоог суулгасан бол maxReplicas-ийг 10-аас 20 болгон өөрчилж болно:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• Аюулгүй байдал ба менежмент. YAML нь Kubernetes-д зүйлсийг хэрхэн байрлуулж байгааг үнэлэхэд маш сайн. Жишээлбэл, таны ажлын ачаалал админ бус хэрэглэгчээр ажиллаж байгаа эсэх нь аюулгүй байдлын гол асуудал юм. Энэ тохиолдолд бидэнд хэрэглүүр гэх мэт хэрэгслүүд хэрэг болж магадгүй тэмцээн, YAML/JSON баталгаажуулагч, нэмэх Нээлттэй бодлогын агент, нөхцөл байдлыг баталгаажуулах бодлогын баталгаажуулагч Аюулгүй байдлын контекст Таны ажлын ачаалал нь контейнерыг администраторын эрхээр ажиллуулахыг зөвшөөрдөггүй. Хэрэв энэ шаардлагатай бол хэрэглэгчид энгийн бодлогыг хэрэгжүүлэх боломжтой би залбирдаг, үүн шиг:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• Үүл үйлчилгээ үзүүлэгчтэй нэгтгэх сонголтууд. Өнөөгийн өндөр технологийн хамгийн алдартай чиг хандлагын нэг бол нийтийн үүлэн үйлчилгээ үзүүлэгч дээр ажлын ачааллыг ажиллуулах явдал юм. Бүрэлдэхүүн хэсгийг ашиглах үүл үйлчилгээ үзүүлэгч Kubernetes нь ямар ч кластерт ажиллаж байгаа үүлэн үйлчилгээ үзүүлэгчтэйгээ нэгдэх боломжийг олгодог. Жишээлбэл, хэрэв хэрэглэгч AWS дээр Kubernetes дээр програм ажиллуулж, тухайн програмыг үйлчилгээгээр дамжуулан үзүүлэхийг хүсвэл үүлэн үйлчилгээ үзүүлэгч нь үйлчилгээг автоматаар үүсгэхэд тусалдаг. LoadBalancerЭнэ нь ачааллын тэнцвэржүүлэгчийг автоматаар хангах болно Амазон уян ачаалал тэнцвэржүүлэгчтраффикийг програмын хэсэг рүү дахин чиглүүлэх.

Өргөтгөх чадвар

Kubernetes нь маш өргөн цар хүрээтэй бөгөөд хөгжүүлэгчид үүнд дуртай. Pod, deployment, гэх мэт боломжтой нөөцийн багц байдаг. StatefulSets, нууц, ConfigMaps, гэх мэт. Үнэн бол хэрэглэгчид болон хөгжүүлэгчид маягт дээр бусад нөөцийг нэмж болно захиалгат нөөцийн тодорхойлолт.

Жишээлбэл, хэрэв бид нөөцийг тодорхойлохыг хүсвэл CronTab, тэгвэл та иймэрхүү зүйлийг хийж болно:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

Дараа нь бид CronTab нөөцийг дараах байдлаар үүсгэж болно.

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

Kubernetes дахь өргөтгөлийн өөр нэг сонголт бол хөгжүүлэгч өөрөө мэдэгдэл бичих боломжтой. Оператор Энэ нь Кубернетес кластер дахь "хувийн дагуу ажилладаг тусгай процесс юм.хяналтын хэлхээ" Операторын тусламжтайгаар хэрэглэгч Kubernetes API-тай мэдээлэл солилцох замаар CRD-ийн удирдлагыг (захиалгат нөөцийн тодорхойлолт) автоматжуулах боломжтой.

Нийгэмлэгт хөгжүүлэгчид өөрсдийн операторуудыг бий болгоход хялбар болгодог хэд хэдэн хэрэгсэл байдаг. Тэдний дунд - Операторын хүрээ мөн түүний SDK оператор. Энэхүү SDK нь хөгжүүлэгч хурдан оператор үүсгэж эхлэх үндэс суурь болдог. Та тушаалын мөрөөс дараах зүйлийг эхлүүлж болно гэж бодъё.

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

Энэ нь YAML файлууд болон Голанг код зэрэг таны операторын бүх кодыг үүсгэдэг.

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

Дараа нь та шаардлагатай API болон хянагчийг дараах байдлаар нэмж болно:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

Эцэст нь операторыг цуглуулж, контейнерийнхээ бүртгэлд илгээнэ үү.

$ operator-sdk build your.container.registry/youruser/myapp-operator

Хэрэв хөгжүүлэгч илүү их хяналтыг хүсч байвал Go файлуудын кодыг өөрчилж болно. Жишээлбэл, хянагчийн онцлогийг өөрчлөхийн тулд та файлд өөрчлөлт оруулж болно controller.go.

Өөр нэг төсөл КУДО, танд зөвхөн мэдэгдлийн YAML файлуудыг ашиглан мэдэгдэл үүсгэх боломжийг олгоно. Жишээлбэл, Апачи Кафкагийн операторыг ойролцоогоор тодорхойлно тэгээд. Үүний тусламжтайгаар та Кафка кластерийг Кубернетес дээр хэдхэн тушаалаар суулгаж болно.

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Дараа нь өөр тушаалаар тохируулна уу:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

Инноваци

Сүүлийн хэдэн жилийн хугацаанд Kubernetes-ийн томоохон хувилбарууд хэдэн сар тутамд гарч байна, өөрөөр хэлбэл жилд гурваас дөрвөн том хувилбар гарч байна. Тэд тус бүрт нэвтрүүлсэн шинэ функцүүдийн тоо буурахгүй байна. Түүгээр ч барахгүй энэ хүнд хэцүү үед ч удаашрах шинж тэмдэг алга - одоо нөхцөл байдал ямар байгааг хараарай Github дээрх Kubernetes төслийн үйл ажиллагаа.

Шинэ боломжууд нь олон төрлийн ажлын ачаалал дээр илүү уян хатан кластер хийх боломжийг танд олгоно. Нэмж дурдахад программистууд програмуудыг шууд үйлдвэрлэлд нэвтрүүлэхэд илүү их хяналт тавьдаг.

Олон нийт

Кубернетесийн алдар нэрийн өөр нэг чухал тал бол нийгэмлэгийн хүч чадал юм. 2015 онд 1.0 хувилбарт хүрсэний дараа Кубернетес ивээн тэтгэсэн Cloud Native Computing сан.

Мөн янз бүрийн нийгэмлэгүүд байдаг SIG (Тусгай сонирхлын бүлгүүд) төслийг хөгжүүлэх явцад Kubernetes-ийн өөр өөр чиглэлээр ажиллахад анхаарлаа төвлөрүүлэв. Эдгээр бүлгүүд шинэ боломжуудыг байнга нэмж, Kubernetes-тэй ажиллахад илүү тохиромжтой, тохиромжтой болгодог.

Cloud Native Foundation нь мөн CloudNativeCon/KubeCon-ийг зохион байгуулдаг бөгөөд энэ нь бичиж байх үед дэлхийн хамгийн том нээлттэй эхийн бага хурал юм. Жилд гурван удаа зохиогддог бөгөөд Кубернетес болон түүний экосистемийг сайжруулах, гурван сар тутамд гарч ирдэг шинэ боломжуудыг сурах хүсэлтэй олон мянган мэргэжилтнүүдийг цуглуулдаг.

Үүнээс гадна, Cloud Native Foundation нь бий Техникийн хяналтын хороо, энэ нь SIG-ийн хамт шинэ болон одоо байгаа дүгнэлтийг хийдэг төслүүд үүлэн экосистемд чиглэсэн хөрөнгө. Эдгээр төслүүдийн ихэнх нь Kubernetes-ийн давуу талыг сайжруулахад тусалдаг.

Эцэст нь хэлэхэд, Кубернетес бүх нийтийн ухамсартай хүчин чармайлтгүйгээр амжилтанд хүрэхгүй байх байсан гэдэгт би итгэж байна, тэнд хүмүүс хоорондоо нягт холбоотой боловч нэгэн зэрэг шинээр ирсэн хүмүүсийг угтан авдаг.

Ирээдүй

Хөгжүүлэгчдийн ирээдүйд тулгарах гол сорилтуудын нэг бол кодын ажиллаж буй дэд бүтцэд бус харин түүний нарийн ширийн зүйлд анхаарлаа хандуулах чадвар юм. Энэ нь эдгээр чиг хандлагад нийцдэг сервергүй архитектурын парадигм, энэ нь өнөөдөр тэргүүлэгчдийн нэг юм. Нарийвчилсан хүрээнүүд аль хэдийн бий, жишээлбэл. Нэхмэл и OpenFaas, энэ нь хөгжүүлэгчээс дэд бүтцийг хийсвэрлэхийн тулд Kubernetes-ийг ашигладаг.

Энэ нийтлэлд бид Кубернетесийн одоогийн төлөв байдлын гадаргууг л маажин хийсэн - үнэндээ энэ бол мөсөн уулын зөвхөн орой юм. Kubernetes-ийн хэрэглэгчид өөр олон нөөц, боломж, тохиргоотой байдаг.

Эх сурвалж: www.habr.com