Lyhyt johdatus Kustomizeen

Huomautus. käännös: Artikkelin on kirjoittanut Scott Lowe, insinööri, jolla on laaja kokemus IT-alasta ja joka on seitsemän painetun kirjan (pääasiassa VMware vSphere) kirjoittaja/apukirjoittaja. Hän työskentelee nyt sen VMware-tytäryhtiössä Heptiossa (ostettu vuonna 2016), joka on erikoistunut pilvilaskentaan ja Kubernetesiin. Itse teksti toimii ytimekkäänä ja helposti ymmärrettävänä johdatuksena Kubernetesin konfiguraatioiden hallintaan teknologiaa hyödyntäen Mukauta, josta tuli hiljattain osa K8:aa.

Kustomize on työkalu, jonka avulla käyttäjät voivat "muokata yksinkertaisia, mallivapaita YAML-tiedostoja eri tarkoituksiin jättäen alkuperäisen YAMLin ehjäksi ja käyttökelpoiseksi" (kuvaus lainattu suoraan kustomize-arkisto GitHubissa). Kustomize voidaan ajaa suoraan tai Kubernetes 1.14:stä alkaen käyttää kubectl -k käyttääkseen sen toimintoja (vaikka Kubernetes 1.15:stä lähtien erillinen binaari on uudempi kuin kubectlin sisäänrakennetut ominaisuudet). (Huomautus. käännös: Ja tuoreen julkaisun kanssa Kubernetes 1.16 muokata tukema myös kubeadm-apuohjelmassa.) Tässä postauksessa haluan esitellä lukijat kustomizen perusteet.

Yksinkertaisimmassa muodossaan/sovelluksessaan kustomize on yksinkertaisesti kokoelma resursseja (YAML-tiedostoja, jotka määrittävät Kubernetes-objekteja: käyttöönotot, palvelut jne.) sekä luettelo ohjeista näihin resursseihin tehtävistä muutoksista. Aivan kuten make käyttää ohjesarjan sisältämiä ohjeita Makefile, ja Docker rakentaa säilön ohjeiden perusteella Dockerfile, mukauttaa käyttötarkoituksia kustomization.yaml tallentaa ohjeita siitä, mitä muutoksia käyttäjä haluaa tehdä resursseihin.

Tässä on esimerkkitiedosto kustomization.yaml:

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

En yritä puhua kaikista tiedoston mahdollisista kentistä. kustomization.yaml (Tästä on kirjoitettu hyvin täällä), mutta annan lyhyen selityksen tietystä esimerkistä:

• Kenttä resources osoittaa, mitä (mitä resursseja) kustomize muuttaa. Tässä tapauksessa se etsii resursseja tiedostoista deployment.yaml и service.yaml hakemistossasi (voit määrittää täydelliset tai suhteelliset polut tarvittaessa).
• Kenttä namePrefix käskee kustomizea lisäämään tietyn etuliitteen (tässä tapauksessa - dev-) määrittämään name kaikki alalla määritellyt resurssit resources. Näin ollen, jos käyttöönotto on name arvoilla nginx-deployment, mukauttamalla se onnistuu dev-nginx-deployment.
• Kenttä namespace käskee kustomizea lisäämään annetun nimitilan kaikkiin resursseihin. Tässä tapauksessa Käyttöönotto ja Palvelu kuuluvat nimiavaruuteen development.
• Lopuksi kenttä commonLabels sisältää joukon tunnisteita, jotka lisätään kaikkiin resursseihin. Esimerkissämme kustomize määrittää resursseille tunnisteen, jolla on nimi environment ja merkitys development.

Jos käyttäjä tekee kustomize build . hakemistossa tiedoston kanssa kustomization.yaml ja tarvittavat resurssit (eli tiedostot deployment.yaml и service.yaml), niin tulosteessa se vastaanottaa tekstin, jossa on määritetyt muutokset kustomization.yaml.

Huomautus. käännös: Kuvitus projektin dokumentaatiosta kustomizen "yksinkertaisesta" käytöstä

Tulos voidaan ohjata uudelleen, jos muutoksia on tehtävä:

kustomize build . > custom-config.yaml

Lähtötiedot ovat deterministisiä (sama syöttötieto tuottaa samat tulostulokset), joten sinun ei tarvitse tallentaa tulosta tiedostoon. Sen sijaan se voidaan siirtää suoraan toiseen komentoon:

kustomize build . | kubectl apply -f -

Kustomize-ominaisuuksiin pääsee myös kautta kubectl -k (Kubernetes-versiosta 1.14 lähtien). Muista kuitenkin, että erillinen kustomize-paketti päivitetään nopeammin kuin integroitu kubectl-paketti (ainakin Kubernetes 1.15 -julkaisun tapauksessa).

