Introduksjonsveiledning for Kubernetes-prosjektet

Denne YAML-utdraget viser hvordan et nytt namespace `glassproj-appname-acc` kan opprettes med omfattende konfigurasjoner ved hjelp av etiketter. Det er et bevis på hvordan Project Onboarding setter team i stand til å definere komplekse innstillinger uten friksjon, med fokus på utvikling og utrulling av applikasjoner.

### Nøkkelfunksjoner

- **Forenklet namespace-administrasjon**: Strømlinjeform oppretting og vedlikehold av Kubernetes-namespaces ved hjelp av etiketter.
- **Automatisering først**: Utnytt Namespace Configuration Operator til å automatisere håndheving av policyer, roller og kvoter basert på angitte etiketter.
- **Flerleietakermiljø gjort enkelt**: Sikre trygge og isolerte flerleietakermiljøer med tilpassbare nettverkspolicyer og ressurskvoter.
- **Kompatibilitet med OpenShift og Kubernetes**: Utformet for fleksibilitet; Project Onboarding integreres sømløst med både Kubernetes- og OpenShift-miljøer, støttet av Helm og Kustomize for en smidig oppsettprosess.

Project Onboarding er mer enn bare et verktøy; det er et nytt perspektiv på Kubernetes-administrasjon som inviterer deg til å tenke nytt om hvordan namespaces håndteres i infrastrukturen din. Det handler om å sette team i stand, styrke sikkerheten og fremme effektivitet gjennom intelligent automatisering.

## Namespace-konfigurasjoner

