Dołącz węzeł Flex do klastra AKS (wersja zapoznawcza)

Ważna

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi i wymagają zapisania się. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów, świadczoną w miarę możliwości. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

Po przygotowaniu klastra Azure Kubernetes Service (AKS), sieci, elastycznej puli węzłów, hosta i tożsamości uruchom hosta i dołącz go do puli docelowej.

W tym artykule dowiesz się:

  • Pobierz i zweryfikuj wersję węzła flex.
  • Uruchom hosta przy użyciu wybranej tożsamości Azure w celu pobrania danych nowej puli.
  • Sprawdź węzeł Kubernetes, maszynę Azure, stan sieci i usługę agenta.
  • Zweryfikuj rozmieszczenie obciążeń, wywołania zwrotne Kubernetes i łączność między węzłami.

Uruchom polecenia administracyjne opisane w tym artykule w środowisku Bash zgodnym z systemem Linux, które ma wymagane narzędzia i dostęp do sieci. Ten artykuł nazywa to środowisko Twoim środowiskiem Bash. Oddzielna maszyna dołączona do klastra to host węzła elastycznego; uruchamiaj na niej polecenia tylko wtedy, gdy dany krok wyraźnie to wskazuje.

W przypadku prywatnego klastra AKS uruchamiaj każde polecenie kubectl w środowisku Bash, które może rozpoznać nazwę i połączyć się z prywatnym serwerem API. Możesz uruchamiać polecenia Azure CLI, pobierania artefaktów, SSH i SCP w środowisku Bash, jeśli ma ono wymagany dostęp do platformy Azure i hosta. Sieć hosta elastycznego węzła musi również rozpoznawać i osiągać prywatny punkt końcowy interfejsu API.

Zanim rozpoczniesz

  • Ukończ konfigurowanie sieci i tworzenie elastycznej puli węzłów w AKS.
  • Ukończ przygotowywanie hosta i tożsamości węzła flex.
  • Zainstaluj Azure CLI, rozszerzenie aks-preview, wersję kubectl różniącą się o nie więcej niż jedną wersję pomocniczą od AKS_VERSION, jq, sha256sum, curl, klienta OpenSSH i scp w środowisku Bash.
  • W przypadku tożsamości zarządzanej lub jednostki usługi użyj konta Azure, które może pobierać dane uruchamiania dla wybranej puli węzłów flex.
  • Upewnij się, że środowisko Bash ma dostęp do hosta węzła Flex przez zatwierdzoną ścieżkę zarządzania SSH.
  • Upewnij się, że host węzła elastycznego może uzyskać dostęp przez protokół HTTPS do punktów końcowych artefaktów wydania i bootstrap zwróconych w danych inicjalizacji puli, usługi Azure Resource Manager, Microsoft Entra ID oraz wybranego punktu końcowego interfejsu API usługi AKS.

Note

Nie przechowuj poświadczeń, certyfikatów, kluczy prywatnych, tokenów dostępu, danych bootstrap ani zawartości kubeconfig w pliku środowiska udostępnionego.

Ładowanie środowiska wdrażania

Uruchom nową sesję Bash, zidentyfikuj plik środowiskowy i wczytaj go. Zastąp <deployment-name> etykietą wdrożenia używaną w poprzednich artykułach.

export FLEXNODE_DEPLOYMENT="<deployment-name>"
export FLEXNODE_ENV_FILE="${HOME}/.config/aks-flexnode/${FLEXNODE_DEPLOYMENT}.env"
test -s "${FLEXNODE_ENV_FILE}"
source "${FLEXNODE_ENV_FILE}"
export KUBECONFIG="${FLEXNODE_KUBECONFIG}"
install -d -m 0700 "${WORK_DIR:?Load the deployment environment first.}"

