Cloud & Server Experts

Amazon VPC CNI wprowadza Enhanced Subnet Discovery

17 lipca 2024

Użytkownicy aktualizujący aplikacje przy użyciu Amazon Elastic Kubernetes Service (Amazon EKS) w AWS często napotykają na napędzane przez skale krytyczne wyczerpanie miejsca adresu IPv4.

Chcą maksymalizować użycie VPC CDRI i podsieci przewidzianych dla podów EKS bez wprowadzania dodatkowej złożoności operacyjnej. Wierzymy, że używanie miejsca adresowego IPv4 to długoterminowe rozwiązanie dla użytkowników, którzy chcą zbudować skalowane rozwiązania sieciowe. Rozumiemy jednak, że środowiska IPv4 mogą być wymuszone na użytkownikach Amazon EKS dzięki uzależnieniu od innych komponentów sieciowych i wsparciu aplikacji na IPv6. Z tego powodu Amazon EKS wprowadza support dla Enhanced Subnet Discovery, aby pomóc użytkownikom optymalizować konfigurację sieci i skalować klastry oparte na IPv4 bez wprowadzania złożoności operacyjnej.

Jak to działa?

Plugin Amazon VPC Container Network Interface (CNI) jest rozlokowany na każdym węźle procesu roboczego Amazon Elastic Compute Cloud (Amazon EC2) w klastrze EKS. Tworzy i dołącza Elastic Network Interfaces (ENI) do węzłów oraz przypisuje prywatne adresy IPv4 i IPv6 z VPC CIDR do każdego poda w klastrze EKS. Domyślnie VPC CNI przypisuje adresy IP do podów z tej samej podsieci co interfejs głównej sieci pracownika, co czasem określane jest jako “podsieć użytkowa”. Bez dodatkowej konfiguracji, węzły mogą przypisywać ENI z podsieci użytkowej, w której instancja EC2 została uruchomiona. Z nową funkcją VPC CNI rozszerzamy teraz możliwości “użytkowych podsieci”. Kiedy enhanced subnet discovery jest włączony, pod IP są automatycznie przydzielane ze wszystkich dostępnych podsieci/CDRI oznaczonych do użytku w VPC.

Nowe podsieci mogą być tworzone i oznaczone przy użyciu sprecyzowanego tagu “kubernetes.io/role/cni” i są integrowane do konfiguracji istniejącej sieci. Umożliwia to efektywne skalowanie aplikacji z minimalnymi zakłóceniami dla toczących się operacji.

Wymagania

Aby kontynuować, wymagania są następujące:

Konto AWS
Klaster EKS w wersji 1.25 lub nowszej – w opisie używamy wersji 1.29
Amazon VPC CNI w wersji 1.18.0 lub nowszej
Najnowsza wersja AWS Command Line Interface (AWS CLI) skonfigurowana na urządzeniu lub w AWS CloudShell
eksctl – proste narzędzie CLI do tworzenia i zarządzania klastrami EKS (wersja 0.165.0 lub nowsza)

Konfiguracja

export AWS_REGION=<YOUR_AWS_REGION> #Replace with your AWS Region 
export AWS_ACCOUNT=<YOUR_ACCOUNT> #Replace with your AWS Account number 
export CLUSTER_NAME=eks-enhsubsel-demo #Replace with your EKS cluster name

W opisie symulujemy przypadek wyczerpania IP poprzez stworzenie Amazon VPC z blokadą /24 CIDR, która dostarcza 256 adresów IP. Jest podzielona na trzy publiczne i trzy prywatne podsieci, z których każda jest przydzielona do blokady /27 CIDR (28 adresów IP), tak jak pokazano na poniższej ilustracji. Kiedy zakres VPC CIDR jest na wyczerpaniu, przypisujemy drugorzędny CIDR do VPC, a następnie tworzymy podsieci VPC z tagiem “kubernetes.io/role/cni”, aby VPC CNI mogło automatycznie odnaleźć i użyć nowych podsieci do przydzielenia adresów Pod IP.

export AWS_REGION=<YOUR_AWS_REGION> #Replace with your AWS Region export AWS_ACCOUNT=<YOUR_ACCOUNT> #Replace with your AWS Account number export CLUSTER_NAME=eks-enhsubsel-demo #Replace with your EKS cluster name

Zacznijmy od stworzenia klastra EKS z VPC CNI w wersji 1.18.0.

cat << EOF > cluster.yaml 
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_REGION}
  version: "1.29"

vpc:
  cidr: 10.0.0.0/24

