హెల్మ్‌తో బహుళ కుబెర్నెట్స్ క్లస్టర్‌లలో అప్లికేషన్‌లను అమలు చేయండి

Dailymotion ఎలా Kubernetes ఉపయోగిస్తుంది: అప్లికేషన్ డిప్లాయ్‌మెంట్

Dailymotion వద్ద మేము 3 సంవత్సరాల క్రితం ఉత్పత్తిలో Kubernetes ఉపయోగించడం ప్రారంభించాము. కానీ బహుళ క్లస్టర్‌లలో అప్లికేషన్‌లను అమలు చేయడం సరదాగా ఉంటుంది, కాబట్టి గత కొన్ని సంవత్సరాలుగా మేము మా సాధనాలు మరియు వర్క్‌ఫ్లోలను మెరుగుపరచడానికి ప్రయత్నిస్తున్నాము.

ఎక్కడ మొదలైంది

ప్రపంచవ్యాప్తంగా ఉన్న బహుళ కుబెర్నెట్స్ క్లస్టర్‌లలో మా అప్లికేషన్‌లను ఎలా అమలు చేస్తామో ఇక్కడ మేము కవర్ చేస్తాము.

ఒకేసారి బహుళ కుబెర్నెట్స్ వస్తువులను అమలు చేయడానికి, మేము ఉపయోగిస్తాము హెల్మ్, మరియు మా అన్ని చార్ట్‌లు ఒకే git రిపోజిటరీలో నిల్వ చేయబడతాయి. అనేక సేవల నుండి పూర్తి అప్లికేషన్ స్టాక్‌ను అమలు చేయడానికి, మేము సారాంశ చార్ట్ అని పిలవబడేదాన్ని ఉపయోగిస్తాము. ముఖ్యంగా, ఇది డిపెండెన్సీలను ప్రకటించే చార్ట్ మరియు ఒక ఆదేశంతో API మరియు దాని సేవలను ప్రారంభించేందుకు మిమ్మల్ని అనుమతిస్తుంది.

తనిఖీలు చేయడానికి, చార్ట్‌లను రూపొందించడానికి, రహస్యాలను జోడించడానికి మరియు అప్లికేషన్‌లను అమలు చేయడానికి మేము హెల్మ్ పైన చిన్న పైథాన్ స్క్రిప్ట్‌ను కూడా వ్రాసాము. ఈ పనులన్నీ డాకర్ ఇమేజ్‌ని ఉపయోగించి సెంట్రల్ CI ప్లాట్‌ఫారమ్‌లో నిర్వహించబడతాయి.

ఇక విషయానికి వద్దాం.

గమనిక. మీరు దీన్ని చదువుతున్నప్పుడు, హెల్మ్ 3 కోసం మొదటి విడుదల అభ్యర్థి ఇప్పటికే ప్రకటించబడింది. ప్రధాన సంస్కరణలో మేము గతంలో ఎదుర్కొన్న కొన్ని సమస్యలను పరిష్కరించడానికి మెరుగుదలల మొత్తం హోస్ట్ ఉంది.

చార్ట్ అభివృద్ధి వర్క్‌ఫ్లో

మేము అప్లికేషన్‌ల కోసం బ్రాంచ్‌ని ఉపయోగిస్తాము మరియు చార్ట్‌లకు అదే విధానాన్ని వర్తింపజేయాలని మేము నిర్ణయించుకున్నాము.

• శాఖ dev డెవలప్‌మెంట్ క్లస్టర్‌లపై పరీక్షించబడే చార్ట్‌లను రూపొందించడానికి ఉపయోగిస్తారు.
• పుల్ అభ్యర్థన సమర్పించబడినప్పుడు మాస్టర్, వారు స్టేజింగ్‌లో తనిఖీ చేయబడతారు.
• చివరగా, బ్రాంచ్‌లో మార్పులను చేయడానికి మేము పుల్ అభ్యర్థనను సృష్టిస్తాము ఉత్పత్తి మరియు వాటిని ఉత్పత్తిలో వర్తింపజేయండి.

ప్రతి పర్యావరణం దాని స్వంత ప్రైవేట్ రిపోజిటరీని కలిగి ఉంటుంది, అది మా చార్ట్‌లను నిల్వ చేస్తుంది మరియు మేము ఉపయోగిస్తాము చార్ట్ మ్యూజియం చాలా ఉపయోగకరమైన APIలతో. ఈ విధంగా మేము వాటిని ఉత్పత్తిలో ఉపయోగించే ముందు వాతావరణాలు మరియు చార్ట్‌ల యొక్క వాస్తవ-ప్రపంచ పరీక్షల మధ్య కఠినమైన ఐసోలేషన్‌ను నిర్ధారిస్తాము.

