Windowsowe workloady na prywatnym klastrze EKS
Starsze aplikacje w branży motoryzacyjnej zwykle działają w systemie Windows. Klienci chcą skalować te workloady na Kubernetes wraz z workloadami w systemie Linux.
Branża motoryzacyjna ma szczególnie wysoki standard bezpieczeństwa, a do obsługi workloadów można zastosować klaster Amazon Elastic Kubernetes Service (Amazon EKS) z prywatnym punktem końcowym.
W tym wpisie pokażemy jak można dodać węzeł roboczy systemu Windows do już istniejącego klastra Amazon EKS i jak przeprowadzić kompleksowy test, aby zapewnić pomyślne wykonanie workloadu kontenera systemu Windows. Skoncentrujemy się na sposobie działania procesu manual bootstrap węzła roboczego, aby to podejście można było dostosować do wdrożenia infrastruktury jako kodu (IaC). Pokażemy również, jak używać modułu Terraform EKS do dodawania węzła roboczego do klastra Amazon EKS.
Dodatkowo omówimy repozytorium implementujące kompletną prywatną konfigurację Amazon EKS z węzłami roboczymi Windows i Linux w Terraform, które jest dostępne jako część repozytorium AWS-Samples repository.
Po przeczytaniu tego wpisu będziesz wiedział jak migrować i uruchamiać obciążenia systemu Windows w klastrze EKS z węzłami, które komunikują się z control plane za pośrednictwem prywatnego punktu końcowego.
Podgląd rozwiązania
Przewodnik
W tym poście pokażemy jak wykonać następujące czynności:
- Włączyć obsługę systemu Windows w klastrze EKS.
- Utworzyć niezbędny skrypt EC2 user data script dla węzła roboczego systemu Windows.
- Zezwolić węzłom roboczym Windows na interakcję z wewnętrzną siecią klastra.
- Uruchomić instancję Windows EC2 ze skryptem danych użytkownika.
- Dodać niezbędne tagi do instancji EC2.
- Przeprowadzić kompleksowe testy na Windows Pod.
- Dodać obsługę Windows Support dla Amazon EKS w Terraform i dodać grupę węzłów Windows.
Wstępne wymagania
Oto wymagania wstępne do wykonania tego przewodnika:
- Konto AWS.
- Istniejący klaster Amazon EKS. Możesz skorzystać z przewodnika tworzenie klastra Amazon EKS, aby dowiedzieć się więcej o procesie tworzenia klastra.
- Włączony prywatny punkt końcowy i wyłączony publiczny punkt końcowy.
- Niezbędne punkty końcowe VPC zostały już utworzone. (Sprawdź punkty końcowe VPC dla prywatnych klastrów pod kątem wymaganych punktów końcowych).
- Klaster działa na obsługiwanej wersji platformy. Porównaj, jak włączyć obsługę systemu Windows w klastrze EKS, aby uzyskać szczegółowe informacje.
- Host bastion, który może być używany do rozwiązywania problemów i jest dostępny z Twojej stacji roboczej.
- kubectl jest zainstalowany na hoście bastion i ma dostęp do klastra EKS
- Dostęp do grup zabezpieczeń między hostem bastion a węzłami roboczymi w klastrze Amazon EKS.
Wskazówka: zalecamy utworzenie i używanie nowego VPC i Amazon EKS w celu ukończenia tego tutorialu. Procedury, takie jak modyfikowanie ConfigMap aws-auth w klastrze, mogą wpływać na inne węzły, użytkowników i obciążenia w klastrze. Korzystanie z nowego VPC i Amazon EKS pomoże zminimalizować ryzyko wpływu na inne aplikacje.
Klaster Amazon EKS, który jest wdrażany za pośrednictwem Terraform i spełnia już wszystkie te wymagania, jest dostępny jako część repozytorium przykładów AWS: private-eks-for-windows-workloads-with-terraform.
Włączanie obsługi systemu Windows w klastrze EKS
Obsługa systemu Windows dla istniejącego klastra EKS musi być włączona, postępując zgodnie z instrukcjami włączania obsługi systemu Windows w klastrze EKS. Jest to obowiązkowe, a niezbędne kroki są zależne od wersji platformy klastra EKS, która jest pokazana w dokumentacji. W tym poście zastosowano nową implementację obsługi systemu Windows, która jest w większości zintegrowana z control plane. Zalecane jest używanie klastra EKS z co najmniej wersją platformy eks.3 dla 1.21.
Utworzenie niezbędnego skryptu danych użytkownika (user data) EC2 dla węzła roboczego systemu Windows
Zoptymalizowany pod kątem EKS Windows AMI dostarczany przez AWS zawiera skrypty i pliki wykonywalne, które są potrzebne do przyłączenia węzłów do klastra EKS, gdy tylko będą gotowe.
W tym poście zostanie użyta wersja Windows zoptymalizowana pod kątem Amazon EKS.
C:\Program Files\Amazon\EKS\Start-EKSBootstrap.ps1
C:\Program Files\Kubernetes\kubelet.exe
C:\Program Files\Kubernetes\kube-proxy.exePlik Start-EKSBootstrap.ps1 uruchamia i konfiguruje niezbędne komponenty lokalne, takie jak kubelet i kube-proxy, aby dołączyć do danego klastra.
W węźle można użyć następującego polecenia, aby dołączyć do klastra EKS:
./Start-EKSBootstrap.ps1 -EKSClusterName "<EKS cluster name>" -APIServerEndpoint "<EKS API endpoint>" -Base64ClusterCA "<Certificate data>"
Nazwa klastra EKS: Nazwa Twojego klastra EKS
Punkt końcowy EKS API: prywatny punkt końcowy Twojego klastra EKS
Dane certyfikatu: autoryzowany certyfikat zakodowany w standardzie base64 klastra.
Skrypt bootstrap utworzy usługi Windows kubelet i kube-proxy w węźle i uruchomi je z podaną konfiguracją.
Uzyskiwanie danych punktu końcowego i certyfikatu danych EKS API (konsola)
- Otwórz konsolę EKS.
- W panelu nawigacyjnym, pod Amazon EKS, wybierz Clusters.
- Otwórz klaster w którym węzeł Windows ma zostać dodany.
- Na pasku nawigacyjnym wybierz Configuration.
- Na pasku wybierz Details
- Zanotuj wartość punktu końcowego serwera API i autoryzowanego certyfikatu.
Uzyskiwanie danych punktu końcowego EKS API (AWS CLI)
1. Otwórz wiersz poleceń na stacji roboczej lub hoście bastion, który ma dostęp do konta AWS, na którym działa klaster EKS.
2. Wykonaj polecenie:
aws eks describe-cluster --region --name --query "cluster.endpoint"
3. Zanotuj zwracaną wartość.
Uzyskiwanie certyfikatu danych EKS API (AWS CLI)
1. Otwórz wiersz poleceń na stacji roboczej lub hoście bastion, który ma dostęp do konta AWS, na którym działa klaster EKS.
2. Wykonaj polecenie:
aws eks describe-cluster --region --name --query "cluster.certificateAuthority"
3. Odpowiedź będzie miała format:
JSON
{ "data": "" }
4. Zanotuj wartość, która będzie w miejscu .
Poniżej znajduje się pełna zawartość danych użytkownika dla programu startowego instancji EC2:
<powershell>
cd '\Program Files\Amazon\EKS'
./Start-EKSBootstrap.ps1 -EKSClusterName '<EKS cluster name>' -APIServerEndpoint '<EKS API endpoint>' -Base64ClusterCA '<Certificate data>'
</powershell>Wstaw wartości dla <EKS API endpoint> & <Certificate data> z wartościami, które zostały zebrane w poprzednich krokach. Zanotuj zawartość danych użytkownika, ponieważ zostaną one wykorzystane w jednym z następnych kroków.
Zezwolenie węzłom roboczym Windows na interakcję z wewnętrzną siecią klastra
Role, które są dołączone do węzłów, zarówno w systemie Linux, jak i Windows, muszą mieć dostęp do zasobów wymaganych przez komponent kube-proxy. Dodatkowo muszą mieć dostęp do systemu ról klastra:node-proxy (szczegółowe informacje Core component roles). Takie powiązanie ról klastra już istnieje w klastrze EKS: eks:kube-proxy-windows.
Wykonaj następujące polecenie, aby zobaczyć szczegóły powiązania roli klastra:
kubectl get clusterrolebinding eks:kube-proxy-windows -o yaml
Aby umożliwić węzłom roboczym systemu Windows dostęp do niezbędnych składników sieciowych, dodaj poniższy fragment na końcu sekcji aws-auth ConfigMap jako część sekcji mapRoles w przestrzeni nazw kube-system:
- rolearn: arn:aws:iam::444455556666:role/Admin
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windowsZastąp rolearn swoim ARN dla roli węzła. Zobacz włączanie dostępu użytkownika i roli uprawnień IAM do klastra, aby uzyskać szczegółowe informacje na temat programu aws-auth ConfigMap.
Możesz również poprać przykład i odpowiednio go zmodyfikować:
curl -o aws-auth-cm-windows.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-10-29/aws-auth-cm-windows.yaml
Jednak ten przykład nie obejmuje żadnych dodatkowych ról ani użytkowników, które zostały już zdefiniowane jako część konfiguracji klastra.
Utworzenie instancji Windows EC2 ze skryptem użytkownika:
- Otwórz konsolę Amazon EC2.
- W panelu nawigacyjnym, pod Instances, wybierz Instances.
- Otwórz Launch Instances.
- Szukaj Windows_Server-2019-English-Core-EKS_Optimized.
- W panelu nawigacyjnym, wybierz Community AMIs.
- Zaznacz AMI, który pasuje do Twojej wersji Kubernetes. W przypadku Kubernetes w wersji 1.21 wyszukaj Windows_Server-2019-English-Core-EKS_Optimized-1.21.
- Wybierz preferowany typ instancji, na przykład t3.xlarge. Zapoznaj się z obsługą systemu Windows, aby uzyskać informacje o nieobsługiwanych typach instancji.
- Wybierz Configure Instance Details.
- W Network, wybierz prywatny VPC, w którym działa klaster EKS.
- Jako Subnet wybierz prywatną podsieć swojego klastra EKS.
- Dla roli IAM wybierz rolę, która jest już używana przez węzły robocze systemu Linux.
- Przewiń w dół do Advanced Details.
- Dla User data wprowadź skrypt danych użytkownika z ostatniego kroku.
- Wybierz Add Storage.
- Wybierz Add Tags.
- Zaznacz Add Tag.
- W polu Key, wpisz kubernetes.io/cluster/<nazwa-klastra>, ale zastąp <nazwa-klastra> nazwą swojego klastra.
- Dla Value, wprowadź owned.
- Wybierz Configure Security Group.
- W polu Assign a security group, wybierz Create a new security group.
- Wybierz opcję Type RDP i podaj identyfikator grupy zabezpieczeń hosta bastion jako źródło.
- Wybierz Add rule.
- Wybierz All Traffic i podaj identyfikator grupy zabezpieczeń węzłów roboczych systemu Linux jako źródło.
- Wybierz Add rule.
- Użyj portu 10250 i podaj identyfikator grupy zabezpieczeń klastra EKS jako Source.
- Wybierz Add rule.
- Użyj portu https i podaj identyfikator grupy zabezpieczeń klastra EKS jako Source.
- Wybierz Review and Launch.
- Po przejrzeniu konfiguracji wybierz Launch.
- Podaj istniejący klucz lub utwórz nową parę kluczy.
Upewnij się, że grupy zabezpieczeń dołączone do węzłów roboczych systemów Windows i Linux zezwalają na cały ruch między nimi w celu komunikacji między węzłami. Ponadto upewnij się, że grupy zabezpieczeń klastra EKS zezwalają na ruch https z grupy zabezpieczeń systemu Windows. Zobacz uwagi dotyczące grupy zabezpieczeń Amazon EKS, aby uzyskać szczegółowe informacje.
Tag jest niezbędny jako dodatkowa informacja dla skryptu bootstrap i jest dostępny za pośrednictwem metadanych instancji EC2.
Po kilku minutach instancja powinna zostać uruchomiona i powinna pojawić się jako część klastra EKS:
kubectl get nodes
Wykonanie kompleksowych testów
Zapoznaj się z tematem Wdrażanie przykładowej aplikacji w celu wdrożenia workloadu systemu Windows.
Modyfikowanie przykładowego workloadu Windows, aby móc wykonywać je w prywatnym środowisku EKS
- Pobierz plik eks-sample-deployment, który jest już przygotowany do uruchomienia w prywatnym klastrze EKS
- Wdróż przykładowey workload systemu Windows.
- Wdróż przykładową usługę systemu Windows dostarczoną przez Deploy a sample application.
Utworzy to prosty serwer sieciowy bez żadnej zależności od publicznego punktu końcowego i pochodzi z Webserver.yaml.
W przypadku wersji Windows AMI Windows_Server-2019-English-Core-EKS_Optimized-* obraz używany przez przykładowy workload jest już dostępny w węźle. Jeśli użyto innej wersji serwera Windows, upewnij się, że wartość „image” w definicji .yaml została zastąpiona poprawnym tagiem prawidłowej wersji jądra.
Po pomyślnym uruchomieniu workloadów i usług w klastrze, wykonaj następujące polecenia, aby przetestować konfigurację.
Testowanie wewnętrznego serwera WWW z Windows Pod:
- Otwórz wiersz poleceń na hoście bastion.
- Wykonaj następujące polecenie na hoście bastion.
kubectl exec -it -n eks-sample-app <windows-pod> powershell - Wykonaj następujące polecenia w PowerShell właśnie otwartego Windows Pod.
curl eks-sample-windows-service -UseBasicParsing - Żądanie powinno zwrócić odpowiedź z serwera WWW. Serwer sieciowy Windows potrzebuje kilku sekund, aby odpowiedzieć za pierwszym razem.
Wykonanie tych testów sprawdza poprawność następujących elementów:
- Rozpoznawanie DNS działa zgodnie z oczekiwaniami wewnątrz Windows Pod.
- Sieć między różnymi podsieciami i podami (DNS) działa zgodnie z oczekiwaniami.
- Obciążenia są uruchomione we właściwym węźle.
Dodawanie Windows Support dla Amazon EKS w Terraform i dodawanie grupy węzłów Windows.
Poniższe fragmenty kodu używają wersji 18.6.0 modułu Terraform eks i automatyzują kroki, które zostały wykonane ręcznie w tym poście. Pełny przykład roboczy można znaleźć w repozytorium aws-samples.
Włączanie Windows Support dla klastra EKS
Ten kod umożliwia klastrowi EKS uruchamianie workloadów systemu Windows przy użyciu plików additional_roles_aws_auth.yaml i vpc-resource-controller-configmap.yaml:
### Prerequisites for Windows worker node enablement
data "aws_eks_cluster_auth" "this" {
name = module.eks.cluster_id
}
locals {
kubeconfig = yamlencode({
apiVersion = "v1"
kind = "Config"
current-context = "terraform"
clusters = [{
name = module.eks.cluster_id
cluster = {
certificate-authority-data = module.eks.cluster_certificate_authority_data
server = module.eks.cluster_endpoint
}
}]
contexts = [{
name = "terraform"
context = {
cluster = module.eks.cluster_id
user = "terraform"
}
}]
users = [{
name = "terraform"
user = {
token = data.aws_eks_cluster_auth.this.token
}
}]
})
}
### Apply changes to aws_auth
### Windows worker node cluster enablement: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html
resource "null_resource" "apply" {
triggers = {
kubeconfig = base64encode(local.kubeconfig)
cmd_patch = <<-EOT
kubectl create configmap aws-auth -n kube-system --kubeconfig <(echo $KUBECONFIG | base64 --decode)
kubectl patch configmap/aws-auth --patch "${module.eks.aws_auth_configmap_yaml}" -n kube-system --kubeconfig <(echo $KUBECONFIG | base64 --decode)
kubectl get cm aws-auth -n kube-system -o json --kubeconfig <(echo $KUBECONFIG | base64 --decode) | jq --arg add "`cat yaml-templates/additional_roles_aws_auth.yaml`" '.data.mapRoles += $add' | kubectl apply --kubeconfig <(echo $KUBECONFIG | base64 --decode) -f -
kubectl apply --kubeconfig <(echo $KUBECONFIG | base64 --decode) -f yaml-templates/vpc-resource-controller-configmap.yaml
EOT
}
provisioner "local-exec" {
interpreter = ["/bin/bash", "-c"]
environment = {
KUBECONFIG = self.triggers.kubeconfig
}
command = self.triggers.cmd_patch
}
}Dynamicznie tworzenie Windows AMI ID
Systemy Amazon EKS optimized Windows AMIs są często publikowane z najnowszymi poprawkami bezpieczeństwa. Poniższy kod pobiera najbardziej aktualną Windows AMI, która jest dostępna w czasie wykonywania:
data "aws_ami" "win_ami" {
most_recent = true
owners = ["amazon"]
filter {
name = "name"
values = ["Windows_Server-2019-English-Core-EKS_Optimized-${var.eks_cluster_version}-*"]
}
}Tworzenie samodzielnie zarządzanej grupy węzłów Windows w module EKS:
Poniższy fragment kodu przedstawia przykład grupy self_managed_node_group systemu Windows, którą można dodać do istniejącej implementacji modułu EKS.
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "18.6.0"
...
self_managed_node_groups = {
windows = {
platform = "windows"
name = "windows"
public_ip = false
instance_type = var.instance_type_win
key_name = "<available-key-in-region>"
desired_size = var.desired_size_win
max_size = var.max_size_win
min_size = var.min_size_win
ami_id = data.aws_ami.win_ami.id
}
}
}Moduł Terraform eks używa szablonu skryptu bootstrap podobnego do tego użytego w tym wpisie. Zobacz windows_user_data.tpl, aby uzyskać szczegółowe informacje.
Czynności końcowe
Aby uniknąć ponoszenia przyszłych opłat, usuń utworzone zasoby. Jeśli ręcznie dodałeś instancję EC2 zgodnie z opisem w tym poście, możesz po prostu usunąć instancję EC2. Jeśli utworzyłeś klaster z połączonym kodem Terraform, możesz użyć następującego polecenia, aby usunąć zasoby zarządzane Terraform:
terraform destroy -var-file main-input.tfvars
Podsumowanie
W tym wpisie pokazaliśmy jak uruchomić węzły robocze z systemem Windows w prywatnym klastrze EKS. Pokazaliśmy także jak przeprowadzić dodanie węzła roboczego Windows i dostarczyliśmy niezbędny skrypt danych użytkownika dla instancji EC2. Ponadto pokazaliśmy, jak przetestować ogólną konfigurację EKS, aby sprawdzić, czy konfiguracja jest kompletna, a klaster może być używany do rzeczywistych workloadów.
Na koniec pokazaliśmy niezbędną implementację Terraform, aby umożliwić obsługę Windows i dodać grupę węzłów Windows. Repozytorium private-eks-for-windows-workloads-with-terraform uzupełnia ten wpis, zapewniając pełną implementację Terraform prywatnego klastra EKS, którego można użyć do rozpoczęcia uruchamiania workloadów systemu Windows w EKS.
źródło: AWS
44-200 Rybnik
Poland
REGON: 240692928
KRS: 275333