Lukijat saattavat kysyä: "Miksi tämä monimutkaisuus, jos voit muokata tiedostoja suoraan?" Hieno kysymys. Meidän esimerkissämme todellakin voidaan muodostaa muokata tiedostoja deployment.yaml и service.yaml suoraan, mutta entä jos ne ovat jonkun muun projektin haarukka? Tiedostojen muuttaminen suoraan vaikeuttaa (ellei mahdotonta) haarukan perustamista uudelleen, kun alkuperää/lähdettä muutetaan. Kustomizen avulla voit keskittää nämä muutokset tiedostoon kustomization.yaml, jättäen alkuperäiset tiedostot ennalleen ja helpottaen siten alkuperäisten tiedostojen uudelleen perustamista tarvittaessa.

Kustomizen edut näkyvät monimutkaisemmissa käyttötapauksissa. Yllä olevassa esimerkissä kustomization.yaml ja resurssit ovat samassa hakemistossa. Kustomize kuitenkin tukee käyttötapauksia, joissa on peruskokoonpano ja sen monia muunnelmia, jotka tunnetaan myös nimellä peittokuvat. Esimerkiksi käyttäjä halusi ottaa Deployment and Service for nginx, jota käytin esimerkkinä, ja luoda kehitys-, vaiheistus- ja tuotantoversiot (tai muunnelmat) näistä tiedostoista. Tätä varten hän tarvitsee edellä mainitut peittokuvat ja itse asiassa itse perusresurssit.

Havainnollistaa ajatusta peittokuvista ja taustalla olevista resursseista (perusresurssit), oletetaan, että hakemistoilla on seuraava rakenne:

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

Tiedostossa base/kustomization.yaml kenttää käyttävät käyttäjät resources yksinkertaisesti ilmoittaa resurssit, jotka kustomizen tulisi sisältää.

Jokaisessa tiedostossa overlays/{dev,staging,prod}/kustomization.yaml käyttäjät viittaavat kentän peruskokoonpanoon resourcesja ilmoita sitten tietyt muutokset kohteelle annettu ympäristö. Esimerkiksi tiedosto overlays/dev/kustomization.yaml saattaa näyttää aiemmin annetulta esimerkiltä:

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

Tässä tapauksessa tiedosto overlays/prod/kustomization.yaml voi olla täysin erilainen:

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

Kun käyttäjä juoksee kustomize build . luettelossa overlays/dev, kustomize luo kehitysvaihtoehdon. Jos juokset kustomize build . luettelossa overlays/prod - saat tuotantovaihtoehdon. Ja kaikki tämä - tekemättä muutoksia alkuperäiseen (perus) tiedostot, kaikki deklaratiivisella ja deterministisellä tavalla. Voit sitoa peruskokoonpanon ja peittohakemistot suoraan versionhallintaan tietäen, että näiden tiedostojen perusteella voit toistaa haluamasi kokoonpanon milloin tahansa.

Huomautus. käännös: Kuva projektidokumentaatiosta peittokuvien käytöstä kustomizessa

Mukauta voi lisää enemmän kuin mitä tässä artikkelissa käsitellään. Toivon kuitenkin, että se toimii hyvänä johdantona.

Lisäresurssit

Kustomizesta on monia hyviä artikkeleita ja julkaisuja. Tässä muutamia, joista pidin erityisen hyödyllisinä:

• Muuta YAML-peruskonfiguraatiota eri ympäristöissä tuote/testaus Kustomizen avulla;
• Kustomize – Oikea tapa tehdä mallinnus Kubernetesissa;
• Kubernetes-objektien deklaratiivinen hallinta mukauttamisen avulla;
• Ylävirran ruorikaavioiden mukauttaminen Customizella.

Huomautus. käännös: Voit myös suositella linkkilohkoa, joka on julkaistu nimellä Esittelymateriaalit apuohjelman verkkosivustolla, jota seuraa kokoelma videoita, joissa on viimeisimmät raportit kustomizesta.

Jos sinulla on kysyttävää tai ehdotuksia tämän materiaalin parantamiseksi, olen aina valmis antamaan palautetta. Voit ottaa minuun yhteyttä osoitteessa Twitter tai Kubernetes Slack -kanava. Pidä hauskaa manifestien muokkaamisessa kustomizen avulla!

PS kääntäjältä

Lue myös blogistamme:

• «Työkalut Kubernetes-sovellusten kehittäjille";
• «Kubernetes 1.14: Uuden kohokohdat";
• «Amsterdamin Helm Summit 2019 -tapahtuman viisi päätulosta";
• «Käytännön johdatus Kubernetesin paketinhallintaan - Helm'.

Lähde: will.com