Plik zmiennych środowiskowych zawiera współdzielone wartości wdrożenia, z których korzysta ten artykuł, w tym WORK_DIR, katalog w Twoim środowisku Bash, w którym są zapisywane pobrane i wygenerowane pliki. Domyślnie WORK_DIR jest ~/.local/share/aksflexnode/<deployment-name>. Artykuł wyprowadza wszystkie inne zmienne, których potrzebuje. Jeśli plik środowiska nie został jeszcze utworzony, najpierw ukończ planowanie wdrożenia węzłów flex . Jeśli powłoka zgłosi błąd, nie przechodź do następnego kroku.

Ustaw aktywną subskrypcję i wyświetl cele Azure, Kubernetes i hostów:

az account set --subscription "${SUBSCRIPTION_ID}"

az aks show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --query "{Cluster:name,ResourceId:id,ApiServer:(privateFqdn || fqdn)}" \
    --output table

kubectl cluster-info

printf 'Recorded flex host: %s\n' "${FLEX_HOST_NAME}"
ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}" hostname

Upewnij się, że wartość parametru ResourceId jest zgodna z AKS_RESOURCE_ID, nazwa hosta płaszczyzny sterowania Kubernetes jest zgodna z parametrem ApiServer, a polecenie SSH zwraca FLEX_HOST_NAME. Jeśli którykolwiek z celów się nie zgadza, zatrzymaj się i popraw plik środowiska, kubeconfig lub cel SSH, zanim prześlesz lub uruchomisz pliki.

Pobierz i zweryfikuj wersję flex node

  1. Zidentyfikuj architekturę hosta i wybierz pasujące archiwum wydania.

    HOST_ARCH="$(ssh \
    -i "${SSH_PRIVATE_KEY_PATH}" \
    "${FLEX_HOST_SSH_TARGET}" \
    uname -m)"
export HOST_ARCH

case "${HOST_ARCH}" in
    x86_64) export AGENT_ARCH="amd64" ;;
    aarch64|arm64) export AGENT_ARCH="arm64" ;;
    *)
        printf 'Unsupported host architecture: %s\n' "${HOST_ARCH}" >&2
        false
        ;;
esac

export AGENT_ARCHIVE="aks-flex-node-linux-${AGENT_ARCH}.tar.gz"
printf 'Selected release archive: %s\n' "${AGENT_ARCHIVE}"

  2. Pobierz archiwum i manifest sum kontrolnych z wybranego wydania.

    curl --fail --location --silent --show-error \
    --proto '=https' \
    --tlsv1.2 \
    "https://github.com/Azure/AKSFlexNode/releases/download/${AKS_FLEX_NODE_VERSION}/${AGENT_ARCHIVE}" \
    --output "${WORK_DIR}/${AGENT_ARCHIVE}"

curl --fail --location --silent --show-error \
    --proto '=https' \
    --tlsv1.2 \
    "https://github.com/Azure/AKSFlexNode/releases/download/${AKS_FLEX_NODE_VERSION}/checksums.txt" \
    --output "${WORK_DIR}/checksums.txt"

  3. Wybierz dokładnie jeden wpis sumy kontrolnej dla archiwum i zweryfikuj plik.

    AGENT_CHECKSUM_ENTRY="$(awk \
    -v file="${AGENT_ARCHIVE}" \
    '$2 == file {print}' \
    "${WORK_DIR}/checksums.txt")"
export AGENT_CHECKSUM_ENTRY

test "$(printf '%s\n' "${AGENT_CHECKSUM_ENTRY}" |
    sed '/^$/d' |
    wc -l)" -eq 1

(
    cd "${WORK_DIR:?Load the deployment environment first.}"
    printf '%s\n' "${AGENT_CHECKSUM_ENTRY}" |
        sha256sum --check --strict -
)

export AGENT_SHA256="${AGENT_CHECKSUM_ENTRY%% *}"
test -n "${AGENT_SHA256}"

    Nie kontynuuj, chyba że polecenie sprawdzania sumy kontrolnej wskazuje, że archiwum jest OK.

  4. Pobierz skrypt inicjalizacyjny z tego samego tagu wersji i sprawdź poprawność jego składni w Bashu.

    curl --fail --location --silent --show-error \
    --proto '=https' \
    --tlsv1.2 \
    "https://raw.githubusercontent.com/Azure/AKSFlexNode/${AKS_FLEX_NODE_VERSION}/scripts/bootstrap.sh" \
    --output "${WORK_DIR}/bootstrap.sh"