వివిధ వాతావరణాలలో చార్ట్ రిపోజిటరీలు

డెవలపర్లు దేవ్ బ్రాంచ్‌ను పుష్ చేసినప్పుడు, వారి చార్ట్ యొక్క సంస్కరణ స్వయంచాలకంగా dev Chartmuseumకి నెట్టబడుతుంది. అందువల్ల, డెవలపర్‌లందరూ ఒకే డెవలప్‌మెంట్ రిపోజిటరీని ఉపయోగిస్తారు మరియు అనుకోకుండా వేరొకరి మార్పులను ఉపయోగించకుండా మీరు మీ చార్ట్ వెర్షన్‌ను జాగ్రత్తగా పేర్కొనాలి.

అంతేకాకుండా, మా చిన్న పైథాన్ స్క్రిప్ట్ ఉపయోగించి Kubernetes OpenAPI స్పెసిఫికేషన్‌లకు వ్యతిరేకంగా Kubernetes వస్తువులను ధృవీకరిస్తుంది కుబేవల్, వాటిని Chartmusemలో ప్రచురించే ముందు.

చార్ట్ డెవలప్‌మెంట్ వర్క్‌ఫ్లో సాధారణ వివరణ

1. స్పెసిఫికేషన్ ప్రకారం పైప్‌లైన్ పనులను ఏర్పాటు చేయడం gazr.io నాణ్యత నియంత్రణ కోసం (లింట్, యూనిట్-టెస్ట్).
2. మా అప్లికేషన్‌లను అమలు చేసే పైథాన్ సాధనాలతో డాకర్ చిత్రాన్ని నెట్టడం.
3. శాఖ పేరుతో పర్యావరణాన్ని ఏర్పాటు చేయడం.
4. Kubeval ఉపయోగించి Kubernetes yaml ఫైల్‌లను ధృవీకరిస్తోంది.
5. చార్ట్ మరియు దాని పేరెంట్ చార్ట్‌ల సంస్కరణను స్వయంచాలకంగా పెంచండి (మార్చబడుతున్న చార్ట్‌పై ఆధారపడి ఉండే చార్ట్‌లు).
6. దాని వాతావరణానికి సరిపోయే చార్ట్‌మ్యూజియంకు చార్ట్‌ను సమర్పించడం

క్లస్టర్లలో తేడాలను నిర్వహించడం

క్లస్టర్ల సమాఖ్య

మనం వాడే కాలం కూడా ఉంది కుబెర్నెటెస్ క్లస్టర్ల సమాఖ్య, ఇక్కడ కుబెర్నెట్స్ ఆబ్జెక్ట్‌లను ఒకే API ఎండ్ పాయింట్ నుండి ప్రకటించవచ్చు. కానీ సమస్యలు తలెత్తాయి. ఉదాహరణకు, కొన్ని కుబెర్నెట్స్ ఆబ్జెక్ట్‌లను ఫెడరేషన్ ఎండ్‌పాయింట్‌లో సృష్టించడం సాధ్యం కాదు, వ్యక్తిగత క్లస్టర్‌ల కోసం సమాఖ్య వస్తువులు మరియు ఇతర వస్తువులను నిర్వహించడం కష్టతరం చేస్తుంది.

సమస్యను పరిష్కరించడానికి, మేము క్లస్టర్‌లను స్వతంత్రంగా నిర్వహించడం ప్రారంభించాము, ఇది ప్రక్రియను చాలా సులభతరం చేసింది (మేము ఫెడరేషన్ యొక్క మొదటి సంస్కరణను ఉపయోగించాము; రెండవదానిలో ఏదో మార్పు ఉండవచ్చు).

జియో-డిస్ట్రిబ్యూటెడ్ ప్లాట్‌ఫారమ్

మా ప్లాట్‌ఫారమ్ ప్రస్తుతం 6 ప్రాంతాలలో పంపిణీ చేయబడింది - 3 స్థానికంగా మరియు 3 క్లౌడ్‌లో.

పంపిణీ చేయబడిన విస్తరణ

గ్లోబల్ హెల్మ్ విలువలు

