Samouczek: wdrażanie konfiguracji przy użyciu metodyki GitOps w klastrze Kubernetes z włączoną usługą Azure Arc
Ważne
Ten samouczek jest przeznaczony dla metodyki GitOps z rozwiązaniem Flux v1. Metodyka GitOps z rozwiązaniem Flux v2 jest teraz dostępna dla klastrów Kubernetes z obsługą usługi Azure Arc i Azure Kubernetes Service (AKS); przejdź do samouczka dotyczącego metodyki GitOps z rozwiązaniem Flux v2. Zalecamy jak najszybszą migrację do platformy Flux w wersji 2 .
Obsługa zasobów konfiguracji klastra opartego na platformie Flux w wersji 1 utworzonego przed 1 stycznia 2024 r. zakończy się 24 maja 2025 r. Od 1 stycznia 2024 r. nie będzie można utworzyć nowych zasobów konfiguracji klastra opartych na platformie Flux w wersji 1.
W tym samouczku zastosujesz konfiguracje przy użyciu metodyki GitOps w klastrze Kubernetes z włączoną usługą Azure Arc. Omawiane tematy:
- Utwórz konfigurację w klastrze Kubernetes z włączoną usługą Azure Arc przy użyciu przykładowego repozytorium Git.
- Sprawdź, czy konfiguracja została pomyślnie utworzona.
- Zastosuj konfigurację z prywatnego repozytorium Git.
- Zweryfikuj konfigurację platformy Kubernetes.
Wymagania wstępne
Konto platformy Azure z aktywną subskrypcją. Utwórz bezpłatne konto.
Istniejący połączony klaster Kubernetes z włączoną usługą Azure Arc.
- Jeśli klaster nie został jeszcze połączony, zapoznaj się z przewodnikiem Szybki start Łączenie klastra Kubernetes z włączoną usługą Azure Arc.
Znajomość korzyści i architektury tej funkcji. Przeczytaj więcej w artykule Configurations and GitOps - Azure Arc-enabled Kubernetes (Konfiguracje i Metodyka GitOps — platforma Kubernetes z włączoną usługą Azure Arc).
Zainstaluj rozszerzenie interfejsu
k8s-configuration
wiersza polecenia platformy Azure w wersji >= 1.0.0:az extension add --name k8s-configuration
Porada
k8s-configuration
Jeśli rozszerzenie jest już zainstalowane, możesz zaktualizować je do najnowszej wersji przy użyciu następującego polecenia :az extension update --name k8s-configuration
Tworzenie konfiguracji
Przykładowe repozytorium używane w tym artykule ma strukturę wokół osoby operatora klastra. Manifesty w tym repozytorium aprowizują kilka przestrzeni nazw, wdrażają obciążenia i udostępniają konfigurację specyficzną dla zespołu. Za pomocą tego repozytorium z usługą GitOps tworzy następujące zasoby w klastrze:
- Przestrzenie nazw:
cluster-config
, ,team-a
team-b
- Wdrażania:
arc-k8s-demo
- ConfigMap:
team-a/endpoints
Sonduje config-agent
platformę Azure pod kątem nowych lub zaktualizowanych konfiguracji. Wykonanie tego zadania potrwa do 5 minut.
Jeśli kojarzysz repozytorium prywatne z konfiguracją, wykonaj poniższe kroki w temacie Zastosuj konfigurację z prywatnego repozytorium Git.
Interfejs wiersza polecenia platformy Azure
Użyj rozszerzenia interfejsu wiersza polecenia platformy Azure, k8s-configuration
aby połączyć połączony klaster z przykładowym repozytorium Git.
Nadaj tej konfiguracji
cluster-config
nazwę .Poinstruuj agenta, aby wdrożył operator w
cluster-config
przestrzeni nazw.Nadaj operatorowi
cluster-admin
uprawnienia.az k8s-configuration create --name cluster-config --cluster-name AzureArcTest1 --resource-group AzureArcTest --operator-instance-name cluster-config --operator-namespace cluster-config --repository-url https://github.com/Azure/arc-k8s-demo --scope cluster --cluster-type connectedClusters
{ "complianceStatus": { "complianceState": "Pending", "lastConfigApplied": "0001-01-01T00:00:00", "message": "{\"OperatorMessage\":null,\"ClusterState\":null}", "messageLevel": "3" }, "configurationProtectedSettings": {}, "enableHelmOperator": false, "helmOperatorProperties": null, "id": "/subscriptions/<sub id>/resourceGroups/<group name>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>/providers/Microsoft.KubernetesConfiguration/sourceControlConfigurations/cluster-config", "name": "cluster-config", "operatorInstanceName": "cluster-config", "operatorNamespace": "cluster-config", "operatorParams": "--git-readonly", "operatorScope": "cluster", "operatorType": "Flux", "provisioningState": "Succeeded", "repositoryPublicKey": "", "repositoryUrl": "https://github.com/Azure/arc-k8s-demo", "resourceGroup": "MyRG", "sshKnownHostsContents": "", "systemData": { "createdAt": "2020-11-24T21:22:01.542801+00:00", "createdBy": null, "createdByType": null, "lastModifiedAt": "2020-11-24T21:22:01.542801+00:00", "lastModifiedBy": null, "lastModifiedByType": null }, "type": "Microsoft.KubernetesConfiguration/sourceControlConfigurations" }
Korzystanie z publicznego repozytorium Git
Parametr | Format |
---|---|
--repository-url |
http[s]://serwer/repozytorium[.git] |
Używanie prywatnego repozytorium Git z protokołem SSH i kluczami utworzonymi za pomocą narzędzia Flux
Dodaj klucz publiczny wygenerowany przez narzędzie Flux do konta użytkownika u dostawcy usług Git. Jeśli klucz zostanie dodany do repozytorium zamiast konta użytkownika, użyj go git@
zamiast user@
adresu URL.
Przejdź do sekcji Zastosuj konfigurację z prywatnego repozytorium Git , aby uzyskać więcej informacji.
Parametr | Format | Uwagi |
---|---|---|
--repository-url |
ssh://user@server/repo[.git] lub user@server:repo[.git] |
git@ może zastąpić user@ |
Używanie prywatnego repozytorium Git z protokołem SSH i kluczami dostarczonymi przez użytkownika
Podaj własny klucz prywatny — bezpośrednio lub w pliku. Klucz musi być w formacie PEM i kończyć się nowym wierszem (\n).
Dodaj skojarzony klucz publiczny do konta użytkownika u dostawcy usług Git. Jeśli klucz zostanie dodany do repozytorium zamiast konta użytkownika, użyj go git@
zamiast .user@
Przejdź do sekcji Zastosuj konfigurację z prywatnego repozytorium Git , aby uzyskać więcej informacji.
Parametr | Format | Uwagi |
---|---|---|
--repository-url |
ssh://user@server/repo[.git] lub user@server:repo[.git] |
git@ może zastąpić user@ |
--ssh-private-key |
Klucz zakodowany w formacie base64 w formacie PEM | Podaj klucz bezpośrednio |
--ssh-private-key-file |
pełna ścieżka do pliku lokalnego | Podaj pełną ścieżkę do pliku lokalnego zawierającego klucz formatu PEM |
Używanie prywatnego hosta Git z protokołem SSH i znanymi hostami podanymi przez użytkownika
Operator Flux przechowuje listę typowych hostów Git w pliku znanych hostów, aby uwierzytelnić repozytorium Git przed ustanowieniem połączenia SSH. Jeśli używasz nietypowego repozytorium Git lub własnego hosta Git, możesz podać klucz hosta, aby platforma Flux mogła zidentyfikować repozytorium.
Podobnie jak klucze prywatne, możesz podać known_hosts zawartość bezpośrednio lub w pliku. W przypadku udostępniania własnej zawartości użyj specyfikacji formatu zawartości known_hosts wraz z jednym z powyższych scenariuszy klucza SSH.
Parametr | Format | Uwagi |
---|---|---|
--repository-url |
ssh://user@server/repo[.git] lub user@server:repo[.git] |
git@ może zastąpić user@ |
--ssh-known-hosts |
Kodowanie base64 | Bezpośrednie podawanie znanej zawartości hostów |
--ssh-known-hosts-file |
pełna ścieżka do pliku lokalnego | Udostępnianie znanej zawartości hostów w pliku lokalnym |
Używanie prywatnego repozytorium Git z protokołem HTTPS
Parametr | Format | Uwagi |
---|---|---|
--repository-url |
https://server/repo[.git] | Protokół HTTPS z podstawowym uwierzytelnianiem |
--https-user |
nieprzetworzone lub zakodowane w formacie base64 | Nazwa użytkownika HTTPS |
--https-key |
nieprzetworzone lub zakodowane w formacie base64 | Osobisty token dostępu https lub hasło |
Uwaga
- Pakiet operatorów helm w wersji 1.2.0 lub nowszej obsługuje prywatne uwierzytelnianie wersji programu Helm protokołu HTTPS.
- Wersja narzędzia Helm protokołu HTTPS nie jest obsługiwana w przypadku klastrów zarządzanych usługi AKS.
- Jeśli potrzebujesz usługi Flux, aby uzyskać dostęp do repozytorium Git za pośrednictwem serwera proxy, musisz zaktualizować agentów usługi Azure Arc przy użyciu ustawień serwera proxy. Aby uzyskać więcej informacji, zobacz Nawiązywanie połączenia przy użyciu serwera proxy ruchu wychodzącego.
Dodatkowe parametry
Dostosuj konfigurację przy użyciu następujących parametrów opcjonalnych:
Parametr | Opis |
---|---|
--enable-helm-operator |
Przełącz się, aby włączyć obsługę wdrożeń pakietu Helm. |
--helm-operator-params |
Wartości wykresu dla operatora programu Helm (jeśli jest włączone). Na przykład --set helm.versions=v3 . |
--helm-operator-chart-version |
Wersja wykresu dla operatora programu Helm (jeśli jest włączona). Użyj wersji 1.2.0 lub nowszej. Ustawienie domyślne: "1.2.0". |
--operator-namespace |
Nazwa przestrzeni nazw operatora. Ustawienie domyślne: "default". Maksymalna liczba znaków: 23 znaki. |
--operator-params |
Parametry dla operatora. Musi być podana w cudzysłowie pojedynczym. Na przykład --operator-params='--git-readonly --sync-garbage-collection --git-branch=main' |
Opcje obsługiwane w programie --operator-params
:
Opcja | Opis |
---|---|
--git-branch |
Gałąź repozytorium Git do użycia dla manifestów platformy Kubernetes. Wartość domyślna to "master". Nowsze repozytoria mają gałąź główną o nazwie main , w tym przypadku należy ustawić .--git-branch=main |
--git-path |
Ścieżka względna w repozytorium Git dla platformy Flux w celu zlokalizowania manifestów platformy Kubernetes. |
--git-readonly |
Repozytorium Git będzie traktowane jako tylko do odczytu. Flux nie będzie próbował napisać do niego. |
--manifest-generation |
Jeśli to ustawienie jest włączone, platforma Flux będzie szukać pliku flux.yaml i uruchomić narzędzie Kustomize lub inne generatory manifestów. |
--git-poll-interval |
Okres sondowania repozytorium Git pod kątem nowych zatwierdzeń. Wartość domyślna to 5m (5 minut). |
--sync-garbage-collection |
Jeśli to ustawienie jest włączone, platforma Flux usunie utworzone zasoby, ale nie są już obecne w usłudze Git. |
--git-label |
Etykieta do śledzenia postępu synchronizacji. Służy do tagowania gałęzi Git. Wartość domyślna to flux-sync . |
--git-user |
Nazwa użytkownika zatwierdzenia usługi Git. |
--git-email |
Email do użycia na potrzeby zatwierdzania usługi Git. |
Jeśli nie chcesz, aby aplikacja Flux zapisywała dane w repozytorium i --git-user
--git-email
nie jest ustawiona, zostanie --git-readonly
ustawiona automatycznie.
Aby uzyskać więcej informacji, zobacz dokumentację platformy Flux.
Uwaga
Funkcja Flux domyślnie synchronizuje się z master
gałęzią repozytorium Git. Jednak nowsze repozytoria Git mają gałąź główną o nazwie main
, w tym przypadku należy ustawić --git-branch=main
w parametrach --operator-params.
Porada
Konfigurację można utworzyć w Azure Portal na karcie GitOps zasobu Kubernetes z włączoną usługą Azure Arc.
Weryfikowanie konfiguracji
Użyj interfejsu wiersza polecenia platformy Azure, aby sprawdzić, czy konfiguracja została pomyślnie utworzona.
az k8s-configuration show --name cluster-config --cluster-name AzureArcTest1 --resource-group AzureArcTest --cluster-type connectedClusters
Zasób konfiguracji zostanie zaktualizowany o informacje o stanie zgodności, komunikatach i debugowaniu.
{
"complianceStatus": {
"complianceState": "Installed",
"lastConfigApplied": "2020-12-10T18:26:52.801000+00:00",
"message": "...",
"messageLevel": "Information"
},
"configurationProtectedSettings": {},
"enableHelmOperator": false,
"helmOperatorProperties": {
"chartValues": "",
"chartVersion": ""
},
"id": "/subscriptions/<sub id>/resourceGroups/AzureArcTest/providers/Microsoft.Kubernetes/connectedClusters/AzureArcTest1/providers/Microsoft.KubernetesConfiguration/sourceControlConfigurations/cluster-config",
"name": "cluster-config",
"operatorInstanceName": "cluster-config",
"operatorNamespace": "cluster-config",
"operatorParams": "--git-readonly",
"operatorScope": "cluster",
"operatorType": "Flux",
"provisioningState": "Succeeded",
"repositoryPublicKey": "...",
"repositoryUrl": "git://github.com/Azure/arc-k8s-demo.git",
"resourceGroup": "AzureArcTest",
"sshKnownHostsContents": null,
"systemData": {
"createdAt": "2020-12-01T03:58:56.175674+00:00",
"createdBy": null,
"createdByType": null,
"lastModifiedAt": "2020-12-10T18:30:56.881219+00:00",
"lastModifiedBy": null,
"lastModifiedByType": null
},
"type": "Microsoft.KubernetesConfiguration/sourceControlConfigurations"
}
Po utworzeniu lub zaktualizowaniu konfiguracji następuje kilka rzeczy:
- Usługa Azure Arc
config-agent
monitoruje usługę Azure Resource Manager pod kątem nowych lub zaktualizowanych konfiguracji (Microsoft.KubernetesConfiguration/sourceControlConfigurations
) i zauważa nowąPending
konfigurację. - Obiekt
config-agent
odczytuje właściwości konfiguracji i tworzy docelową przestrzeń nazw. - Usługa Azure Arc
controller-manager
tworzy konto usługi Kubernetes i mapuje je na clusterRoleBinding lub RoleBinding w celu uzyskania odpowiednich uprawnień (cluster
lubnamespace
zakresu). Następnie wdraża wystąpienie klasyflux
. - Jeśli używasz opcji SSH z kluczami generowanymi przez platformę Flux,
flux
generuje klucz SSH i rejestruje klucz publiczny. - Raportuje
config-agent
stan z powrotem do zasobu konfiguracji na platformie Azure.
Podczas procesu aprowizacji zasób konfiguracji przejdzie przez kilka zmian stanu. Monitoruj postęp za pomocą powyższego az k8s-configuration show ...
polecenia:
Zmiana etapu | Opis |
---|---|
complianceStatus ->Pending |
Reprezentuje stany początkowe i w toku. |
complianceStatus ->Installed |
config-agent pomyślnie skonfigurowano klaster i wdrożono flux go bez błędu. |
complianceStatus ->Failed |
config-agent wystąpił błąd podczas flux wdrażania elementu . Szczegóły są podane w complianceStatus.message treści odpowiedzi. |
Stosowanie konfiguracji z prywatnego repozytorium Git
Jeśli używasz prywatnego repozytorium Git, musisz skonfigurować klucz publiczny SSH w repozytorium. Podajesz lub platforma Flux generuje klucz publiczny SSH. Klucz publiczny można skonfigurować w określonym repozytorium Git lub na koncie użytkownika usługi Git, który ma dostęp do repozytorium.
Uzyskiwanie własnego klucza publicznego
Jeśli generujesz własne klucze SSH, masz już klucze prywatne i publiczne.
Uzyskiwanie klucza publicznego przy użyciu interfejsu wiersza polecenia platformy Azure
Zastosuj poniższe kroki w interfejsie wiersza polecenia platformy Azure, jeśli klucze są generowane przez narzędzie Flux.
az k8s-configuration show --resource-group <resource group name> --cluster-name <connected cluster name> --name <configuration name> --cluster-type connectedClusters --query 'repositoryPublicKey'
"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAREDACTED"
Uzyskiwanie klucza publicznego z witryny Azure Portal
Zapoznaj się z poniższymi instrukcjami w Azure Portal, jeśli flux generuje klucze.
- W witrynie Azure Portal przejdź do zasobu klastra połączonego.
- Na stronie zasobu wybierz pozycję "GitOps" i zobacz listę konfiguracji dla tego klastra.
- Wybierz konfigurację, która używa prywatnego repozytorium Git.
- W wyświetlonym oknie kontekstowym w dolnej części okna skopiuj klucz publiczny Repozytorium.
Dodawanie klucza publicznego przy użyciu usługi GitHub
Skorzystaj z jednej z następujących opcji:
Opcja 1. Dodawanie klucza publicznego do konta użytkownika (dotyczy wszystkich repozytoriów na koncie):
- Otwórz usługę GitHub i kliknij ikonę profilu w prawym górnym rogu strony.
- Kliknij pozycję Settings (Ustawienia).
- Kliknij klucze SSH i GPG.
- Kliknij pozycję Nowy klucz SSH.
- Podaj tytuł.
- Wklej klucz publiczny bez cudzysłowów.
- Kliknij pozycję Dodaj klucz SSH.
Opcja 2. Dodawanie klucza publicznego jako klucza wdrożenia do repozytorium Git (dotyczy tylko tego repozytorium):
- Otwórz usługę GitHub i przejdź do swojego repozytorium.
- Kliknij pozycję Settings (Ustawienia).
- Kliknij pozycję Wdróż klucze.
- Kliknij pozycję Dodaj klucz wdrażania.
- Podaj tytuł.
- Zaznacz pozycję Zezwalaj na dostęp do zapisu.
- Wklej klucz publiczny bez cudzysłowów.
- Kliknij pozycję Dodaj klucz.
Dodawanie klucza publicznego przy użyciu repozytorium usługi Azure DevOps
Aby dodać klucz do kluczy SSH, wykonaj następujące kroki:
- W obszarze Ustawienia użytkownika w prawym górnym rogu (obok obrazu profilu) kliknij pozycję Klucze publiczne SSH.
- Wybierz pozycję + Nowy klucz.
- Podaj nazwę.
- Wklej klucz publiczny bez cudzysłowów.
- Kliknij pozycję Dodaj.
Weryfikowanie konfiguracji platformy Kubernetes
Po config-agent
zainstalowaniu flux
wystąpienia zasoby przechowywane w repozytorium Git powinny zacząć przepływać do klastra. Sprawdź, czy przestrzenie nazw, wdrożenia i zasoby zostały utworzone za pomocą następującego polecenia:
kubectl get ns --show-labels
NAME STATUS AGE LABELS
azure-arc Active 24h <none>
cluster-config Active 177m <none>
default Active 29h <none>
itops Active 177m fluxcd.io/sync-gc-mark=sha256.9oYk8yEsRwWkR09n8eJCRNafckASgghAsUWgXWEQ9es,name=itops
kube-node-lease Active 29h <none>
kube-public Active 29h <none>
kube-system Active 29h <none>
team-a Active 177m fluxcd.io/sync-gc-mark=sha256.CS5boSi8kg_vyxfAeu7Das5harSy1i0gc2fodD7YDqA,name=team-a
team-b Active 177m fluxcd.io/sync-gc-mark=sha256.vF36thDIFnDDI2VEttBp5jgdxvEuaLmm7yT_cuA2UEw,name=team-b
Widzimy, że team-a
utworzono przestrzenie nazw , team-b
, itops
i cluster-config
.
flux
Operator został wdrożony w cluster-config
przestrzeni nazw zgodnie z zaleceniami zasobu konfiguracji:
kubectl -n cluster-config get deploy -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
cluster-config 1/1 1 1 3h flux docker.io/fluxcd/flux:1.16.0 instanceName=cluster-config,name=flux
memcached 1/1 1 1 3h memcached memcached:1.5.15 name=memcached
Dalsza eksploracja
Inne zasoby wdrożone w repozytorium konfiguracji można eksplorować przy użyciu następujących elementów:
kubectl -n team-a get cm -o yaml
kubectl -n itops get all
Czyszczenie zasobów
Usuń konfigurację przy użyciu interfejsu wiersza polecenia platformy Azure lub Azure Portal. Po uruchomieniu polecenia usuwania zasób konfiguracji zostanie natychmiast usunięty na platformie Azure. Pełne usunięcie skojarzonych obiektów z klastra powinno nastąpić w ciągu 10 minut. Jeśli konfiguracja jest w stanie niepowodzenia po usunięciu, pełne usunięcie skojarzonych obiektów może potrwać do godziny.
Po usunięciu konfiguracji z namespace
zakresem przestrzeń nazw nie jest usuwana przez usługę Azure Arc, aby uniknąć przerywania istniejących obciążeń. W razie potrzeby możesz ręcznie usunąć tę przestrzeń nazw przy użyciu polecenia kubectl
.
az k8s-configuration delete --name cluster-config --cluster-name AzureArcTest1 --resource-group AzureArcTest --cluster-type connectedClusters
Uwaga
Wszelkie zmiany w klastrze, które były wynikiem wdrożeń z śledzonego repozytorium Git, nie są usuwane po usunięciu konfiguracji.
Następne kroki
Przejdź do następnego samouczka, aby dowiedzieć się, jak zaimplementować ciągłą integrację/ciągłe wdrażanie za pomocą usługi GitOps.