chmod 0700 "${WORK_DIR}/bootstrap.sh"
bash -n "${WORK_DIR}/bootstrap.sh"

    W ramach tego wydania nie jest obecnie udostępniana oddzielna suma kontrolna dla tego skryptu. Pobierz go bez przekierowywania go potokiem do powłoki, zachowaj zgodność wersji ze zweryfikowanym archiwum agenta i przerwij, jeśli sprawdzenie składni zakończy się niepowodzeniem.

Pobierz aktualne dane inicjalizacyjne puli

Ścieżki uwierzytelniania z użyciem tożsamości zarządzanej i nazwy głównej usługi korzystają z danych początkowych, które pobierasz w środowisku Bash. Jeśli wybrano tożsamość zarządzaną usługi Azure Arc, pomiń tę sekcję. Polecenie bootstrap usługi Arc pobiera aktualne dane przy użyciu tożsamości maszyny Arc.

W przypadku tożsamości zarządzanej lub nazwy głównej usługi pobierz dane bezpośrednio przed przesłaniem plików do hosta. Odpowiedź zawiera token inicjalizacyjny, który wygasa po upływie godziny. Nie wyświetlaj odpowiedzi ani nie przechowuj jej w notatkach.

az aks nodepool get-bootstrap-data \
    --resource-group "${RESOURCE_GROUP}" \
    --cluster-name "${CLUSTER_NAME}" \
    --name "${FLEX_POOL_NAME}" \
    --output json \
    > "${WORK_DIR}/base-config.json"

chmod 0600 "${WORK_DIR}/base-config.json"
test -s "${WORK_DIR}/base-config.json"

Kontynuuj, gdy ${WORK_DIR}/base-config.json istnieje i nie jest pusty. Ukończ przenoszenie i inicjalizację hosta w ciągu godziny. Jeśli token wygaśnie, uruchom ponownie polecenie i zastąp stary plik.

Transferowanie plików i przygotowywanie hosta

  1. Utwórz niejawny plik przekazania hosta.

    {
    printf 'export AGENT_ARCHIVE=%q\n' "${AGENT_ARCHIVE}"
    printf 'export AGENT_SHA256=%q\n' "${AGENT_SHA256}"
    printf 'export AKS_FLEX_NODE_VERSION=%q\n' "${AKS_FLEX_NODE_VERSION}"
    printf 'export AKS_RESOURCE_ID=%q\n' "${AKS_RESOURCE_ID}"
    printf 'export FLEX_POOL_NAME=%q\n' "${FLEX_POOL_NAME}"
    printf 'export FLEX_HOST_PRIVATE_IP=%q\n' "${FLEX_HOST_PRIVATE_IP}"
    printf 'export HOST_IDENTITY_CLIENT_ID=%q\n' "${HOST_IDENTITY_CLIENT_ID:-}"
    printf 'export SP_TENANT_ID=%q\n' "${SP_TENANT_ID:-}"
    printf 'export SP_CLIENT_ID=%q\n' "${SP_CLIENT_ID:-}"
} > "${WORK_DIR}/host-bootstrap.env"

chmod 0600 "${WORK_DIR}/host-bootstrap.env"

  2. Skopiuj zweryfikowane pliki wydania i przekaż plik do hosta.

    scp -i "${SSH_PRIVATE_KEY_PATH}" \
    "${WORK_DIR}/${AGENT_ARCHIVE}" \
    "${WORK_DIR}/bootstrap.sh" \
    "${WORK_DIR}/host-bootstrap.env" \
    "${FLEX_HOST_SSH_TARGET}:/tmp/"

  3. W przypadku tożsamości zarządzanej lub nazwy głównej usługi skopiuj również chronione dane inicjalizacyjne:

    scp -i "${SSH_PRIVATE_KEY_PATH}" \
    "${WORK_DIR}/base-config.json" \
    "${FLEX_HOST_SSH_TARGET}:/tmp/"

  4. Połącz się z hostem i uruchom powłokę główną:

    ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}"
