Introduktionsguide till Kubernetes-projektet

Detta YAML-exempel visar hur ett nytt namespace `glassproj-appname-acc` kan skapas med heltäckande konfigurationer med hjälp av etiketter. Det visar hur Project Onboarding ger team möjlighet att definiera komplexa inställningar utan krångel, med fokus på applikationsutveckling och utrullning.

### Nyckelfunktioner

- Förenklad hantering av namespaces: Effektivisera skapande och underhåll av Kubernetes-namespaces med hjälp av etiketter.
- Automation i första hand: Utnyttja Namespace Configuration Operator för att automatisera tillämpningen av policys, roller och kvoter baserat på angivna etiketter.
- Multi-tenancy gjort enkelt: Säkerställ säkra och isolerade multi-tenant-miljöer med anpassningsbara nätverkspolicys och resurskvoter.
- Kompatibilitet med OpenShift och Kubernetes: Utformat för flexibilitet; Project Onboarding integreras sömlöst med både Kubernetes- och OpenShift-miljöer, med stöd av Helm och Kustomize för en smidig installation.

Project Onboarding är mer än bara ett verktyg; det är ett nytt perspektiv på Kubernetes-hantering som uppmuntrar dig att ompröva hur namespaces hanteras i din infrastruktur. Det handlar om att möjliggöra för team, stärka säkerheten och främja effektivitet genom intelligent automatisering.

## Namespace-konfigurationer