addons:
  - name: vpc-cni
    version: 1.18.0
  - name: coredns
  - name: kube-proxy
    
managedNodeGroups:
  - name: ${CLUSTER_NAME}-mng
    instanceType: m6a.large
    privateNetworking: true
    minSize: 2
    desiredCapacity: 2
    maxSize: 5
EOF

eksctl create cluster -f cluster.yaml

Poczekaj na finalizację tworzenia klastra i upewnij się, że dodatek vpc-cni działa w klastrze.

aws eks describe-addon --addon-name vpc-cni --cluster-name $CLUSTER_NAME --region $AWS_REGION

{
    "addon": {
        "addonName": "vpc-cni",
        "clusterName": "eks-enhsubsel-demo",
        "status": "ACTIVE",
        "addonVersion": "v1.18.0-eksbuild.1",
        ....
    }
}

Jako że podsieci są przypisane do /27 CIDR, zauważ, że prywatne podsieci mają tylko kilka albo żadnych dostępnych adresów IP:

aws ec2 describe-subnets --region $AWS_REGION \
--filters Name=tag:Name,Values="eksctl-eks-enhsubsel-demo-cluster/SubnetPrivate*" \
--query "Subnets[].{VPC:VpcId,SubnetId:SubnetId,AvailableIPs:AvailableIpAddressCount}" \
--output table

-----------------------------------------------------------------------
|                           DescribeSubnets                           |
+--------------+----------------------------+-------------------------+
| AvailableIPs |         SubnetId           |           VPC           |
+--------------+----------------------------+-------------------------+
|  16          |  subnet-08411e385d62f29da  |  vpc-07f75e9b1d954689a  |
|  7           |  subnet-0755097835150b642  |  vpc-07f75e9b1d954689a  |
|  0           |  subnet-0975a78066e7e76d6  |  vpc-07f75e9b1d954689a  |
+--------------+----------------------------+-------------------------+

Wprowadź próbną aplikację i zasymuluj przypadek wyczerpania IP w klastrze EKS.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 50
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: 50m
EOF

W związku z niewystarczającymi IP, wiele podów jest w stanie ”ContainerCreating”, jako że Amazon VPC CNI jest niezdolne do alokacji adresów IP. Teraz sprawdźmy, jak możemy użyć funkcji Enhanced Subnet Discovery z VPC CNI, aby automatycznie odnaleźć nowe podsieci VPC z dostępnym miejscem IP i użyć jej do przydzielenia adresów IP dla podów k8s.

Amazon VPC wspiera nawet do pięciu drugorzędnych blokad IP CIDR, aby rozszerzyć miejsce VPC IP. Zacznij od dodania drugorzędnej blokady CIDR “10.1.0.0/16” do Amazon EKS VPC.

export EKS_VPC_ID=$(aws eks describe-cluster --name $CLUSTER_NAME \
--region $AWS_REGION --query "cluster.resourcesVpcConfig.vpcId" --output text)

aws ec2 associate-vpc-cidr-block --vpc-id $EKS_VPC_ID \
--cidr-block "10.1.0.0/16" --region $AWS_REGION

{
    "CidrBlockAssociation": {
        "AssociationId": "vpc-cidr-assoc-06515a22930a5d6e9",
        "CidrBlock": "10.1.0.0/16",
        "CidrBlockState": {
            "State": "associating"
        }
    },
    "VpcId": "vpc-07f75e9b1d954689a"
}

Poczekaj aż dołączanie się zakończy i zacznij tworzyć nowe podsieci VPC z drugorzędnej blokady CIDR. Tagujemy także podsieci z ”kubernetes.io/role/cni=1”, aby VPC CNI mogło je automatycznie odnaleźć.

aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \
--availability-zone "$AWS_REGION"a --cidr-block 10.1.0.0/19 \
--tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]"

aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \
--availability-zone "$AWS_REGION"b --cidr-block 10.1.32.0/19 \
--tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]"

aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \
--availability-zone "$AWS_REGION"c --cidr-block 10.1.64.0/19 \
--tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]"

W domyślnym ustawieniu VPC CNI przypisuje zarówno główne i drugorzędne adresy IP ENI z podsieci VPC przypisanej do interfejsu głównej podsieci węzła roboczego Amazon EKS.

aws ec2 describe-network-interfaces --region $AWS_REGION \
--query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \
--filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \
--output table