sudo -i

  5. Wczytaj niepoufne wartości przekazania i zweryfikuj przesłane pliki:

    source /tmp/host-bootstrap.env
chmod 0600 "/tmp/${AGENT_ARCHIVE}" /tmp/host-bootstrap.env
chmod 0700 /tmp/bootstrap.sh
bash -n /tmp/bootstrap.sh
printf '%s  %s\n' \
    "${AGENT_SHA256}" \
    "/tmp/${AGENT_ARCHIVE}" |
    sha256sum --check --strict -

    Kontynuuj, gdy polecenie sprawdzania sumy kontrolnej wskazuje, że archiwum jest OK. Zatrzymaj się, jeśli sprawdzenie sumy kontrolnej lub sprawdzenie składni skryptu nie powiedzie się.

  6. W przypadku tożsamości zarządzanej lub nazwy głównej usługi należy zainstalować dane początkowe:

    install -d -o root -g root -m 0700 /etc/aks-flex-node
install -o root -g root -m 0600 \
    /tmp/base-config.json \
    /etc/aks-flex-node/base-config.json
test -s /etc/aks-flex-node/base-config.json

Uruchamianie hosta

Wypełnij tylko sekcję odpowiadającą identyfikatorowi skonfigurowanemu w poprzednim artykule.

Tej sekcji używaj dopiero wtedy, gdy zasób maszyny Arc odpowiada hostowi SSH, stan himdsd to aktywny, weryfikacja HIMDS zwraca kod HTTP 200 dla tego konkretnego zasobu AKS oraz istnieje przypisanie roli ograniczone do zakresu AKS, co zweryfikowano w poprzednim artykule. Ta ścieżka pobiera aktualne dane inicjalizacyjne przy użyciu tożsamości maszyny Arc i nie używa pliku base-config.json ze środowiska powłoki Bash.

CONFIG_OVERRIDES="$(jq -cn \
    --arg nodeIP "${FLEX_HOST_PRIVATE_IP}" \
    '{node:{kubelet:{nodeIP:$nodeIP}}}')"
export CONFIG_OVERRIDES

bash /tmp/bootstrap.sh \
    --auth arc \
    --fetch-bootstrap-data \
    --cluster-resource-id "${AKS_RESOURCE_ID}" \
    --agent-pool-name "${FLEX_POOL_NAME}" \
    --agent-url "file:///tmp/${AGENT_ARCHIVE}" \
    --agent-sha256 "${AGENT_SHA256}" \
    --config-overrides "${CONFIG_OVERRIDES}"

Kontynuuj, gdy w danych wyjściowych pojawi się komunikat Arc preflight: OK, rejestracja maszyny zostanie ukończona, a skrypt bootstrapu zgłosi, że usługa agenta Flex Node została uruchomiona. Jeśli bootstrap nie może pobrać danych, sprawdź połączenie z usługą Arc, himdsd, przypisanie roli w zakresie AKS i dostęp hosta do Azure Resource Manager.

Usuwanie tymczasowych plików wydania

Po pomyślnym zakończeniu inicjalizacji usuń z hosta skrypt tymczasowy, archiwum i plik przekazania:

rm -f \
    "/tmp/${AGENT_ARCHIVE}" \
    /tmp/bootstrap.sh \
    /tmp/base-config.json \
    /tmp/host-bootstrap.env
exit
exit

Pierwszy exit pozostawia powłokę główną. Druga opcja zamyka sesję SSH i powoduje powrót do powłoki Bash.

Usuń duplikaty w środowisku Bash:

