자습서: pods의 보안 그룹 - Amazon EKS

자습서: pods의 보안 그룹

pods의 보안 그룹은 Amazon EC2 보안 그룹을 Kubernetes pods와 통합합니다. Amazon EC2 보안 그룹을 사용하여 여러 Amazon EC2 인스턴스 유형 및 Fargate 에서 실행 중인 노드에 배포하는 pods와의 인바운드 및 아웃바운드 네트워크 트래픽을 허용하는 규칙을 정의할 수 있습니다. 이 기능에 대한 자세한 설명은 pods의 보안 그룹 소개 블로그 게시물을 참조하세요.

고려 사항

pods의 보안 그룹을 배포하기 전에 다음 제한 사항 및 조건을 고려하세요.

  • pods의 보안 그룹은 Windows 노드에서 사용할 수 없습니다.

  • pods의 보안 그룹은 Amazon EC2 노드가 포함된 IPv6 패밀리용으로 구성된 클러스터에서 사용할 수 없습니다. 그러나 Fargate 노드만 포함하는 IPv6 패밀리용으로 구성된 클러스터가 있는 pods의 보안 그룹을 사용할 수 있습니다. 자세한 정보는 자습서: pods 및 services에 IPv6 주소 할당을 참조하십시오.

  • pods에 대한 보안 그룹은 대다수 Nitro 기반 Amazon EC2 인스턴스 패밀리에서 지원하지만, 패밀리의 모든 세대에서 지원하지는 않습니다. 예를 들면 m5, c5, r5, p3, m6g, c6gr6g 인스턴스 패밀리와 세대는 지원됩니다. t 패밀리의 인스턴스 유형은 지원되지 않습니다. 지원되는 인스턴스 유형의 전체 목록은 GitHub의 limits.go 파일을 참조하세요. 노드는 해당 파일에 IsTrunkingCompatible: true가 있는 나열된 인스턴스 유형 중 하나여야 합니다. 지원되는 인스턴스 유형에 대한 자세한 내용은 GitHub의 amazon-vpc-resource-controller-k8s에서 지원되는 EC2 인스턴스 유형을 참조하세요.

  • pod 보안 정책을 사용하여 pod 변형에 대한 액세스 권한을 제한하는 경우에는 psp가 할당된 role의 Kubernetes ClusterRoleBindingeks:vpc-resource-controller Kubernetes 사용자가 지정되어야 합니다. 기본 Amazon EKS psp, role 및 ClusterRoleBinding을 사용하는 경우 이는 eks:podsecuritypolicy:authenticated ClusterRoleBinding입니다. 예를 들어 다음 예와 같이 사용자를 subjects: 섹션에 추가합니다.

    ... subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated - apiGroup: rbac.authorization.k8s.io kind: User name: eks:vpc-resource-controller - kind: ServiceAccount name: eks-vpc-resource-controller
  • 사용자 지정 네트워킹 및 pods의 보안 그룹을 함께 사용하는 경우 ENIconfig에서 지정된 보안 그룹 대신 pods의 보안 그룹에서 지정한 보안 그룹이 사용됩니다.

  • 버전 1.10.2 이하의 Amazon VPC CNI 플러그인을 사용하고 pod 사양에 terminationGracePeriodSeconds 설정이 포함된 경우 설정 값은 0이 될 수 없습니다.

  • 버전 1.10 이하의 Amazon VPC CNI 플러그 인이나 기본 설정인 POD_SECURITY_GROUP_ENFORCING_MODE=strict로 버전 1.11를 사용하는 경우, externalTrafficPolicyLocal로 설정한 인스턴스 대상을 사용하는 유형 NodePortLoadBalancer의 Kubernetes 서비스는 보안 그룹을 할당하는 pods에서 지원하지 않습니다. 인스턴스 대상에 로드 밸런서를 사용하는 데 대한 자세한 내용은 Amazon EKS의 네트워크 로드 밸런싱 섹션을 참조하세요. POD_SECURITY_GROUP_ENFORCING_MODE=standard로 설정된 버전 1.11 이상의 플러그 인을 사용하는 경우 externalTrafficPolicyLocal로 설정한 인스턴스 대상은 지원됩니다.

  • 버전 1.10 이하의 Amazon VPC CNI 플러그 인이나 기본 설정인 POD_SECURITY_GROUP_ENFORCING_MODE=strict로 버전 1.11를 사용하는 경우, 소스 NAT는 보안 그룹이 할당된 pods에서 아웃바운드 트래픽에 대해 사용 중지되므로 아웃바운드 보안 그룹 규칙이 적용됩니다. 인터넷에 액세스하려면 보안 그룹이 할당된 pods는 NAT 게이트웨이 또는 인스턴스로 구성된 프라이빗 서브넷에 배포된 노드에서 실행해야 합니다. 퍼블릭 서브넷에 배포된 보안 그룹이 할당된 Pods는 인터넷에 액세스할 수 없습니다.

    POD_SECURITY_GROUP_ENFORCING_MODE=standard로 설정된 버전 1.11 이상의 플러그 인을 사용하는 경우 VPC 외부로 향하는 pod 트래픽은 인스턴스의 기본 네트워크 인터페이스의 IP 주소로 변환됩니다. 이 트래픽의 경우 pod's 보안 그룹의 규칙이 아닌 기본 네트워크 인터페이스에 대한 보안 그룹의 규칙이 사용됩니다.

  • 연결된 보안 그룹이 있는 pods를 통해 Calico 네트워크 정책을 사용하려면 버전 1.11.0 이상의 Amazon VPC CNI 플러그 인을 사용하고 POD_SECURITY_GROUP_ENFORCING_MODE=standard로 설정해야 합니다. 그렇지 않으면 연결된 보안 그룹이 있는 pods에서 주고받는 트래픽 흐름에는 Calico 네트워크 정책이 적용되지 않으며 Amazon EC2 보안 그룹으로만 적용이 제한됩니다. Amazon VPC CNI 버전을 업데이트하려면 Amazon VPC CNI plugin for Kubernetes 추가 기능 관리 섹션을 참조하세요.

  • Nodelocal DNSCache를 사용하는 클러스터에서 보안 그룹을 사용하는 Amazon EC2 노드에서 실행되는 Pods는 POD_SECURITY_GROUP_ENFORCING_MODE=standard로 설정된 버전 1.11.0 이상의 Amazon VPC CNI 플러그 인에서만 지원됩니다. Amazon VPC CNI 플러그 인 버전을 업데이트하려면 Amazon VPC CNI plugin for Kubernetes 추가 기능 관리 섹션을 참조하세요.

  • 포드의 보안 그룹은 변동이 많은 pods의 경우 pod 시작 지연 시간 증가로 이어질 수 있습니다. 이는 리소스 컨트롤러의 속도 제한 때문입니다.

