Utangulizi mfupi wa Kustomize

Kumbuka. tafsiri.: Makala yaliandikwa na Scott Lowe, mhandisi aliye na uzoefu mkubwa katika IT, ambaye ni mwandishi/mwandishi mwenza wa vitabu saba vilivyochapishwa (hasa kwenye VMware vSphere). Sasa anafanya kazi kwa kampuni yake tanzu ya VMware Heptio (iliyopatikana mnamo 2016), akibobea katika kompyuta ya wingu na Kubernetes. Maandishi yenyewe hutumika kama utangulizi mfupi na rahisi kuelewa wa usimamizi wa usanidi wa Kubernetes kwa kutumia teknolojia. Geuza kukufaa, ambayo hivi karibuni imekuwa sehemu ya K8s.

Kustomize ni zana inayowaruhusu watumiaji "kubinafsisha faili za YAML rahisi, zisizo na violezo kwa madhumuni tofauti, na kuacha YAML asili ikiwa sawa na kutumika" (maelezo yamekopwa moja kwa moja kutoka kustomize hazina kwenye GitHub) Kustomize inaweza kuendeshwa moja kwa moja au, kama ya Kubernetes 1.14, kutumika kubectl -k kufikia utendakazi wake (ingawa kama Kubernetes 1.15, mfumo wa jozi tofauti ni mpya zaidi kuliko uwezo uliojengwa katika kubectl). (Kumbuka. tafsiri.: Na kwa toleo la hivi karibuni Kubernetes 1.16 Customize mkono na pia katika matumizi ya kubeadm.) Katika chapisho hili, nataka kuwajulisha wasomaji misingi ya kustomize.

Katika umbo/matumizi yake rahisi zaidi, kustomize ni mkusanyiko wa rasilimali (faili za YAML zinazofafanua vitu vya Kubernetes: Usambazaji, Huduma, n.k.) pamoja na orodha ya maagizo ya mabadiliko yanayohitaji kufanywa kwenye rasilimali hizo. Kama vile make hutumia seti ya maagizo iliyomo ndani Makefile, na Docker huunda chombo kulingana na maagizo kutoka Dockerfile,binafsisha matumizi kustomization.yaml kuhifadhi maagizo kuhusu mabadiliko ambayo mtumiaji anataka kufanya kwa seti ya rasilimali.

Hapa kuna faili ya mfano kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Sitajaribu kuzungumza juu ya sehemu zote zinazowezekana kwenye faili. kustomization.yaml (hii imeandikwa vizuri hapa), lakini nitatoa maelezo mafupi ya mfano maalum:

• Shamba resources inaonyesha ni (rasilimali gani) kustomize itabadilika. Katika kesi hii, itatafuta rasilimali katika faili deployment.yaml и service.yaml kwenye saraka yako (unaweza kutaja njia kamili au jamaa ikiwa ni lazima).
• Shamba namePrefix inaagiza kustomize kuongeza kiambishi awali fulani (katika kesi hii - dev-) kuashiria name rasilimali zote zilizoainishwa kwenye uwanja resources. Kwa hivyo, ikiwa Usambazaji una name yenye maana nginx-deployment, kubinafsisha kutaifanya dev-nginx-deployment.
• Shamba namespace inaagiza kustomize kuongeza nafasi ya majina kwa rasilimali zote. Katika kesi hii, Usambazaji na Huduma zitaanguka kwenye nafasi ya majina development.
• Hatimaye, shamba commonLabels ina seti ya lebo ambazo zitaongezwa kwa rasilimali zote. Katika mfano wetu, kustomize itaweka lebo kwa rasilimali zilizo na jina environment na thamani development.

Ikiwa mtumiaji anafanya kustomize build . kwenye saraka na faili kustomization.yaml na rasilimali zinazohitajika (yaani mafaili deployment.yaml и service.yaml), basi kwenye pato itapokea maandishi na mabadiliko yaliyoainishwa ndani kustomization.yaml.

Kumbuka. tafsiri.: Mchoro kutoka kwa nyaraka za mradi juu ya matumizi "rahisi" ya kustomize

Matokeo yanaweza kuelekezwa upya ikiwa mabadiliko yanahitajika kufanywa:

kustomize build . > custom-config.yaml

Data ya pato ni ya kuamua (data sawa ya pembejeo itatoa matokeo sawa), kwa hivyo sio lazima kuhifadhi matokeo kwenye faili. Badala yake, inaweza kupitishwa moja kwa moja kwa amri nyingine:

kustomize build . | kubectl apply -f -

Vipengele vya kustomize pia vinaweza kupatikana kupitia kubectl -k (tangu Kubernetes toleo la 1.14). Hata hivyo, kumbuka kuwa kifurushi cha kustomize cha pekee kinasasishwa kwa kasi zaidi kuliko kifurushi kilichojumuishwa cha kubectl (angalau hii ndivyo ilivyo kwa toleo la Kubernetes 1.15).