rm -f \
    "${WORK_DIR:?Load the deployment environment first.}/${AGENT_ARCHIVE}" \
    "${WORK_DIR}/bootstrap.sh" \
    "${WORK_DIR}/base-config.json" \
    "${WORK_DIR}/host-bootstrap.env" \
    "${WORK_DIR}/checksums.txt"

Zachowaj /etc/aks-flex-node i poświadczenie nazwy głównej usługi, dopóki host jest nadal dołączony. Działający agent używa tej konfiguracji do uzgadniania stanu węzła i maszyny platformy Azure.

Weryfikowanie węzła Kubernetes

Ustaw nazwę węzła na nazwę hosta systemu Linux zarejestrowaną w środowisku udostępnionym. Najpierw poczekaj na utworzenie obiektu Node, a następnie zaczekaj, aż stanie się gotowy:

export FLEX_NODE_NAME="$(printf '%s' "${FLEX_HOST_NAME}" | tr -d '[:space:]' | tr '[:upper:]' '[:lower:]')"

kubectl wait \
    --for=create \
    "node/${FLEX_NODE_NAME}" \
    --timeout=5m

kubectl wait \
    --for=condition=Ready \
    "node/${FLEX_NODE_NAME}" \
    --timeout=10m

kubectl get node "${FLEX_NODE_NAME}" -o wide

Kontynuuj, gdy węzeł ma wartość Ready. Jeśli węzeł nie zostanie utworzony lub nie stanie się gotowy, przed ponowieniu próby uruchomienia sprawdź dane wyjściowe bootstrap, łączność interfejsu API i usługę agenta.

Weryfikowanie zasobu maszyny Azure

  1. Wyświetl listę maszyn w docelowej puli węzłów flex.

    az aks machine list \
    --resource-group "${RESOURCE_GROUP}" \
    --cluster-name "${CLUSTER_NAME}" \
    --nodepool-name "${FLEX_POOL_NAME}" \
    --query "[].{name:name,state:properties.provisioningState,nodeName:properties.kubernetes.nodeName,version:properties.kubernetes.currentOrchestratorVersion}" \
    --output table

  2. Znajdź maszynę, która zarejestrowała przygotowany węzeł Kubernetes:

    FLEX_MACHINE_NAME="$(az aks machine list \
    --resource-group "${RESOURCE_GROUP}" \
    --cluster-name "${CLUSTER_NAME}" \
    --nodepool-name "${FLEX_POOL_NAME}" \
    --query "[?properties.kubernetes.nodeName=='${FLEX_NODE_NAME}'].name | [0]" \
    --output tsv)"
export FLEX_MACHINE_NAME

printf 'Machine: %s\n' "${FLEX_MACHINE_NAME}"

    Kontynuuj, gdy polecenie zwraca dokładnie jedną nazwę maszyny.

  3. Pokaż maszynę:

    az aks machine show \
    --resource-group "${RESOURCE_GROUP}" \
    --cluster-name "${CLUSTER_NAME}" \
    --nodepool-name "${FLEX_POOL_NAME}" \
    --machine-name "${FLEX_MACHINE_NAME}" \
    --output yaml

    Kontynuuj, gdy Maszyna istnieje, odwołuje się do FLEX_NODE_NAME i zgłasza pomyślny stan aprowizacji. Zapisz nazwę maszyny dla operacji związanych z cyklem życia:

    set_flexnode_env FLEX_MACHINE_NAME "${FLEX_MACHINE_NAME}"

Zweryfikuj połączenie sieciowe węzła Flex

  1. Wyświetl lokalizację Flex, CIDR poda i klucz publiczny WireGuard.

    kubectl get node "${FLEX_NODE_NAME}" \
    -L net.unbounded-cloud.io/site \
    -o wide

