ProHoster > Блог > басқарма > Helm көмегімен бірнеше Kubernetes кластерлері бойынша қолданбаларды орналастырыңыз

Helm көмегімен бірнеше Kubernetes кластерлері бойынша қолданбаларды орналастырыңыз

Dailymotion Kubernetes қалай пайдаланады: қолданбаны орналастыру

Біз Dailymotion-те Kubernetes-ті өндірісте 3 жыл бұрын пайдалана бастадық. Бірақ қолданбаларды бірнеше кластерлерде қолдану қызық, сондықтан соңғы бірнеше жылда біз құралдар мен жұмыс процестерін жақсартуға тырыстық.

Қайдан басталды

Мұнда біз әлем бойынша бірнеше Kubernetes кластерлерінде қолданбаларды қалай орналастыратынымызды қарастырамыз.

Бір уақытта бірнеше Kubernetes нысандарын орналастыру үшін біз пайдаланамыз Хельм, және біздің барлық диаграммаларымыз бір git репозиторийінде сақталады. Бірнеше қызметтерден толық қолданбалар стегін орналастыру үшін біз жиынтық диаграмма деп аталатынды пайдаланамыз. Негізінде, бұл тәуелділіктерді жариялайтын және API және оның қызметтерін бір пәрменмен инициализациялауға мүмкіндік беретін диаграмма.

Сондай-ақ тексерулер, диаграммалар жасау, құпияларды қосу және қолданбаларды орналастыру үшін Helm үстіне шағын Python сценарийін жаздық. Бұл тапсырмалардың барлығы докер кескіні арқылы орталық CI платформасында орындалады.

Нәтижеге келейік.

Ескерту. Сіз мұны оқып жатқанда, Helm 3 үшін бірінші шығарылым кандидаты қазірдің өзінде жарияланды. Негізгі нұсқада біз бұрын кездескен кейбір мәселелерді шешуге арналған көптеген жақсартулар бар.

Диаграммаларды әзірлеу жұмыс процесі

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

  • Филиал Dev әзірлеу кластерлерінде сыналатын диаграммаларды жасау үшін пайдаланылады.
  • Тарту сұрауы жіберілген кезде мастер, олар қойылымда тексеріледі.
  • Соңында, филиалға өзгертулерді енгізу үшін тарту сұрауын жасаймыз өнім және оларды өндірісте қолдану.

Әрбір ортада диаграммаларымызды сақтайтын өзінің жеке репозиторийі бар және біз оны пайдаланамыз Шартмұражайы өте пайдалы API интерфейстерімен. Осылайша, біз орталар арасындағы қатаң оқшаулауды және диаграммаларды өндірісте қолданар алдында нақты әлемде сынауды қамтамасыз етеміз.

Әртүрлі орталардағы диаграмма репозиторийлері

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

Сонымен қатар, біздің кішкентай Python сценарийі Kubernetes нысандарын Kubernetes OpenAPI сипаттамаларына сәйкес тексереді. Кубевал, оларды Chartmusem сайтында жарияламас бұрын.

Диаграмманы әзірлеу жұмысының жалпы сипаттамасы

  1. Техникалық сипаттамаларға сәйкес құбыр тапсырмаларын орнату gazr.io сапаны бақылау үшін (линт, бірлік-сынама).
  2. Біздің қолданбаларды орналастыратын Python құралдарымен докер кескінін итеру.
  3. Филиал атауы бойынша ортаны орнату.
  4. Kubeval көмегімен Kubernetes yaml файлдарын тексеру.
  5. Диаграмманың нұсқасын және оның негізгі диаграммаларын (өзгертілетін диаграммаға байланысты диаграммалар) автоматты түрде көбейтіңіз.
  6. Диаграмманы Диаграмма мұражайына оның ортасына сәйкес жіберу

Кластерлер арасындағы айырмашылықтарды басқару

Кластерлер федерациясы

Қолданған кезіміз болды Кубернетес кластерлерінің федерациясы, мұнда Kubernetes нысандарын бір API соңғы нүктесінен жариялауға болады. Бірақ проблемалар туындады. Мысалы, кейбір Kubernetes нысандарын федерацияның соңғы нүктесінде жасау мүмкін болмады, бұл федеративті нысандарды және жеке кластерлер үшін басқа нысандарды қолдауды қиындатады.

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

Гео-таратылған платформа

Біздің платформа қазіргі уақытта 6 аймаққа таратылған - 3 жергілікті және 3 бұлтта.


Бөлінген орналастыру

Global Helm құндылықтары

4 жаһандық Helm мәні кластерлер арасындағы айырмашылықтарды анықтауға мүмкіндік береді. Біздің барлық диаграммаларымызда әдепкі ең төменгі мәндер бар.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

Жаһандық құндылықтар

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

  • «бұлт»: Бізде гибридті Kubernetes платформасы бар. Мысалы, біздің API GCP аймақтарында және деректер орталықтарында орналастырылған.
  • "env": кейбір мәндер өндірістік емес орталар үшін өзгеруі мүмкін. Мысалы, ресурс анықтамалары және автомасштабтау конфигурациялары.
  • "аймақ": Бұл ақпарат кластердің орнын анықтауға көмектеседі және сыртқы қызметтер үшін жақын маңдағы соңғы нүктелерді анықтау үшін пайдаланылуы мүмкін.
  • "clusterName": жеке кластер үшін мәнді анықтағымыз келсе және қашан.

Міне, нақты мысал:

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

Helm үлгісінің мысалы

Бұл логика Kubernetes YAML-дің кедергісін болдырмау үшін көмекші үлгіде анықталған.