Wasomaji wanaweza kuuliza: "Kwa nini utata huu wote ikiwa unaweza kuhariri faili moja kwa moja?" Swali kubwa. Kwa kweli, katika mfano wetu mtu anaweza rekebisha faili deployment.yaml и service.yaml moja kwa moja, lakini vipi ikiwa ni uma wa mradi wa mtu mwingine? Kubadilisha faili moja kwa moja hufanya iwe ngumu (ikiwa haiwezekani) kuweka tena uma wakati mabadiliko yanafanywa kwa asili/chanzo. Kutumia kustomize hukuruhusu kuweka mabadiliko haya kwenye faili kustomization.yaml, na kuacha faili asili zikiwa sawa na hivyo kurahisisha kuweka upya faili za asili ikiwa ni lazima.

Faida za kustomize huonekana katika hali ngumu zaidi za utumiaji. Katika mfano hapo juu kustomization.yaml na rasilimali ziko kwenye saraka sawa. Walakini, kustomize inasaidia kesi za utumiaji ambapo kuna usanidi wa msingi na anuwai zake nyingi, zinazojulikana pia kama kuingiliana. Kwa mfano, mtumiaji alitaka kuchukua Usambazaji na Huduma kwa nginx, ambayo nilitumia kama mfano, na kuunda matoleo ya ukuzaji, uwekaji na uzalishaji (au vibadala) vya faili hizo. Kwa kufanya hivyo, atahitaji nyongeza zilizotajwa hapo juu na, kwa kweli, rasilimali za msingi wenyewe.

Ili kuonyesha wazo la viwekeleo na rasilimali za msingi (rasilimali za msingi), wacha tufikirie kuwa saraka zina muundo ufuatao:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Katika faili base/kustomization.yaml watumiaji wanaotumia uwanja resources tangaza tu rasilimali ambazo kustomize inapaswa kujumuisha.

Katika kila faili overlays/{dev,staging,prod}/kustomization.yaml watumiaji hurejelea usanidi wa msingi kwenye uwanja resources, na kisha onyesha mabadiliko maalum kwa mazingira yaliyotolewa. Kwa mfano, faili overlays/dev/kustomization.yaml inaweza kuonekana kama mfano uliotolewa hapo awali:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Katika kesi hii faili overlays/prod/kustomization.yaml inaweza kuwa tofauti kabisa:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Wakati mtumiaji anaendesha kustomize build . katika orodha overlays/dev, kustomize itazalisha chaguo la maendeleo. Ikiwa unakimbia kustomize build . katika orodha overlays/prod - unapata chaguo la uzalishaji. Na hii yote - bila kufanya mabadiliko yoyote kwa asili (msingi) faili, zote kwa njia ya kutangaza na ya kuamua. Unaweza kuweka usanidi wa msingi na saraka za kuwekelea moja kwa moja kwenye udhibiti wa toleo, ukijua kwamba kulingana na faili hizi unaweza kuzalisha usanidi unaotaka wakati wowote.

Kumbuka. tafsiri.: Mchoro kutoka kwa nyaraka za mradi juu ya kutumia viwekeleo katika kustomize

Customize can sana zaidi ya yale yaliyotajwa katika makala hii. Walakini, natumai itatumika kama utangulizi mzuri.

Rasilimali za Ziada

Kuna nakala nyingi nzuri na machapisho kuhusu kustomize. Hapa kuna machache ambayo nilipata kuwa muhimu sana:

• Badilisha usanidi wa msingi wa YAML kwa mazingira tofauti ya prod/test kwa kutumia Kustomize;
• Kustomize - Njia sahihi ya kufanya violezo katika Kubernetes;
• Usimamizi wa Kutangaza wa Vitu vya Kubernetes Kwa Kutumia Customize;
• Kubinafsisha Chati za Helm za Juu kwa kutumia Geuza kukufaa.

Kumbuka. tafsiri.: Unaweza pia kupendekeza kizuizi cha viungo vilivyochapishwa kama rasilimali kwenye tovuti ya shirika, ikifuatiwa na mkusanyiko wa video na ripoti za hivi punde kuhusu kustomize.

Ikiwa una maswali au mapendekezo ya kuboresha nyenzo hii, niko wazi kila wakati kwa maoni. Unaweza kuwasiliana nami kwa Twitter au Kituo cha Kubernetes Slack. Furahia kurekebisha maonyesho yako kwa kustomize!

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• «Zana za watengenezaji wa programu zinazoendeshwa kwenye Kubernetes";
• «Kubernetes 1.14: Vivutio vya kile kipya";
• «Matokeo makuu matano ya Mkutano wa Helm 2019 huko Amsterdam";
• «Utangulizi wa vitendo kwa msimamizi wa kifurushi cha Kubernetes - Helm'.

Chanzo: mapenzi.com