kubectl get node "${FLEX_NODE_NAME}" \
    -o jsonpath='{.metadata.name}{" site="}{.metadata.labels.net\.unbounded-cloud\.io/site}{" podCIDR="}{.spec.podCIDR}{" wg="}{.metadata.annotations.net\.unbounded-cloud\.io/wg-pubkey}{"\n"}'

  2. Sprawdź witryny i powiązane zasoby sieciowe Unbounded-Net.

    kubectl get \
    sites,sitenodeslices,gatewaypools,sitegatewaypoolassignments,gatewaypoolpeerings \
    -o wide

  3. Wyświetl pody Unbounded-Net przypisane do węzła flex.

    kubectl get pods --all-namespaces \
    --field-selector "spec.nodeName=${FLEX_NODE_NAME}" \
    -o wide

Nie kontynuuj walidacji obciążenia, chyba że:

  • Węzeł to Ready.
  • Jest to witryna Unbounded-Net Flex skonfigurowana w artykule o sieci.
  • CIDR podu należy do planowanego zakresu FLEX_POD_CIDR.
  • Klucz publiczny WireGuard został uzupełniony.
  • cluster-flex-private-l3 SitePeering odwołuje się do witryn cluster i flex-site.
  • Każdy zwracany zasobnik Unbounded-Net na węźle to Running.
  • W przypadku publicznej topologii WireGuard występuje oczekiwany peering puli bram.

Zweryfikuj agenta węzła Flex

Poczekaj do minuty, aż usługa stanie się aktywna. Jeśli tak nie jest, wyświetl stan usługi i najnowsze dzienniki:

ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}" \
    'set -euo pipefail
     for attempt in {1..12}; do
         if sudo systemctl is-active --quiet aks-flex-node-agent; then
             sudo systemctl show aks-flex-node-agent \
                 -p ActiveState \
                 -p SubState \
                 -p Result \
                 -p NRestarts
             exit 0
         fi
         sleep 5
     done

     sudo systemctl show aks-flex-node-agent \
         -p ActiveState \
         -p SubState \
         -p Result \
         -p NRestarts
     sudo journalctl -u aks-flex-node-agent --no-pager -n 80
     exit 1'

Kontynuuj, gdy dane wyjściowe zawierają ActiveState=active, SubState=running i Result=success.

Jeśli agent wielokrotnie uruchamia się ponownie, ponieważ nie może wyświetlić listy MachineOperation zasobów, wróć do tymczasowego kroku RBAC demona flex w sekcji Skonfiguruj sieć i utwórz pulę węzłów flex w usłudze AKS, sprawdź, czy rola i przypisanie istnieją, a następnie uruchom ponownie agenta:

ssh -i "${SSH_PRIVATE_KEY_PATH}" "${FLEX_HOST_SSH_TARGET}" \
    'sudo systemctl restart aks-flex-node-agent'

Zweryfikuj rozmieszczenie obciążeń roboczych i połączenia

Utwórz obciążenie robocze walidacji

Utwórz dedykowaną przestrzeń nazw. Jeśli ta przestrzeń nazw już istnieje, wyczyść poprzedni przebieg weryfikacji przed ponowieniu próby.

export VALIDATION_NAMESPACE="flex-node-validation"

if kubectl get namespace "${VALIDATION_NAMESPACE}" >/dev/null 2>&1; then
    printf 'Validation namespace already exists: %s\n' \
        "${VALIDATION_NAMESPACE}" >&2
    false
fi

kubectl create namespace "${VALIDATION_NAMESPACE}"
kubectl label namespace "${VALIDATION_NAMESPACE}" \
    app.kubernetes.io/managed-by=flex-node-article

Utwórz serwer HTTP, który harmonogram Kubernetesa umieści na węźle flex, i udostępnij go za pośrednictwem usługi ClusterIP:

kubectl --namespace "${VALIDATION_NAMESPACE}" run flex-http-server \
    --image=busybox:1.36 \
    --restart=Never \
    --labels app=flex-http \
    --overrides="{\"spec\":{\"nodeSelector\":{\"kubernetes.io/hostname\":\"${FLEX_NODE_NAME}\"},\"tolerations\":[{\"operator\":\"Exists\"}]}}" \
    --command -- sh -c \
    'mkdir -p /www; echo flex-network-ok >/www/index.html; exec httpd -f -p 8080 -h /www'