--------------------------------------------------------------------------------------
|                              DescribeNetworkInterfaces                             |
+-------------------------------------------+-------------------------+--------------+
|                   DNSName                 |           ID            |  PrimaryIP   |
+-------------------------------------------+-------------------------+--------------+
|  ip-10-0-0-155.us-west-2.compute.internal |  eni-07f66d0e6b2408fc7  |  10.0.0.155  |
+--------------------------------------------+------------------------+--------------+
||                                   SecondaryIPs                                    ||
|+-----------------------------------------------------------------------------------+|
||  10.0.0.155                                                                      ||
||  10.0.0.136                                                                      ||
||  10.0.0.140                                                                      ||
||  10.0.0.141                                                                      ||
||  10.0.0.145                                                                      ||
||  10.0.0.150                                                                      ||
||  10.0.0.135                                                                      ||
||  10.0.0.151                                                                      ||
||  10.0.0.148                                                                      ||
||  10.0.0.149                                                                      ||
|+-----------------------------------------------------------------------------------+|
  .........
|+----------------------------------------------------------------------------------+|
|                              DescribeNetworkInterfaces                             |
+--------------------------------------------+-------------------------+-------------+
|                   DNSName                  |           ID           |  PrimaryIP   |
+--------------------------------------------+-------------------------+--------------+
|  ip-10-0-0-102.us-west-2.compute.internal |  eni-087692b80786865e0  |  10.0.0.102  |
+--------------------------------------------+-------------------------+--------------+
||                                   SecondaryIPs                                    ||
|+-----------------------------------------------------------------------------------+|
||  10.0.0.102                                                                      ||
||  10.0.0.105                                                                      ||
||  10.0.0.110                                                                      ||
||  10.0.0.126                                                                      ||
||  10.0.0.124                                                                      ||
||  10.0.0.125                                                                      ||
||  10.0.0.118                                                                      ||
||  10.0.0.100                                                                      ||
||  10.0.0.116                                                                      ||
||  10.0.0.117                                                                      ||
|+-----------------------------------------------------------------------------------+|

Teraz sprawdź, czy nowa funkcja Enhanced Subnet Discovery jest włączona przez zmienną środowiska ”ENABLE_SUBNET_DISCOVERY” w dodatku Amazon VPC CNI. Aby to sprawdzić, możesz użyć kubectl.

kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY

ENABLE_SUBNET_DISCOVERY: true

Jak widać, Enhanced Subnet Discovery jest włączone domyślnie w wersji 1.18.0 Amazon VPC CNI i nowszej. Jeśli zmienna środowiska nie była ustawiona na true, możesz użyć kubctl lub AWS CLI do ustawienia tej konfiguracji:

kubectl set env daemonset aws-node -n kube-system ENABLE_SUBNET_DISCOVERY=true \
-c aws-node

aws eks update-addon --cluster-name $CLUSTER_NAME --region $AWS_REGION \
--addon-name vpc-cni \
--configuration-values '{"env":{"ENABLE_SUBNET_DISCOVERY":"true"}}'

Kiedy funkcja jest włączona, VPC CNI szuka podsieci VPC otagowanych ”kubernetes.io/role/cni” z dostępnym miejscem IP. Przypisuje dodatkowe ENI z tych podsieci do węzłów Amazon EKS, aby przypisać adresy IP do podów k8s. Jako że u nas dużo podów jest w stanie ”ContainerCreating”, VPC CNI automatycznie znalazło nowe podsieci z /19 CIDR i przypisało je do istniejących węzłów procesu roboczego. Możemy to zweryfikować przez następujące komendy:

kubectl get pods -o wide | grep ContainerCreating
<<EMPTY OUTPUT>>

Teraz, kiedy popatrzymy na ENI dołączone do węzłów procesu roboczego, zauważ, że dodatkowe ENI z drugorzędnej podsieci CIDR i pody są dołączone z przedziału 10.1.x.x IP.