pods용 보안 그룹의 Amazon VPC CNI plugin for Kubernetes 구성

pods의 보안 그룹 배포

Fargate pods의 보안 그룹만 사용하고 클러스터에 Amazon EC2 노드가 없는 경우 애플리케이션 예 배포로 건너뜁니다.

  1. 현재 Amazon VPC CNI plugin for Kubernetes 버전은 다음 명령을 통해 확인할 수 있습니다.

    kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3

    출력 예는 다음과 같습니다.

    v1.7.6

    Amazon VPC CNI plugin for Kubernetes 버전이 1.7.7 이하인 경우 플러그인을 버전 1.7.7 이상으로 업데이트합니다. 자세한 정보는 Amazon VPC CNI plugin for Kubernetes 추가 기능 업데이트을 참조하십시오.

  2. AmazonEKSVPCResourceController 관리형 IAM 정책을 Amazon EKS 클러스터에 연결된 클러스터 역할에 추가합니다. 정책을 사용하면 역할이 네트워크 인터페이스, 프라이빗 IP 주소, 네트워크 인스턴스의 연결 및 분리를 관리할 수 있습니다.

    1. 클러스터 IAM 역할의 이름을 검색하고 변수에 저장합니다. my-cluster를 클러스터 이름으로 바꿉니다.

      cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
    2. 정책을 역할에 연결합니다.

      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
  3. aws-node DaemonSet에서 ENABLE_POD_ENI 변수를 true로 설정하여 Amazon VPC CNI 추가 기능이 pods의 네트워크 인터페이스를 관리하도록 합니다. 이 설정이 true로 설정되면, 클러스터의 각 노드에 대해 추가 기능이 vpc.amazonaws.com/has-trunk-attached=true 값이 있는 레이블을 추가합니다. VPC 리소스 컨트롤러는 설명 aws-k8s-trunk-eni를 사용하여 트렁크 네트워크 인터페이스라는 하나의 특수 네트워크 인터페이스를 생성하고 연결합니다.

    kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
    참고

    트렁크 네트워크 인터페이스는 인스턴스 유형에서 지원하는 최대 네트워크 인터페이스 수에 포함됩니다. 인스턴스 유형별로 지원되는 최대 네트워크 인터페이스 수 목록은 Linux 인스턴스용 Amazon EC2 사용 설명서에서 인스턴스 유형별 네트워크 인터페이스당 IP 주소 섹션을 참조하세요. 노드에 이미 최대 수의 표준 네트워크 인터페이스가 연결되어 있는 경우 VPC 리소스 컨트롤러가 공간을 예약합니다. 컨트롤러가 표준 네트워크 인터페이스를 분리 및 삭제하고 트렁크 네트워크 인터페이스를 만든 다음 인스턴스에 연결할 수 있도록 실행 중인 pods를 축소해야 합니다.

    다음 명령을 사용하여 이 노드 중 어느 노드에 aws-k8s-trunk-enitrue로 설정되어 있는지 확인할 수 있습니다. No resources found가 반환된 경우 몇 초 정도 기다렸다가 다시 시도하세요. 이전 단계에서는 몇 초 정도 걸리는 Amazon VPC CNI plugin for Kubernetes pods를 다시 시작해야 합니다.

    kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true

    트렁크 네트워크 인터페이스가 만들어지면 트렁크 또는 표준 네트워크 인터페이스에서 pods에 보조 IP 주소를 할당합니다. 노드가 삭제되면 트렁크 인터페이스가 자동으로 삭제됩니다.

    이후 단계에서 pod에 대한 보안 그룹을 배포하면 VPC 리소스 컨트롤러가 aws-k8s-branch-eni의 설명과 함께 브랜치 네트워크 인터페이스라는 특수한 네트워크 인터페이스를 생성하고 거기에 보안 그룹을 연결합니다. 브랜치 네트워크 인터페이스는 노드에 연결된 표준 및 트렁크 네트워크 인터페이스와 함께 생성됩니다. 라이브니스 또는 준비 프로브를 사용하는 경우 kubelet이 TCP를 사용하여 브랜치 네트워크 인터페이스의 pods에 연결할 수 있도록 TCP 초기 demux를 사용 정지해야 합니다. TCP 초기 Demux를 비활성화하려면 다음 명령을 실행합니다.

    kubectl patch daemonset aws-node -n kube-system \ -p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
    참고

    POD_SECURITY_GROUP_ENFORCING_MODE=standard로 설정된 1.11.0 이상의 Amazon VPC CNI plugin for Kubernetes 추가 기능을 사용하는 경우 다음 단계에서 설명한 대로 이전 명령을 실행할 필요가 없습니다.

  4. 클러스터에서 NodeLocal DNSCache를 사용하거나, 자체 보안 그룹이 있는 pods를 통해 Calico 네트워크 정책을 사용하거나, 보안 그룹을 할당하려는 pods에 대해 externalTrafficPolicyLocal로 설정한 인스턴스 대상을 사용하는 NodePortLoadBalancer 유형의 Kubernetes 서비스가 있는 경우 버전 1.11.0 이상의 Amazon VPC CNI plugin for Kubernetes 추가 기능을 사용하고 있어야 하며 다음 설정을 활성화해야 합니다.

    kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
    중요
    • Pod 보안 그룹 규칙은 kubelet 또는 nodeLocalDNS와 같이 동일한 노드에 있는 pods 간 또는 pods와 services 간의 트래픽에 적용되지 않습니다.

    • pods에서 VPC 외부의 주소로 향하는 아웃바운드 트래픽은 인스턴스의 기본 네트워크 인터페이스의 IP 주소로 변환된 네트워크 주소입니다(AWS_VPC_K8S_CNI_EXTERNALSNAT=true로 설정하지 않은 경우 제외). 이 트래픽의 경우 pod's 보안 그룹의 규칙이 아닌 기본 네트워크 인터페이스에 대한 보안 그룹의 규칙이 사용됩니다.

    • 이 설정을 기존 pods에 적용하려면 pods 또는 pods가 실행되고 있는 노드를 다시 시작해야 합니다.