kubectl --namespace "${VALIDATION_NAMESPACE}" wait \
    --for=condition=Ready \
    pod/flex-http-server \
    --timeout=3m

kubectl --namespace "${VALIDATION_NAMESPACE}" expose pod flex-http-server \
    --name=flex-http-service \
    --port=8080 \
    --target-port=8080

Weryfikacja wywołań zwrotnych i łączności z usługą lokalną

Sprawdź dzienniki i wykonywanie poleceń przy użyciu ścieżki callback serwera API Kubernetes:

kubectl --namespace "${VALIDATION_NAMESPACE}" logs flex-http-server --tail=5
kubectl --namespace "${VALIDATION_NAMESPACE}" exec flex-http-server -- \
    sh -c 'printf "exec-callback-ok\n"'

Pobierz ClusterIP i wyślij żądanie do usługi z obciążenia roboczego węzła flex:

SERVICE_IP="$(kubectl --namespace "${VALIDATION_NAMESPACE}" \
    get service flex-http-service \
    --output jsonpath='{.spec.clusterIP}')"
export SERVICE_IP

kubectl --namespace "${VALIDATION_NAMESPACE}" exec flex-http-server -- \
    wget -qO- "http://${SERVICE_IP}:8080"

Oczekiwana odpowiedź to:

flex-network-ok

Zweryfikuj przekierowanie portów

W bieżącym terminalu przekaż port lokalny za pośrednictwem serwera interfejsu API Kubernetes. To polecenie używa środowiska wdrażania i narzędzia kubeconfig, które zostały załadowane wcześniej:

kubectl --namespace "${VALIDATION_NAMESPACE}" \
    port-forward pod/flex-http-server 18080:8080

W drugim terminalu zażądaj przekazanego punktu końcowego:

curl -fsS http://127.0.0.1:18080

Oczekiwana odpowiedź to flex-network-ok. Naciśnij klawisze Ctrl+C w pierwszym terminalu po sprawdzeniu.

Sprawdź łączność z węzła zarządzanego przez AKS

Znajdź gotowy węzeł systemu zarządzanego przez usługę AKS:

SYSTEM_NODE="$(kubectl get nodes \
    --selector agentpool=systempool \
    --output json |
    jq -r '
        .items[]
        | select(any(.status.conditions[];
            .type == "Ready" and .status == "True"))
        | .metadata.name
    ' |
    head -n 1)"
export SYSTEM_NODE

test -n "${SYSTEM_NODE}"
printf 'Managed-node test target: %s\n' "${SYSTEM_NODE}"

Uruchom zasobnik klienta na tym węźle i sprawdź, czy odpowiedź jest zgodna z oczekiwaniami:

kubectl --namespace "${VALIDATION_NAMESPACE}" run system-http-client \
    --image=busybox:1.36 \
    --restart=Never \
    --overrides="{\"spec\":{\"nodeSelector\":{\"kubernetes.io/hostname\":\"${SYSTEM_NODE}\"}}}" \
    --command -- sh -c \
    "test \"\$(wget -qO- http://${SERVICE_IP}:8080)\" = flex-network-ok"

kubectl --namespace "${VALIDATION_NAMESPACE}" wait \
    --for=jsonpath='{.status.phase}'=Succeeded \
    pod/system-http-client \
    --timeout=3m

kubectl --namespace "${VALIDATION_NAMESPACE}" \
    get pod flex-http-server system-http-client -o wide

Węzeł Kubernetes w stanie Ready wskazuje na rejestrację węzła. Samo w sobie nie potwierdza działania sieci obciążeń roboczych, operacji wywołań zwrotnych ani operacji cyklu życia platformy Azure.

Wyczyść obciążenie walidacji

Usuń tylko zasoby tymczasowe utworzone w tym artykule.

kubectl delete namespace "${VALIDATION_NAMESPACE}"

Następny krok

Następnie zarządzaj, aktualizuj, uaktualniaj lub usuń podłączony węzeł Flex.

  • Ostatnia aktualizacja o