Өтінім туралы хабарландыру

Біздің орналастыру құралдары бірнеше YAML файлдарына негізделген. Төменде қызмет пен оның масштабтау топологиясын (репликалар саны) кластерде қалай жариялайтынымыздың мысалы берілген.

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

Қызмет анықтамасы

Бұл орналастыру жұмыс үрдісін анықтайтын барлық қадамдардың құрылымы. Соңғы қадам қолданбаны бірнеше жұмысшы кластерлеріне бір уақытта орналастырады.


Дженкинсті орналастыру қадамдары

Құпиялар ше?

Қауіпсіздікке қатысты біз барлық құпияларды әртүрлі жерлерден қадағалап, оларды бірегей қоймада сақтаймыз Қойма Парижде.

Біздің орналастыру құралдары Vault ішінен құпия мәндерді шығарады және орналастыру уақыты келгенде, оларды Helm ішіне енгізеді.

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

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

  • Біз Vault жүйесінде құпияларды жазу кезінде орындалатын жалпы ережелерді анықтадық.
  • Егер құпия қолданылса белгілі бір контекстке немесе кластерге, сізге арнайы жазба қосу керек. (Мұнда контекстік кластер1 құпия стек-бағдарлама1-құпия сөз үшін өз мәніне ие).
  • Әйтпесе мән пайдаланылады әдепкі бойынша.
  • Осы тізімдегі әрбір элемент үшін Кубернетес құпиясы кілт-мән жұбы енгізіледі. Сондықтан, біздің диаграммалардағы құпия үлгі өте қарапайым.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

Мәселелер мен шектеулер

Бірнеше репозиторийлермен жұмыс істеу

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

Жалпыланған диаграммаларды басқару қиын

Жоғарыда айтқанымыздай, жалпы диаграммалар тәуелділіктерді анықтау және бірнеше қолданбаларды жылдам орналастыру үшін өте пайдалы. Бірақ қолданамыз --reuse-valuesосы жалпыланған диаграмманың бөлігі болып табылатын қолданбаны қолданған сайын барлық мәндерді өткізбеу үшін.

Үздіксіз жеткізу жұмыс процесінде бізде үнемі өзгеретін екі мән бар: репликалар саны және кескін тегі (нұсқа). Басқа тұрақты мәндер қолмен өзгертіледі және бұл өте қиын. Сонымен қатар, жалпыланған диаграмманы орналастырудағы бір қателік елеулі сәтсіздіктерге әкелуі мүмкін, мұны өз тәжірибемізден көрдік.

Бірнеше конфигурация файлдарын жаңарту

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

Vault ішінде Дженкинс рұқсаттары тым кеңейтілген

Қазір бізде біреуі бар AppRole, ол қоймадағы барлық құпияларды оқиды.

Қайтару процесі автоматтандырылмаған

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

Біз GitOps бағытында келе жатырмыз

Біздің мақсат

Біз диаграмманы ол орналастыратын қолданбаның репозиторийіне қайтарғымыз келеді.

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

Бірнеше артықшылықтар бар:

  • Көп анық әзірлеушіге арналған. Жергілікті диаграммада өзгертулерді қолдануды үйрену оңайырақ.
  • Қызметті орналастыру анықтамасын көрсетуге болады кодпен бірдей орын қызмет көрсету.
  • Жалпыланған диаграммаларды жоюды басқару. Қызметтің өзінің Helm шығарылымы болады. Бұл басқа қызметтерге әсер етпеу үшін қолданбаның өмірлік циклін (қайтару, жаңарту) ең кіші деңгейде басқаруға мүмкіндік береді.
  • Git артықшылықтары диаграмманы басқару үшін: өзгерістерді болдырмау, тексеру журналы, т.б.. Диаграммадағы өзгертуді болдырмау қажет болса, мұны git арқылы орындауға болады. Орналастыру автоматты түрде басталады.
  • сияқты құралдармен әзірлеу жұмыс процесін жақсартуды қарастыруыңыз мүмкін Скаффолд, оның көмегімен әзірлеушілер өндіріске жақын контексте өзгерістерді сынай алады.

Екі сатылы көші-қон

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

  • Біз қолданбаны орналастыруды орнату үшін ұқсас құрылымды сақтаймыз, бірақ DailymotionRelease деп аталатын бір нысанда.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

  • Әр қолданбаға 1 шығарылым (жалпыланған диаграммаларсыз).
  • Қолданбаның git репозиторийіндегі диаграммалар.

Біз барлық әзірлеушілермен сөйлестік, сондықтан тасымалдау процесі басталып кетті. Бірінші кезең әлі де CI платформасы арқылы басқарылады. Мен жақында екінші кезең туралы тағы бір пост жазамын: GitOps жұмыс процесіне қалай көшкеніміз ағыны. Мен бәрін қалай орнатқанымызды және қандай қиындықтарға тап болғанымызды (көп репозиторийлер, құпиялар және т.б.) айтып беремін. Жаңалықты бақылаңыз.

Мұнда біз GitOps тәсілі туралы ойларға әкелген соңғы жылдардағы қолданбаларды орналастыру жұмыс үрдісіндегі жетістіктерімізді сипаттауға тырыстық. Біз әлі мақсатқа жеткен жоқпыз және нәтижелер туралы хабарлаймыз, бірақ қазір біз бәрін оңайлатып, оны әзірлеушілердің әдеттеріне жақындатуға шешім қабылдағанда дұрыс әрекет еткенімізге сенімдіміз.

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

пікір қалдыру