Denna automatisering utnyttjar [Namespace Configuration Operator](https://github.com/redhat-cop/namespace-configuration-operator) från Red Hats Communities of Practice, ett utmärkt verktyg för att spåra etiketter i namespaces och i OpenShifts grupper eller användare, vilket gör det till en hörnsten i vår Project Onboarding.

Här är en inblick i hur dessa resursdefinitioner för Namespace Configuration Operator är organiserade inom Project Onboarding-strukturen:```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

### Nätverkspolicyer

Att implementera lämpliga nätverkspolicyer är avgörande för att upprätthålla säkerhet och isolering i ett Kubernetes-kluster, särskilt när du hostar flera kunder eller team. Låt oss se hur Project Onboarding hanterar nätverkspolicyer.

#### Nätverkspolicyer för multitenancy

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

I Kubernetes-kluster med flera tenants är det vanligt att begränsa nätverkstrafiken mellan namnrymder. Om inte etiketten `project-onboarding/networkpolicies-multitenancy: false` är applicerad kommer dessa nätverkspolicyer att verkställas automatiskt i namnrymden. Detta säkerställer att nätverkstrafik mellan olika kunder eller team inom samma kluster alltid routas på ett korrekt sätt, vilket upprätthåller strikta säkerhets- och isoleringsstandarder.

#### Teamspecifika nätverkspolicyer

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

För att möjliggöra kommunikation mellan team över olika namnrymder, använd etiketten `project-onboarding/networkpolicies-team: teamname` och ersätt `teamname` med det faktiska teamnamnet (t.ex. `glassproj`). Detta ger smidigt samarbete mellan teamens namnrymder samtidigt som nödvändig säkerhet och isolering i klustret upprätthålls.

### Rollbindningar

Att koppla namnrymder till användargrupper är viktigt för att hantera åtkomst och säkerställa att team effektivt kan använda sina tilldelade namnrymder. På grund av begränsningar i etikettfunktionalitet har vi tagit fram ett enkelt etiketteringssystem för detta ändamål.

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

Använd etiketten `project-onboarding/team: groupname` för att ge administratörsrättigheter till en grupp i namnrymden. Denna etikett förenklar processen att ge ett team de åtkomsträttigheter de behöver för sin namnrymd.

För mer finmaskig kontroll över behörigheter finns följande etiketter:

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

Dessa etiketter låter dig koppla en grupp till specifika behörigheter i en namnrymd. Även om behörigheterna initialt är begränsade till admin, edit och view kan de anpassas i den anpassade resursen `namespaceConfig` för att rymma fler varianter vid behov.

### Resurskvoter

Resurskvoter är en kritisk del av resursstyrning i dina Kubernetes-namnrymder. De säkerställer att varje team eller projekt bara förbrukar sin rättvisa andel, vilket förhindrar resursbrist för andra. Project Onboarding förenklar processen genom att låta dig definiera resurskvoter direkt via namnrymdsetiketter, vilket gör det enkelt att hantera CPU-, minnes- och lagringsbegränsningar på namnrymdsnivå.

#### Definiera CPU- och minneskvoter

För att effektivt hantera beräkningsresurser erbjuder Project Onboarding följande etiketter:

- **`project-onboarding/compute-limits-cpu`**: Anger den totala mängden CPU-resurser som alla poddar i namnrymden får förbruka. Om du till exempel sätter detta till `"10"` får poddar i namnrymden använda upp till 10 CPU-enheter.
- **`project-onboarding/compute-limits-memory`**: Bestämmer den totala mängden minne (RAM) som alla poddar i namnrymden får förbruka. Om denna etikett sätts till `"8Gi"` tillåts upp till 8 GiB minnesanvändning.

Dessa kvoter säkerställer att dina applikationer körs effektivt utan att monopolisera klusterresurser och underlättar en rättvis resursfördelning mellan alla namnrymder.

#### Hantera lagringskvoter

Lagringshantering är en annan viktig del som täcks av Project Onboarding. Följande etiketter hjälper dig att definiera lagringskvoter:

- **`project-onboarding/storage-size`**: Anger den totala mängden beständig lagring som är tillgänglig för namnrymden. Till exempel allokerar `"50Gi"` upp till 50 GiB beständig lagring fördelat över alla poddar i namnrymden.

För mer detaljerad kontroll av lagring baserat på StorageClass, använd:

- **`project-onboarding/storage-csi-cinder-sc-delete-size`** och **`project-onboarding/storage-csi-cinder-sc-retain-size`**: Dessa etiketter låter dig ange lagringsgränser per StorageClass och ger flexibilitet i hanteringen av lagringspolicyer och livscykel.

Denna struktur gör det enkelt att anpassa och hantera resurskvoter och säkerställer att dina Kubernetes-miljöer är optimerade för både prestanda och resursutnyttjande.

Genom att utnyttja Project Onboarding för resurskvotshantering kan du säkerställa en balanserad fördelning av resurser och främja en mer effektiv och rättvis miljö för alla dina Kubernetes-arbetslaster.

## Installera Namespace Configuration Operator och ställa in ett tjänstkonto

Project Onboarding använder Namespace Configuration Operator, som kan installeras via Operator Lifecycle Manager (OLM) eller som ett Helm chart. Följande guide fokuserar på installation från `community-operators` CatalogSource, en källa som är förinstallerad i OKD/OpenShift-miljöer.

### Installera Namespace Configuration Operator

För att underlätta hanteringen av namnrymder och relaterade konfigurationer i ditt Kubernetes- eller OpenShift-kluster är Namespace Configuration Operator en kritisk komponent. Denna operator kan sömlöst integreras i din miljö med OLM eller Helm och erbjuder en robust lösning för att automatisera tillämpningen av etiketter och den efterföljande konfigurationen av namnrymder baserat på dessa etiketter.

För installationer från `community-operators` CatalogSource, som finns tillgänglig i OKD/OpenShift-kluster, kan du använda en enkel metod med `oc`, OpenShift CLI-verktyget. Denna metod säkerställer att operatorn distribueras korrekt i ditt kluster och möjliggör automatisk hantering av namnrymdskonfigurationer.

För att installera Namespace Configuration Operator, kör följande kommando:```bash
oc apply -k ./namespace-configuration/operator

Detta kommando tillämpar konfigurationen för kategorin `all` och omfattar inställningar och policyer som är avsedda att gälla över alla dina kluster.

### Konfigurera ett servicekonto

Nästa steg är att konfigurera ett servicekonto som kommer att användas för att skapa namnrymder med de angivna etiketterna. Detta servicekonto ger de nödvändiga behörigheterna för att automatisera skapande och hantering av namnrymder, vilket säkerställer att Namespace Configuration Operator kan fungera utan manuell inblandning.

För att konfigurera servicekontot, kör:```bash
oc apply -k ./namespace-configuration/serviceaccount

Detta skript genererar en `kubeconfig`-fil som är konfigurerad med servicekontots token, vilket möjliggör sömlös autentisering för åtgärder som kräver klusteråtkomst.

### Slutförande

Med Namespace Configuration Operator installerad och servicekontot konfigurerat är din Project Onboarding-miljö nu redo. Denna konfiguration gör det möjligt att automatisera hanteringen av namespaces i ditt kluster, vilket effektiviserar onboarding-processen för nya namespaces och säkerställer konsekvent tillämpning av konfigurationer i hela din Kubernetes- eller OpenShift-miljö.

## Hantera Project Onboarding med ArgoCD

För ett flexibelt sätt att hantera namespaces kan du använda Kustomize tillsammans med ArgoCD. Denna metod innebär att man använder ett dedikerat git-repo för namespace-konfiguration, som hanteras antingen via en kundportal eller ett automationsverktyg. Detta repo innehåller alla önskade Kustomize-YAML-ändringar som ArgoCD sedan tillämpar på ditt kluster, vilket ger en balans mellan manuella anpassningsmöjligheter och robust granskning, tillståndshantering och återspelningsmöjligheter.

Överväg att strukturera ditt git-repo så att unika konfigurationer per namespace är möjliga. Denna struktur stödjer komplexa scenarier, till exempel när ett namespace kräver specifika nätverkspolicys utöver vad som enkelt kan åstadkommas med en NamespaceConfig-anpassad resurs. I sådana fall kan du skapa en dedikerad fil för nätverkspolicy och referera till den i namespace:ets `kustomization.yaml`.

Nedan följer ett illustrativt exempel på hur du kan organisera ditt git-repo:```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