Denne automatiseringen utnytter [Namespace-konfigurasjonsoperatør](https://github.com/redhat-cop/namespace-configuration-operator) fra Red Hats Communities of Practice, et utmerket verktøy for å spore etiketter i namespaces og OpenShift-grupper eller -brukere, noe som gjør det til en hjørnestein i vår Project Onboarding.

Her er et glimt av hvordan disse ressursdefinisjonene for Namespace Configuration Operator er organisert innenfor strukturen til Project Onboarding:```text
.
└── namespace-configuration
    └── configuration
        ├── all
        │   └── NamespaceConfig
        │       ├── networkpolicies
        │       │   ├── networkpolicies-multitenancy.yaml
        │       │   └── networkpolicies-team.yaml
        │       │
        │       ├── resourcequotas
        │       │   ├── compute-limits-cpu-default.yaml
        │       │   ├── compute-limits-cpu.yaml
        │       │   ├── compute-limits-memory-default.yaml
        │       │   ├── compute-limits-memory.yaml
        │       │   ├── storage-csi-cinder-sc-delete-size.yaml
        │       │   ├── storage-csi-cinder-sc-retain-size.yaml
        │       │   ├── storage-global-size-limit.yaml
        │       │   └── storage-no-storage.yaml
        │       │
        │       └── rolebindings
        │           ├── rolebindings-team1.yaml
        │           ├── rolebindings-team2.yaml
        │           ├── rolebindings-team3.yaml
        │           └── rolebindings-team.yaml
        │
        └── clustertypeZ
            └── GroupConfig
                └── group-shared-namespace.yaml

### Nettverkspolicyer

Å implementere hensiktsmessige nettverkspolicyer er avgjørende for å opprettholde sikkerhet og isolasjon i en Kubernetes-klynge, spesielt når du er vert for flere kunder eller team. La oss se hvordan Project Onboarding håndterer nettverkspolicyer.

#### Nettverkspolicyer for multitenancy

- **`project-onboarding/networkpolicies-multitenancy`**

I Kubernetes-klynger med flere leietakere er det vanlig å begrense nettverkstrafikk mellom namespaces. Med mindre etiketten `project-onboarding/networkpolicies-multitenancy: false` er satt, vil disse nettverkspolicyene automatisk håndheves i navnerommet. Dette sikrer at nettverkstrafikk mellom ulike kunder eller team i samme klynge alltid rutes på riktig måte, og opprettholder strenge krav til sikkerhet og isolasjon.

#### Teamspesifikke nettverkspolicyer

- **`project-onboarding/networkpolicies-team`**

For å legge til rette for kommunikasjon mellom team på tvers av namespaces, bruk etiketten `project-onboarding/networkpolicies-team: teamname`, der du erstatter `teamname` med faktisk teamnavn (f.eks. `glassproj`). Dette muliggjør sømløst samarbeid mellom team-navnerom samtidig som nødvendig sikkerhet og isolasjon i klyngen opprettholdes.

### Rollebindinger

Å koble namespaces til brukergrupper er essensielt for å styre tilgang og sikre at team kan bruke sine tildelte navnerom effektivt. På grunn av begrensninger i mulighetene med etiketter har vi laget et enkelt system for dette.

- **`project-onboarding/team`**

Bruk etiketten `project-onboarding/team: groupname` for å gi administratorrettigheter til en gruppe i navnerommet. Denne etiketten forenkler prosessen med å gi et team tilgangsrettighetene de trenger i sitt navnerom.

For mer finmasket kontroll over tillatelser er følgende etiketter tilgjengelige:

- `project-onboarding/team1-name`
- `project-onboarding/team1-permissions`
- `project-onboarding/team2-name`
- `project-onboarding/team2-permissions`
- `project-onboarding/team3-name`
- `project-onboarding/team3-permissions`

Disse etikettene lar deg knytte en gruppe til spesifikke tillatelser i et navnerom. Selv om tillatelsene i utgangspunktet er begrenset til admin, edit og view, kan de tilpasses i den egendefinerte ressursen `namespaceConfig` for å støtte flere varianter ved behov.

### Ressurskvoter

Ressurskvoter er en kritisk del av ressursstyringen i Kubernetes-navnerom, og sikrer at hvert team eller prosjekt bare bruker sin rettmessige andel av ressursene, slik at andre ikke blir skadelidende. Project Onboarding forenkler dette ved at du kan definere ressurskvoter direkte via etiketter på navnerommet, noe som gjør det enkelt å styre grenser for CPU, minne og lagring på navneromsnivå.

#### Definere CPU- og minnekvoter

For å administrere beregningsressurser effektivt tilbyr Project Onboarding følgende etiketter:

- **`project-onboarding/compute-limits-cpu`**: Angir den totale mengden CPU-ressurser som kan brukes av alle podder i navnerommet. For eksempel vil verdien `"10"` tillate podder i navnerommet å bruke inntil 10 CPU-enheter.
- **`project-onboarding/compute-limits-memory`**: Bestemmer den totale mengden minne (RAM) som kan brukes av alle podder i navnerommet. Verdien `"8Gi"` tillater inntil 8 GiB minnebruk.

Disse kvotene sørger for at applikasjonene dine kjører effektivt uten å monopolisere klyngeressursene, og legger til rette for rettferdig ressursfordeling på tvers av alle navnerom.

#### Administrere lagringskvoter

Lagringshåndtering er en annen viktig del som dekkes av Project Onboarding. Følgende etiketter hjelper deg å definere lagringskvoter:

- **`project-onboarding/storage-size`**: Setter total mengde vedvarende lagring tilgjengelig for navnerommet. For eksempel vil `"50Gi"` avsette inntil 50 GiB vedvarende lagring på tvers av alle podder i navnerommet.

For mer finmasket kontroll over lagring basert på StorageClass, bruk:

- **`project-onboarding/storage-csi-cinder-sc-delete-size`** og **`project-onboarding/storage-csi-cinder-sc-retain-size`**: Disse etikettene lar deg angi lagringsgrenser per StorageClass, og gir fleksibilitet i håndteringen av lagringspolicyer og livssyklus.

Denne strukturen gjør det enkelt å tilpasse og administrere ressurskvoter, slik at Kubernetes-miljøene dine er optimalisert både for ytelse og ressursutnyttelse.

Ved å bruke Project Onboarding til å styre ressurskvoter kan du sikre en balansert ressursfordeling og legge til rette for et mer effektivt og rettferdig miljø for alle Kubernetes-arbeidslaster.

## Installere Namespace Configuration Operator og sette opp en servicekonto

Project Onboarding benytter Namespace Configuration Operator, som kan installeres via Operator Lifecycle Manager (OLM) eller som et Helm-diagram. Følgende veiledning fokuserer på installasjon fra `community-operators` CatalogSource, en kilde som er forhåndsinstallert i OKD/OpenShift-miljøer.

### Installere Namespace Configuration Operator

For å forenkle håndteringen av navnerom og relaterte konfigurasjoner i Kubernetes- eller OpenShift-klyngen din er Namespace Configuration Operator en kritisk komponent. Operatøren kan integreres sømløst i miljøet ditt ved hjelp av OLM eller Helm og gir en robust løsning for å automatisere bruk av etiketter og påfølgende konfigurasjon av navnerom basert på disse etikettene.

For installasjoner fra `community-operators` CatalogSource, som er lett tilgjengelig i OKD/OpenShift-klynger, kan du bruke en enkel fremgangsmåte med `oc`, kommandolinjeverktøyet for OpenShift. Denne metoden sikrer at operatøren blir distribuert riktig i klyngen, og muliggjør automatisk håndtering av navneromskonfigurasjoner.

For å installere Namespace Configuration Operator, kjør følgende kommando:```bash
oc apply -k ./namespace-configuration/operator

Denne kommandoen anvender konfigurasjonen for `all`-kategorien, som omfatter innstillinger og policyer ment for universell bruk på tvers av klyngene dine.

### Sette opp en servicekonto

Neste steg innebærer å sette opp en servicekonto som skal brukes til å opprette namespaces med de angitte labelene. Denne servicekontoen gir nødvendige tillatelser til å automatisere opprettelse og håndtering av namespaces, og sikrer at Namespace Configuration Operator kan fungere uten manuell inngripen.

For å sette opp servicekontoen, kjør:```bash
oc apply -k ./namespace-configuration/serviceaccount

Dette skriptet genererer en `kubeconfig`-fil konfigurert med tjenestekontoens token, som muliggjør sømløs autentisering for operasjoner som krever tilgang til klyngen.

### Fullføring

Med Namespace Configuration Operator installert og tjenestekontoen satt opp, er miljøet for prosjekt-onboarding nå klart. Denne oppsettet gjør det mulig å automatisere håndteringen av namespaces i klyngen din, strømlinjeforme onboarding-prosessen for nye namespaces og sikre konsekvent anvendelse av konfigurasjoner på tvers av Kubernetes- eller OpenShift-miljøet ditt.

## Administrere prosjekt-onboarding med ArgoCD

For en fleksibel tilnærming til håndtering av namespaces kan du vurdere å bruke Kustomize sammen med ArgoCD. Denne metoden innebærer et dedikert Git-repositorium for namespace-konfigurasjon, styrt enten via en kundeportal eller et automatiseringsverktøy. Dette repositoriet inneholder alle ønskede Kustomize YAML-endringer, som ArgoCD deretter anvender på klyngen din, og gir en balanse mellom manuelle tilpasningsmuligheter og robust revisjonssporing, tilstandsstyring og replay-muligheter.

Vurder å strukturere Git-repositoriet slik at det tillater unike konfigurasjoner per namespace. Denne strukturen støtter komplekse scenarier, for eksempel når et namespace krever spesifikke NetworkPolicy-er utover det som enkelt lar seg oppnå med en NamespaceConfig-tilpasset ressurs. I slike tilfeller kan du lage en dedikert NetworkPolicy-fil og referere til den i namespace-ets `kustomization.yaml`.

Nedenfor er et illustrerende eksempel på hvordan du kan organisere Git-repositoriet:```text
.
└── namespace-configuration
    └── examples
        ├── clustertypeX
        │   ├── businessarea51-labs-utv
        │   │   ├── kustomization.yaml
        │   │   └── namespace.yaml
        │   └── kustomization.yaml
        │
        ├── clustertypeZ
        │   ├── glassproj-appname-acc
        │   │   ├── kustomization.yaml
        │   │   └── namespace.yaml
        │   ├── glassproj-appname-sys
        │   │   ├── kustomization.yaml
        │   │   └── namespace.yaml
        │   ├── glassproj-appname-utv
        │   │   ├── kustomization.yaml
        │   │   └── namespace.yaml
        │   └── kustomization.yaml
        │
        └── kustomization.yaml