4 గ్లోబల్ హెల్మ్ విలువలు క్లస్టర్‌ల మధ్య తేడాలను గుర్తించడానికి మిమ్మల్ని అనుమతిస్తాయి. మా అన్ని చార్ట్‌లు డిఫాల్ట్ కనీస విలువలను కలిగి ఉంటాయి.

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

ప్రపంచ విలువలు

ఈ విలువలు మా అప్లికేషన్‌ల కోసం సందర్భాన్ని నిర్వచించడంలో సహాయపడతాయి మరియు వివిధ ప్రయోజనాల కోసం ఉపయోగించబడతాయి: పర్యవేక్షణ, ట్రేసింగ్, లాగింగ్, బాహ్య కాల్‌లు చేయడం, స్కేలింగ్ మొదలైనవి.

• "Cloud": మాకు హైబ్రిడ్ Kubernetes ప్లాట్‌ఫారమ్ ఉంది. ఉదాహరణకు, మా API GCP జోన్‌లలో మరియు మా డేటా సెంటర్‌లలో అమలు చేయబడుతుంది.
• "env": ఉత్పత్తి కాని పరిసరాల కోసం కొన్ని విలువలు మారవచ్చు. ఉదాహరణకు, వనరుల నిర్వచనాలు మరియు ఆటోస్కేలింగ్ కాన్ఫిగరేషన్‌లు.
• "region": ఈ సమాచారం క్లస్టర్ యొక్క స్థానాన్ని గుర్తించడంలో సహాయపడుతుంది మరియు బాహ్య సేవల కోసం సమీపంలోని ముగింపు పాయింట్‌లను గుర్తించడానికి ఉపయోగించవచ్చు.
• "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 -}}

హెల్మ్ టెంప్లేట్ ఉదాహరణ

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

సేవ నిర్వచనం

ఇది మా విస్తరణ వర్క్‌ఫ్లోను నిర్వచించే అన్ని దశల రూపురేఖలు. చివరి దశ అప్లికేషన్‌ను ఏకకాలంలో బహుళ వర్కర్ క్లస్టర్‌లకు అమలు చేస్తుంది.

జెంకిన్స్ విస్తరణ దశలు

రహస్యాల గురించి ఏమిటి?

భద్రతకు సంబంధించి, మేము వివిధ ప్రదేశాల నుండి అన్ని రహస్యాలను ట్రాక్ చేస్తాము మరియు వాటిని ప్రత్యేకమైన ఖజానాలో నిల్వ చేస్తాము ఖజానా в పరీజే.

మా విస్తరణ సాధనాలు వాల్ట్ నుండి రహస్య విలువలను సంగ్రహిస్తాయి మరియు విస్తరణ సమయం వచ్చినప్పుడు, వాటిని హెల్మ్‌లోకి చొప్పించండి.

దీన్ని చేయడానికి, మేము వాల్ట్‌లోని రహస్యాలు మరియు మా అప్లికేషన్‌లకు అవసరమైన రహస్యాల మధ్య మ్యాపింగ్‌ను నిర్వచించాము:

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"

