En kort introduktion till Kustomize

Obs. övers.: Artikeln är skriven av Scott Lowe — en erfaren ingenjör inom IT, som är författare eller medförfattare till sju tryckta böcker (för det mesta om VMware vSphere). Han arbetar nu på dess dotterbolag VMware — Heptio (förvärvat 2016), med fokus på molnberäkningar och Kubernetes. Texten utgör en kort och lättförståelig introduktion till konfigurationshantering för Kubernetes med hjälp av tekniken Kustomize, som nyligen har blivit en del av K8s.

Kustomize är ett verktyg som låter användare "anpassa enkla och mallfria YAML-filer för olika ändamål, medan original-YAML förblir oförändrat och användbart" (beskrivningen är direkt lånad från kustomize-repositoriet på GitHub). Kustomize kan anropas direkt eller, från och med Kubernetes 1.14, användas med kubectl -k för att få åtkomst till dess funktioner (även om i Kubernetes 1.15 en separat binär är nyare än funktionerna inbyggda i kubectl). (Obs. övers.: Med den senaste versionen av Kubernetes 1.16 kustomize endast manuellt via läget «about:debugging» och kräver tillämpning av en patch. även i kubeadm-verktyget.) I denna publikation vill jag introducera läsarna till grunderna i kustomize.

I sin enklaste form/användning är kustomize helt enkelt en uppsättning resurser (YAML-filer som definierar Kubernetes-objekt: Deployments, Services etc.) plus en lista med instruktioner om vilka ändringar som ska göras i dessa resurser. På samma sätt som make använder en uppsättning instruktioner som finns i Makefile, och Docker bygger en container baserat på instruktioner från Dockerfile, använder kustomize kustomization.yaml för att lagra föreskrifter om vilka ändringar användaren vill göra i uppsättningen resurser.

Här är ett exempel på en fil kustomization.yaml:

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

Jag kommer inte att försöka berätta om alla möjliga fält i filen kustomization.yaml (detta har skrivits bra om här), men jag ger en kort förklaring av ett specifikt exempel:

• Fältet resources anger vilka resurser som kustomize kommer att ändra. I detta fall kommer den att leta efter resurser i filerna deployment.yaml och service.yaml i sin katalog (vägar kan anges som fullständiga eller relativa vid behov).
• Fältet namePrefix ålägger kustomize att lägga till ett visst prefix (i detta fall — dev-) till attributet name för alla resurser som definieras i fältet resources. Så om det finns i Deployment name med värdet nginx-deployment, kommer kustomize att göra det till dev-nginx-deployment.
• Fältet namnrymd föreskriver att kustomize ska lägga till det angivna namnområdet till alla resurser. I det här fallet kommer Deployment och Service att hamna i namnområdet utveckling.
• Slutligen, fältet commonLabels innehåller en uppsättning etiketter som kommer att läggas till alla resurser. I vårt exempel kommer kustomize att tilldela resurserna en etikett med namnet miljö och värdet utveckling.

Om användaren kör kustomize build . i katalogen med filen kustomization.yaml och nödvändiga resurser (dvs. filer deployment.yaml och service.yaml), så får han text med ändringarna angivna i kustomization.yaml.

Obs. övers.: En illustration från projektets dokumentation om "enkel" användning av kustomize

Utdata kan omdirigeras om det är nödvändigt att spara ändringarna:

kustomize build . > custom-config.yaml

Utdata är deterministisk (om samma data matas in kommer samma resultat att genereras), så det är inte nödvändigt att spara resultatet i en fil. Istället kan det direkt överföras till ett annat kommando:

kustomize build . | kubectl apply -f -

Tillgång till kustomize-funktioner kan också fås genom kubectl -k (från och med version 1.14 av Kubernetes). Tänk på att det fristående paketet kustomize uppdateras snabbare än det som är integrerat i kubectl (åtminstone så är det fallet med Kubernetes version 1.15).