aws ec2 describe-network-interfaces --region $AWS_REGION \
--query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \
--filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \
--output table
--------------------------------------------------------------------------------------
|                              DescribeNetworkInterfaces                             |
+-------------------------------------------+-------------------------+--------------+
|                   DNSName                 |           ID            |  PrimaryIP   |
+-------------------------------------------+-------------------------+--------------+
|  ip-10-0-0-152.us-west-2.compute.internal |  eni-0525ae09d044a6688  |  10.0.0.152  |
+--------------------------------------------+-------------------------+--------------+
||                                   SecondaryIPs                                    ||
|+-----------------------------------------------------------------------------------+|
||  10.0.0.152                                                                      ||
||  10.0.0.144                                                                      ||
||  10.0.0.154                                                                      ||
||  10.0.0.147                                                                      ||
||  10.0.0.133                                                                      ||
||  10.0.0.157                                                                      ||
||  10.0.0.153                                                                      ||
||  10.0.0.158                                                                      ||
||  10.0.0.146                                                                      ||
||  10.0.0.132                                                                      ||
|+-----------------------------------------------------------------------------------+|
|                              DescribeNetworkInterfaces                              |
+--------------------------------------------+-------------------------+--------------+
|                   DNSName                  |           ID            |  PrimaryIP   |
+--------------------------------------------+-------------------------+--------------+
|  ip-10-1-79-53.us-west-2.compute.internal  |  eni-0b2632fa77e9fbf68  |  10.1.79.53  |
+--------------------------------------------+-------------------------+--------------+
||                                   SecondaryIPs                                    ||
|+-----------------------------------------------------------------------------------+|
||  10.1.79.53                                                                       ||
||  10.1.78.231                                                                      ||
||  10.1.75.23                                                                       ||
||  10.1.81.171                                                                      ||
||  10.1.95.26                                                                       ||
||  10.1.86.60                                                                       ||
||  10.1.76.92                                                                       ||
||  10.1.65.140                                                                      ||
||  10.1.75.174                                                                      ||
||  10.1.94.30                                                                       ||
|+-----------------------------------------------------------------------------------+|

Clean-up

Aby uniknąć bieżących opłat, usuń zasoby klastrów EKS stworzonych w Twoim koncie AWS.

# Delete EKS cluster resources 
eksctl delete cluster -f cluster.yaml

Sprawy kluczowe

Dzielone podsieci

Używając tej funkcji w przypadku cross-account, gdzie VPC i podsieci są tworzone w centralnym koncie AWS i dzielone z uczestniczącym kontem AWS, aby rozmieścić klaster EKS powinieneś otagować podsieci w uczestniczącym koncie, gdzie klaster jest odpalony. Aby zobaczyć instrukcję, odwiedź Use shared VPC Subnets in Amazon EKS.

Custom networking

Custom networking, funkcja Amazon VPC CNI zapewnia opcjonalność dla problemu zużycia IP poprzez przypisanie Pod IP z drugorzędnych przestrzeni adresowych VPC IP. Kiedy custom networking jest włączone w VPC CNI, tworzy to drugorzędne ENI w podsieci zdefiniowanej pod customowym zasobem o nazwie ENIConfig, który zawiera alternatywny zakres podsieci CIDR stworzony z drugorzędnego VPC CIDR. VPC CNI przypisuje adresy Pods IP z zakresu CIDR zdefiniowanego w customowym zasobie ENIConfig. Co więcej, pody mogą używać innych grup bezpieczeństwa niż te z interfejsu głównej sieci węzłów. Z tego powodu mógłbyś brać pod uwagę custom networking, jeśli musisz włączać pody w innej sieci z innymi grupami bezpieczeństwa. W przeciwieństwie do custom networking, enhanced subnet discovery nie wymaga stworzenia customowego zasobu ENIConfig, przez co redukuje koszty ogólne konfiguracji. Custom networking jest nadrzędne, kiedy obie funkcje są włączone w VPC CNI.

Pod networking use cases

Możesz używać tej funkcji razem z innymi use case VPC CNI, takimi jak “SNAT for Pods”, “Security groups for Pods”, “Kubernetes network policies” i “Increase available IP addresses on a worker node”. Zobacz Choose Pod networking use cases, aby zobaczyć szczegółowe porównanie.

Podsumowanie

Pokazaliśmy Ci, jak Amazon VPC CNI based subnet discovery może dostarczać skalę i elastyczność przy dostosowywaniu alokacji adresów IPv4, aby dostosowywać wzrost klastrów EKS do niskich operacyjnych kosztów ogólnych. Pokazaliśmy, jak funkcja pozwala na przystosowalność do zmian w rozmiarze i upraszcza zarządzanie adresem IP przy wspieraniu dynamicznych potrzeb nowoczesnych środowisk IT. Zobacz Amazon EKS best practices guide, aby sprawdzić rekomendacje i dodatkowe warunki przy bezpiecznym skalowaniu klastrów EKS.

Aby zobaczyć instrukcje instalacji dla Amazon VPC CNI, zobacz przewodnik użytkownika Amazon EKS. Swoją opinię o pluginie VPC CNI możesz zostawić w komentarzu lub opisać ją w AWS Containers Roadmap na GitHubie.

źródło: AWS

Hostersi Sp. z o.o.

Jankowicka 7
44-200 Rybnik
Poland

NIP: 642-300-73-08
REGON: 240692928
KRS: 275333