• వాల్ట్‌లో రహస్యాలను రికార్డ్ చేసేటప్పుడు అనుసరించాల్సిన సాధారణ నియమాలను మేము నిర్వచించాము.
• రహస్యం వర్తిస్తుంది నిర్దిష్ట సందర్భం లేదా క్లస్టర్‌కు, మీరు నిర్దిష్ట ఎంట్రీని జోడించాలి. (ఇక్కడ సందర్భం క్లస్టర్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

సమస్యలు మరియు పరిమితులు

బహుళ రిపోజిటరీలతో పని చేస్తోంది

ఇప్పుడు మేము చార్ట్‌లు మరియు అప్లికేషన్‌ల అభివృద్ధిని వేరు చేస్తాము. డెవలపర్‌లు రెండు గిట్ రిపోజిటరీలలో పని చేయాల్సి ఉంటుందని దీని అర్థం: ఒకటి అప్లికేషన్ కోసం మరియు ఒకటి కుబెర్నెట్స్‌కు దాని విస్తరణను నిర్వచించడానికి. 2 git రిపోజిటరీలు అంటే 2 వర్క్‌ఫ్లోలు, మరియు కొత్త వ్యక్తి గందరగోళానికి గురికావడం సులభం.

సాధారణీకరించిన చార్ట్‌లను నిర్వహించడం ఒక అవాంతరం

మేము ఇప్పటికే చెప్పినట్లుగా, డిపెండెన్సీలను గుర్తించడానికి మరియు బహుళ అప్లికేషన్‌లను త్వరగా అమలు చేయడానికి జెనరిక్ చార్ట్‌లు చాలా ఉపయోగకరంగా ఉంటాయి. కానీ మేము ఉపయోగిస్తాము --reuse-valuesమేము ఈ సాధారణీకరించిన చార్ట్‌లో భాగమైన అప్లికేషన్‌ను అమలు చేసిన ప్రతిసారీ అన్ని విలువలను దాటకుండా ఉండటానికి.

నిరంతర డెలివరీ వర్క్‌ఫ్లో, మాకు కేవలం రెండు విలువలు మాత్రమే ఉంటాయి, అవి క్రమం తప్పకుండా మారుతాయి: ప్రతిరూపాల సంఖ్య మరియు ఇమేజ్ ట్యాగ్ (వెర్షన్). ఇతర, మరింత స్థిరమైన విలువలు మానవీయంగా మార్చబడతాయి మరియు ఇది చాలా కష్టం. అంతేకాకుండా, సాధారణీకరించిన చార్ట్‌ను అమలు చేయడంలో ఒక పొరపాటు తీవ్రమైన వైఫల్యాలకు దారి తీస్తుంది, మన స్వంత అనుభవం నుండి మనం చూసినట్లుగా.

బహుళ కాన్ఫిగరేషన్ ఫైల్‌లను నవీకరిస్తోంది

డెవలపర్ కొత్త అప్లికేషన్‌ను జోడించినప్పుడు, అతను అనేక ఫైల్‌లను మార్చవలసి ఉంటుంది: అప్లికేషన్ డిక్లరేషన్, సీక్రెట్స్ జాబితా, అప్లికేషన్‌ను సాధారణీకరించిన చార్ట్‌లో చేర్చినట్లయితే డిపెండెన్సీగా జోడించడం.

వాల్ట్‌లో జెంకిన్స్ అనుమతులు చాలా పొడిగించబడ్డాయి

ఇప్పుడు మన దగ్గర ఒకటి ఉంది AppRole, ఇది వాల్ట్ నుండి అన్ని రహస్యాలను చదువుతుంది.

రోల్‌బ్యాక్ ప్రక్రియ స్వయంచాలకంగా లేదు

రోల్‌బ్యాక్ చేయడానికి, మీరు అనేక క్లస్టర్‌లలో ఆదేశాన్ని అమలు చేయాలి మరియు ఇది లోపాలతో నిండి ఉంది. సరైన సంస్కరణ ID పేర్కొనబడిందని నిర్ధారించుకోవడానికి మేము ఈ ఆపరేషన్‌ను మాన్యువల్‌గా చేస్తాము.

మేము GitOps వైపు వెళ్తున్నాము

మా లక్ష్యం

మేము చార్ట్‌ను అది అమలు చేసే అప్లికేషన్ యొక్క రిపోజిటరీకి తిరిగి ఇవ్వాలనుకుంటున్నాము.

వర్క్‌ఫ్లో డెవలప్‌మెంట్ మాదిరిగానే ఉంటుంది. ఉదాహరణకు, ఒక బ్రాంచ్‌ను మాస్టర్‌కి నెట్టినప్పుడు, విస్తరణ స్వయంచాలకంగా ట్రిగ్గర్ చేయబడుతుంది. ఈ విధానం మరియు ప్రస్తుత వర్క్‌ఫ్లో మధ్య ప్రధాన వ్యత్యాసం అది ప్రతిదీ gitలో నిర్వహించబడుతుంది (అప్లికేషన్ మరియు అది కుబెర్నెట్స్‌లో అమర్చబడిన విధానం).

అనేక ప్రయోజనాలు ఉన్నాయి:

• చాలా స్పష్టమైన డెవలపర్ కోసం. స్థానిక చార్ట్‌లో మార్పులను ఎలా వర్తింపజేయాలో నేర్చుకోవడం సులభం.
• సేవ విస్తరణ నిర్వచనాన్ని పేర్కొనవచ్చు కోడ్ వలె అదే స్థలం సేవ.
• సాధారణీకరించిన చార్ట్‌ల తొలగింపును నిర్వహించడం. సేవ దాని స్వంత హెల్మ్ విడుదలను కలిగి ఉంటుంది. ఇది ఇతర సేవలను ప్రభావితం చేయకుండా, చిన్న స్థాయిలో అప్లికేషన్ జీవితచక్రాన్ని (రోల్‌బ్యాక్, అప్‌గ్రేడ్) నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తుంది.
• 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