Läsare kan fråga: "Varför behövs alla dessa komplicerade saker, om man kan redigera filerna direkt?". Bra fråga. I vårt exempel skulle det faktiskt kan modifiera filerna deployment.yaml och service.yaml direkt, men vad händer om de är en fork av någon annans projekt? Att direkt ändra filerna komplicerar (om inte gör det omöjligt) rebase av forken, när ändringar görs i källan. Användning av kustomize möjliggör centralisering av dessa ändringar i filen kustomization.yaml, vilket lämnar originalfilerna oförändrade och därmed underlättar rebase av de ursprungliga filerna vid behov.

Fördelarna med kustomize blir uppenbara i mer komplexa användningsfall. I det tidigare exemplet kustomization.yaml och resurserna ligger i samma katalog. Men kustomize stödjer användningsscenarier där det finns en grundkonfiguration och många varianter av den, även kända som överlagringar. Till exempel ville användaren ta Deployment och Service för nginx, som jag använde som exempel, och skapa utvecklings-, staging- och produktionsversioner (eller varianter) av de filerna. För detta kommer han att behöva de ovannämnda overlays och själva basresurserna.

För att illustrera idén med overlays och basresurser (basresurser), låt oss anta att katalogerna har följande struktur:

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

I filen base/kustomization.yaml användare med hjälp av fältet resources deklarerar bara de resurser som kustomize ska inkludera.

I varje av filerna overlays/{dev,staging,prod}/kustomization.yaml refererar användare till den grundläggande konfigurationen i fältet resources, och anger sedan specifika ändringar för denna miljö. Till exempel kan filen overlays/dev/kustomization.yaml se ut som exemplet som angavs tidigare:

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

Samtidigt kan filen overlays/prod/kustomization.yaml vara helt annorlunda:

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

När användaren kör kustomize build . i katalogen overlays/dev, kommer kustomize att generera en utvecklingsvariant. Om du kör kustomize build . i katalogen overlays/prod — får du en produktionsvariant. Och allt detta — utan att göra några ändringar i de ursprungliga (bas) filer, och allt detta — på ett deklarativt och deterministiskt sätt. Du kan committa den grundläggande konfigurationen och overlay-katalogerna direkt till versionshanteringssystemet, väl medveten om att baserat på dessa filer kan den nödvändiga konfigurationen när som helst återskapas.

Obs. övers.: Illustration från projektets dokumentation om användning av overlays i kustomize.

Kustomize kan mycket mer än vad som beskrivs i denna artikel. Jag hoppas dock att den här artikeln kommer att fungera som en bra introduktion.

Ytterligare resurser

Det finns många bra artiklar och publikationer om kustomize. Här är några som jag tyckte var särskilt användbara:

• Ändra bas YAML-konfiguration för olika miljöer prod/test med Kustomize.;
• Kustomize — Det rätta sättet att göra templating i Kubernetes.;
• Deklarativ hantering av Kubernetes-objekt med Kustomize.;
• Anpassa upstream Helm-diagram med Kustomize..

Obs. övers.: Det kan också rekommenderas att läsa länkavsnittet som publicerades som Resurser på verktygets webbplats, och den efterföljande samlingen av videor med de senaste föreläsningarna om kustomize.

Om du har frågor eller förslag på förbättringar av detta material är jag alltid öppen för feedback. Du kan kontakta mig på Twitter eller i Slack-kanalen Kubernetes. Njut av att modifiera dina manifest med Kustomize!

P.S. från översättaren

Läs även i vår blogg:

• «Verktyg för utvecklare av applikationer som körs i Kubernetes»;
• «Kubernetes 1.14: översikt över de viktigaste nyheterna»;
• «Fem huvudpunkter från Helm Summit 2019 i Amsterdam»;
• «En praktisk introduktion till paketförvaltaren för Kubernetes — Helm».

Källa: habr.com