애플리케이션 예 배포

pods의 보안 그룹을 사용하려면 다음 절차에 설명된 대로 클러스터에 기존 보안 그룹과 Amazon EKS SecurityGroupPolicy 배포가 있어야 합니다. 다음 단계에서는 pod의 보안 그룹 정책을 사용하는 방법을 보여 줍니다. 달리 명시되지 않는 한, 변수가 터미널에 걸쳐 지속되지 않는 다음 단계에서 사용되므로 동일한 터미널에서 모든 단계를 완료합니다.

보안 그룹을 통해 pod 예 배포
  1. 리소스를 배포할 Kubernetes 네임스페이스를 생성합니다. 사용하려는 네임스페이스의 이름으로 my-namespace를 바꿀 수 있습니다.

    kubectl create namespace my-namespace
  2. Amazon EKS SecurityGroupPolicy를 클러스터에 배포합니다.

    1. 다음 콘텐츠를 디바이스에 복사합니다. 서비스 계정 레이블에 따라 pods를 선택하려는 경우 podSelectorserviceAccountSelector로 바꿀 수 있습니다. 두 선택기 중 하나만 지정해야 합니다. 비어 있는 podSelector(예: podSelector: {})는 네임스페이스의 모든 pods를 선택합니다. my-role을 자신의 역할 이름으로 변경할 수 있습니다. 비어 있는 serviceAccountSelector는 네임스페이스의 모든 서비스 계정을 선택합니다. my-security-group-policy를 자신의 SecurityGroupPolicy에 대한 이름으로 바꾸고 SecurityGroupPolicy를 생성하려는 네임스페이스로 my-namespace를 바꿀 수 있습니다.

      my_pod_security_group_id를 기존 보안 그룹의 ID로 바꿔야 합니다. 기존 보안 그룹이 없으면 하나를 생성해야 합니다. 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서Linux 인스턴스에 대한 Amazon EC2 보안 그룹을 참조하세요. 보안 그룹 ID는 1~5개를 지정할 수 있습니다. 둘 이상의 ID를 지정하면 모든 보안 그룹의 모든 규칙 조합이 선택한 pods에 적용됩니다.

      cat >my-security-group-policy.yaml <<EOF apiVersion: vpcresources.k8s.aws/v1beta1 kind: SecurityGroupPolicy metadata: name: my-security-group-policy namespace: my-namespace spec: podSelector: matchLabels: role: my-role securityGroups: groupIds: - my_pod_security_group_id EOF
      중요

      pod에 대해 지정한 보안 그룹 또는 그룹은 다음 기준을 충족해야 합니다.

      • 존재해야 합니다. 존재하지 않을 경우 선택기와 일치하는 pod를 배포하면 pod가 생성 프로세스에 계속 남아 있습니다. pod에 대해 설명하면 An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID 'sg-05b1d815d1EXAMPLE' does not exist와 유사한 오류 메시지가 표시됩니다.

      • 보안 그룹에서는 프로브를 구성한 모든 포트를 통해 노드에 적용된 보안 그룹의 인바운드 통신(kubelet의 경우)을 허용해야 합니다.

      • CoreDNS를 실행하는 pods(또는 pods가 실행되는 노드)에 할당된 보안 그룹에 대한 TCPUDP 포트 53을 통한 아웃바운드 통신을 허용해야 합니다. CoreDNS pods의 보안 그룹에서는 지정하는 보안 그룹의 인바운드 TCPUDP 포트 53 트래픽을 허용해야 합니다.

      • 통신하려면 필요한 다른 pods와 통신하는 데 필요한 인바운드 및 아웃바운드 규칙이 있어야 합니다.

      • Fargate에서 보안 그룹을 사용하는 경우 pods가 Kubernetes 컨트롤 플레인과 통신할 수 있는 규칙이 있어야 합니다. 이 작업을 수행할 수 있는 가장 쉬운 방법은 클러스터 보안 그룹을 보안 그룹 중 하나로 지정하는 것입니다.

      보안 그룹 정책은 새로 예약된 pods에만 적용되며, 실행 중인 pods에는 영향을 주지 않습니다.

    2. 정책을 배포합니다.

      kubectl apply -f my-security-group-policy.yaml
  3. 이전 단계에서 지정한 podSelectormy-role 값과 일치하는 레이블이 있는 샘플 애플리케이션을 배포합니다.

    1. 다음 콘텐츠를 디바이스에 복사합니다. 예제 값을 사용자 값으로 바꾼 다음 수정된 명령을 실행합니다. my-role을 바꾸는 경우 이전 단계에서 선택기에 지정한 값과 동일한지 확인합니다.

      cat >sample-application.yaml <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment namespace: my-namespace labels: app: my-app spec: replicas: 4 selector: matchLabels: app: my-app template: metadata: labels: app: my-app role: my-role spec: terminationGracePeriodSeconds: 120 containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.23 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: my-app namespace: my-namespace labels: app: my-app spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 80 EOF
    2. 다음 명령을 사용하여 애플리케이션을 배포합니다. 애플리케이션을 배포할 때 role 레이블과 일치하는 Amazon VPC CNI plugin for Kubernetes과 이전 단계에서 지정한 보안 그룹이 pod에 적용됩니다.

      kubectl apply -f sample-application.yaml
  4. 샘플 애플리케이션을 통해 배포된 pods를 봅니다. 이 주제의 나머지 부분에서는 이 터미널을 TerminalA로 언급합니다.

    kubectl get pods -n my-namespace -o wide

    출력 예는 다음과 같습니다.

    NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES my-deployment-5df6f7687b-4fbjm 1/1 Running 0 7m51s 192.168.53.48 ip-192-168-33-28.region-code.compute.internal <none> <none> my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal <none> <none> my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal <none> <none> my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal <none> <none>
    참고
    • pods가 Waiting 상태에서 멈춘 경우 kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace를 실행합니다. Insufficient permissions: Unable to create Elastic Network Interface.(권한 부족: 탄력적 네트워크 인터페이스를 생성할 수 없습니다.)가 표시되면 이전 단계에서 IAM 클러스터 역할에 IAM 정책을 추가했는지 확인합니다.

    • 포드가 Pending 상태로 멈춰 있는 경우 노드 인스턴스 유형이 limits.go에 나열되어 있고 인스턴스 유형에서 지원하는 최대 브랜치 네트워크 인터페이스 수의 제품에 노드 그룹의 노드 수를 곱한 값이 아직 충족되지 않았는지 확인합니다. 예를 들어 m5.large 인스턴스는 9개의 브랜치 네트워크 인터페이스를 지원합니다. 노드 그룹에 5개의 노드가 있는 경우 노드 그룹에 대해 최대 45개의 브랜치 네트워크 인터페이스를 생성할 수 있습니다. 배포하려는 46 번째 pod는 연결된 보안 그룹이 있는 다른 pod가 삭제될 때까지 Pending 상태로 남아 있습니다.

    kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace를 실행할 때 다음 메시지와 유사한 메시지가 표시될 경우 무시해도 됩니다. 이 메시지는 Amazon VPC CNI plugin for Kubernetes가 호스트 네트워킹을 설정하려고 할 때 네트워크 인터페이스가 생성되는 동안 실패할 경우 나타날 수 있습니다. 플러그인은 네트워크 인터페이스가 생성될 때까지 이 이벤트를 기록합니다.

    Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for pod "my-deployment-5df6f7687b-4fbjm": networkPlugin cni failed to set up pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container

    인스턴스 유형에서 실행할 수 있는 최대 pods 수를 초과할 수 없습니다. 각 인스턴스 유형에서 실행할 수 있는 최대 pods 수 목록은 GitHub의 eni-max-pods.txt를 참조하세요. 연결된 보안 그룹이 있는 pod를 삭제하거나 pod가 실행되고 있는 노드를 삭제하면 VPC 리소스 컨트롤러가 브랜치 네트워크 인터페이스를 삭제합니다. 보안 그룹에 대해 pods를 사용하는 pods가 있는 클러스터를 삭제하면 컨트롤러가 브랜치 네트워크 인터페이스를 삭제하지 않으므로 직접 삭제해야 합니다.

  5. 별도의 터미널에서 pods 중 하나에 셸을 적용합니다. 이 주제의 나머지 부분에서는 이 터미널을 TerminalB로 언급합니다. 5df6f7687b-4fbjm을 이전 단계의 결과에서 반환된 pods 중 하나의 ID로 바꿉니다.

    kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
  6. TerminalB의 셸에서 샘플 애플리케이션이 작동하는지 확인합니다.

    curl my-app

    출력 예는 다음과 같습니다.

    <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ...

    애플리케이션이 실행되는 모든 pods는 사용자가 생성한 보안 그룹과 연결되기 때문에 이 결과가 표시됩니다. 해당 그룹에는 보안 그룹이 연결되는 모든 pods 간에 모든 트래픽을 허용하는 규칙이 포함되어 있습니다. DNS 트래픽은 해당 보안 그룹에서 노드와 연결된 클러스터 보안 그룹으로 아웃바운드 트래픽이 허용됩니다. 노드가 pods에서 이름 조회를 수행한 CoreDNS pods를 실행하고 있습니다.

  7. 보안 그룹에서 클러스터 보안 그룹으로의 DNS 통신을 허용하는 보안 그룹 규칙을 TerminalA에서 제거합니다. 이전 단계에서 클러스터 보안 그룹에 DNS 규칙을 추가하지 않은 경우 $my_cluster_security_group_id를 사용자가 규칙을 생성한 보안 그룹의 ID로 바꿉니다.

    aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
  8. TerminalB에서 다시 애플리케이션에 액세스하려고 시도합니다.

    curl my-app

    출력 예는 다음과 같습니다.

    curl: (6) Could not resolve host: my-app

    pod에서 클러스터 보안 그룹을 연결해 주는 CoreDNS pods에 더 이상 액세스할 수 없기 때문에 이 시도는 실패합니다. 클러스터 보안 그룹에는 pod에 연결된 보안 그룹에서 DNS 통신을 허용하는 보안 그룹 규칙이 더 이상 없습니다.

    이전 단계에서 pods 중 하나에 대해 반환된 IP 주소를 사용하여 애플리케이션에 액세스하려고 시도하는 경우 보안 그룹이 연결되어 있는 pods 간에 모든 포트가 허용되고 이름 조회가 필요 없기 때문에 응답이 계속 표시됩니다.

  9. 실험이 끝나면 생성한 샘플 보안 그룹 정책, 애플리케이션 및 보안 그룹을 제거할 수 있습니다. TerminalA에서 다음 명령을 실행합니다.

    kubectl delete namespace my-namespace aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id wait sleep 45s aws ec2 delete-security-group --group-id $my_pod_security_group_id