고려 사항 필수 조건 네트워크 정책 구성 Stars Policy 데모 문제 해결 Kubernetes 네트워크 정책

클러스터에 Kubernetes 네트워크 정책 구성

기본적으로 클러스터의 Pods 또는 다른 네트워크의 Pods 및 리소스 사이에 IP 주소, 포트 또는 연결에 대해 Kubernetes에는 제한이 없습니다. Kubernetes 네트워크 정책을 사용하여 Pods에 대한 네트워크 트래픽을 제한할 수 있습니다. 자세한 내용은 Kubernetes 설명서의 네트워크 정책을 참조하세요.

클러스터에 버전 1.13 이하의 Amazon VPC CNI plugin for Kubernetes가 있는 경우 타사 솔루션을 구현하여 클러스터에 Kubernetes 네트워크 정책을 적용해야 합니다. 버전 1.14 이상의 플러그인으로 네트워크 정책을 구현할 수 있으므로 타사 솔루션을 사용할 필요가 없습니다. 이 주제에서는 타사 추가 기능을 사용하지 않고 클러스터에서 Kubernetes 네트워크 정책을 사용하도록 클러스터를 구성하는 방법을 알아봅니다.

Amazon VPC CNI plugin for Kubernetes의 네트워크 정책은 다음 구성에서 지원됩니다.

Amazon EKS 클러스터 버전 1.25 이상.
클러스터의 Amazon VPC CNI plugin for Kubernetes 버전 1.14 이상.
IPv4 또는 IPv6 주소에 대해 구성된 클러스터.
Pods용 보안 그룹에 네트워크 정책을 사용할 수 있습니다. 네트워크 정책을 사용하면 클러스터 내 모든 통신을 제어할 수 있습니다. Pods용 보안 그룹을 통해 Pod 내의 애플리케이션에서 AWS 서비스에 대한 액세스를 제어할 수 있습니다.
사용자 지정 네트워킹 및 접두사 위임에 네트워크 정책을 사용할 수 있습니다.

고려 사항

Amazon VPC CNI plugin for Kubernetes 사용을 통해 클러스터에 Amazon VPC CNI plugin for Kubernetes 네트워크 정책을 적용할 때 Amazon EC2 Linux 노드에만 정책을 적용할 수 있습니다. Fargate 또는 Windows 노드에는 정책을 적용할 수 없습니다.
클러스터에서 현재 타사 솔루션을 사용하여 Kubernetes 네트워크 정책을 관리하는 경우 Amazon VPC CNI plugin for Kubernetes에 동일한 정책을 사용할 수 있습니다. 하지만 동일한 정책을 관리하지 않도록 기존 솔루션을 제거해야 합니다.
여러 네트워크 정책을 동일한 Pod에 적용할 수 있습니다. 동일한 Pod를 선택한 둘 이상의 정책이 구성된 경우 모든 정책이 Pod에 적용됩니다.
네트워크 정책의 각 ingress: 또는 egress: 선택기에서 각 프로토콜의 고유한 포트 조합 최대 수는 24입니다.
Kubernetes 서비스의 경우 서비스 포트는 컨테이너 포트와 동일해야 합니다. 이름이 지정된 포트를 사용하는 경우 서비스 사양에도 같은 이름을 사용합니다.
Pod 시작 시 정책 적용

Amazon VPC CNI plugin for Kubernetes는 포드 프로비저닝과 병행하여 포드에 대한 네트워크 정책을 구성합니다. 새 포드에 대해 모든 정책이 구성될 때까지 새 포드의 컨테이너는 기본 허용 정책으로 시작됩니다. 이를 표준 모드라고 합니다. 기본 허용 정책은 새 포드를 오가는 모든 수신 및 송신 트래픽이 허용됨을 의미합니다.

VPC CNI DaemonSet의 aws-node 컨테이너에서 환경 변수 NETWORK_POLICY_ENFORCING_MODE를 strict로 설정하여 기본 네트워크 정책을 변경할 수 있습니다.
```
env:
  - name: NETWORK_POLICY_ENFORCING_MODE
    value: "strict"
```
NETWORK_POLICY_ENFORCING_MODE 변수가 strict로 설정되면 VPC CNI를 사용하는 포드는 기본 거부 정책으로 시작하고, 정책이 구성됩니다. 이를 엄격 모드라고 합니다. 엄격 모드에서는 클러스터에서 포드가 액세스해야 하는 모든 엔드포인트에 대한 네트워크 정책이 있어야 합니다. 이 요구 사항은 CoreDNS 포드에 적용됩니다. 호스트 네트워킹을 사용하는 포드에는 기본 거부 정책이 구성되어 있지 않습니다.
네트워크 정책 기능에서 policyendpoints.networking.k8s.aws라는 PolicyEndpoint 사용자 지정 리소스 정의(CRD)가 생성되고 이를 사용해야 합니다.사용자 지정 참조의 PolicyEndpoint 개체는 Amazon EKS에서 관리합니다. 이러한 리소스를 수정하거나 삭제해서는 안 됩니다.
인스턴스 역할 IAM 보안 인증 정보를 사용하는 포드를 실행하거나 EC2 IMDS에 연결하는 경우 EC2 IMDS에 대한 액세스를 차단하는 네트워크 정책을 주의하여 확인하세요. EC2 IMDS에 대한 액세스를 허용하려면 네트워크 정책을 추가해야 할 수도 있습니다. 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서의 인스턴스 메타데이터 및 사용자 데이터를 참조하세요.

서비스 계정에 대한 IAM 역할을 사용하는 포드는 EC2 IMDS에 액세스하지 않습니다.
Amazon VPC CNI plugin for Kubernetes는 각 포드의 추가 네트워크 인터페이스에 네트워크 정책을 적용하지 않고 각 포드의 기본 인터페이스(eth0)에만 적용합니다. 이는 다음 아키텍처에 영향을 미칩니다.
- ENABLE_V4_EGRESS 변수가 true로 설정된 IPv6 포드. 이 변수를 사용하면 IPv4 송신 기능을 통해 IPv6 포드를 클러스터 외부의 항목과 같이 IPv4 엔드포인트에 연결할 수 있습니다. IPv4 송신 기능은 로컬 루프백 IPv4 주소를 사용하여 추가 네트워크 인터페이스를 생성하여 작동합니다.
- Multus와 같은 체인 네트워크 플러그인을 사용하는 경우. 이러한 플러그인은 각 포드에 네트워크 인터페이스를 추가하므로 네트워크 정책은 체인 네트워크 플러그인에 적용되지 않습니다.
네트워크 정책 기능은 기본적으로 노드의 포트 8162를 지표에 사용합니다. 또한 이 기능은 상태 프로브에 포트 8163을 사용했습니다. 이러한 포트를 사용해야 하는 노드 또는 포드 내부에서 다른 애플리케이션을 실행하면 앱이 실행되지 않습니다. VPC CNI 버전 v1.14.1 이상에서는 다음 위치에서 이러한 포트 포트를 변경할 수 있습니다.
AWS Management Console
https://console.aws.amazon.com/eks/home#/clusters에서 Amazon EKS 콘솔을 엽니다.

왼쪽 탐색 창에서 클러스터를 선택한 다음 Amazon VPC CNI 추가 기능을 구성할 클러스터의 이름을 선택합니다.

추가 기능(Add-ons) 탭을 선택합니다.

추가 기능 상자의 오른쪽 상단에 있는 상자를 선택한 다음에 Edit(편집)를 선택합니다.

Configure name of addon(추가 기능 이름 구성) 페이지에서:

버전 드롭다운 목록에서 v1.14.0-eksbuild.3 이상 버전을 선택합니다.

선택적 구성 설정을 확장합니다.

구성 값에 JSON 키 "enableNetworkPolicy": 및 값 "true"를 입력합니다. 결과 텍스트는 유효한 JSON 객체여야 합니다. 이 키와 값이 텍스트 상자의 유일한 데이터인 경우 키와 값을 중괄호({})로 둘러쌉니다.

다음 예시에서는 네트워크 정책 기능이 활성화되어 있고, 네트워크 정책 로그가 활성화되어 있고, 네트워크 정책 로그가 Amazon CloudWatch Logs로 전송되었으며, 지표와 상태 프로브가 기본 포트 번호로 설정되어 있습니다.

{ "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true", "healthProbeBindAddr": "8163", "metricsBindAddr": "8162" } }
Helm
helm을 통해 Amazon VPC CNI plugin for Kubernetes를 설치한 경우 구성을 업데이트하여 포트를 변경할 수 있습니다.

다음 명령을 실행하여 포트를 변경합니다. 키 nodeAgent.metricsBindAddr 또는 키 nodeAgent.healthProbeBindAddr의 값에 각각 포트 번호를 설정합니다.

helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
kubectl
편집기에서 aws-node DaemonSet를 엽니다.

kubectl edit daemonset -n kube-system aws-node

VPC CNI aws-node 데몬 세트 매니페스트의 aws-network-policy-agent 컨테이너에 있는 args:의 다음 명령 인수에서 포트 번호를 바꿉니다.

- args: - --metrics-bind-addr=:8162 - --health-probe-bind-addr=:8163

필수 조건

최소 클러스터 버전

기존 Amazon EKS 클러스터. 배포하려면 Amazon EKS 시작하기 섹션을 참조하세요. 클러스터는 Kubernetes 버전 1.25 이상이어야 합니다. 클러스터는 다음 표에 나열된 Kubernetes 버전 및 플랫폼 버전 중 하나를 실행해야 합니다. 나열된 것보다 이후의 모든 Kubernetes 및 플랫폼 버전도 지원됩니다. 다음 명령에서 my-cluster를 본인의 클러스터 이름으로 바꾼 다음 수정된 명령을 실행하여 현재 Kubernetes 버전을 확인할 수 있습니다.


aws eks describe-cluster
              --name my-cluster --query cluster.version --output
              text

Kubernetes 버전	플랫폼 버전
`1.27.4`	`eks.5`
`1.26.7`	`eks.6`
`1.25.12`	`eks.7`

최소 VPC CNI 버전

클러스터의 Amazon VPC CNI plugin for Kubernetes 버전 1.14 이상. 다음 명령을 사용하여 현재 버전을 확인할 수 있습니다.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
버전이 1.14 이하인 경우 Amazon EKS 추가 기능 업데이트의 내용을 참조하여 버전을 1.14 이상으로 업그레이드합니다.
최소 Linux 커널 버전

노드의 Linux 커널 버전이 5.10 이상이어야 합니다. uname -r을 사용하여 커널 버전을 확인할 수 있습니다. Amazon EKS 최적화 Amazon Linux, Amazon EKS 최적화 가속 Amazon Linux AMI, Bottlerocket AMI의 최신 버전을 사용하는 경우 이미 필수 커널 버전이 설치되어 있습니다.

Amazon EKS 최적화 가속 Amazon Linux AMI 버전 v20231116 이상에는 커널 버전 5.10이 있습니다.

Kubernetes 네트워크 정책을 사용하도록 클러스터 구성

BPF 파일 시스템을 탑재합니다.

참고
클러스터가 버전 1.27 이상인 경우 모든 Amazon EKS 최적화 Amazon Linux 및 Bottlerocket AMI 1.27 이상에 이미 이 기능이 있습니다.
다른 모든 클러스터 버전의 경우 Amazon EKS 최적화 Amazon Linux를 v20230703 이상으로 업그레이드하거나 Bottlerocket AMI를 버전 v1.0.2 이상으로 업그레이드한 경우 이 단계를 건너뛸 수 있습니다.
1. 각 노드에 버클리 패킷 필터(BPF) 파일 시스템을 탑재합니다.
```
sudo mount -t bpf bpffs /sys/fs/bpf
```
2. 그런 다음 Amazon EC2 Auto Scaling 그룹용 시작 템플릿의 사용자 데이터에 동일한 명령을 추가합니다.
VPC CNI에서 네트워크 정책을 활성화합니다.
1. 클러스터에 설치된 추가 기능의 유형을 확인하세요. 클러스터를 생성하는 데 사용한 도구에 따라 현재 클러스터에 Amazon EKS 추가 기능이 유형이 설치되어 있지 않을 수 있습니다. my-cluster를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query addon.addonVersion --output text
```
  버전 번호가 반환되는 경우 Amazon EKS 유형의 추가 기능이 클러스터에 설치되고 본 절차의 나머지 단계를 완료할 필요가 없습니다. 오류가 번호가 반환되는 경우 Amazon EKS 유형의 추가 기능이 클러스터에 설치되지 않습니다.
2. - Amazon EKS 추가 기능
    AWS Management Console
    
    https://console.aws.amazon.com/eks/home#/clusters에서 Amazon EKS 콘솔을 엽니다.
    
    왼쪽 탐색 창에서 클러스터를 선택한 다음 Amazon VPC CNI 추가 기능을 구성할 클러스터의 이름을 선택합니다.
    
    추가 기능(Add-ons) 탭을 선택합니다.
    
    추가 기능 상자의 오른쪽 상단에 있는 상자를 선택한 다음에 Edit(편집)를 선택합니다.
    
    Configure name of addon(추가 기능 이름 구성) 페이지에서:
    
    버전 드롭다운 목록에서 v1.14.0-eksbuild.3 이상 버전을 선택합니다.
    
    선택적 구성 설정을 확장합니다.
    
    구성 값에 JSON 키 "enableNetworkPolicy": 및 값 "true"를 입력합니다. 결과 텍스트는 유효한 JSON 객체여야 합니다. 이 키와 값이 텍스트 상자의 유일한 데이터인 경우 키와 값을 중괄호({})로 둘러쌉니다. 다음 예시는 네트워크 정책이 활성화된 것을 보여줍니다.
    
    { "enableNetworkPolicy": "true" }
    
    다음 스크린샷은 이 시나리오의 예를 보여줍니다.
    
    AWS CLI
    
    다음 AWS CLI 명령을 실행합니다. my-cluster를 본인의 클러스터 이름으로 바꾸고 IAM 역할 ARN을 사용 중인 역할로 바꿉니다.
    
    aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
  - 자체 관리형 추가 기능
    Helm
    
    helm을 통해 Amazon VPC CNI plugin for Kubernetes를 설치한 경우 구성을 업데이트하여 네트워크 정책을 활성화할 수 있습니다.
    
    다음 명령을 실행하여 네트워크 정책을 활성화합니다.
    
    helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
    
    kubectl
    
    편집기에서 amazon-vpc-cni ConfigMap을 엽니다.
    
    kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
    
    다음 줄을 ConfigMap의 data에 추가합니다.
    
    enable-network-policy-controller: "true"
    
    줄을 추가한 후에는 ConfigMap이 다음 예와 같을 것입니다.
    
    apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy-controller: "true"
    
    편집기에서 aws-node DaemonSet를 엽니다.
    
    kubectl edit daemonset -n kube-system aws-node
    
    VPC CNI aws-node 데몬 세트 매니페스트의 aws-network-policy-agent 컨테이너에 있는 args:의 명령 인수 --enable-network-policy=false에서 false를 true로 바꿉니다.
    
    - args: - --enable-network-policy=true
aws-node 포드가 클러스터에서 실행 중인지 확인합니다.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
예제 출력은 다음과 같습니다.
```
aws-node-gmqp7                                          2/2     Running   1 (24h ago)   24h
aws-node-prnsh                                          2/2     Running   1 (24h ago)   24h
```
네트워크 정책이 활성화된 경우 aws-node 포드에는 2개의 컨테이너입니다. 이전 버전에서 네트워크 정책이 비활성화된 경우 aws-node 포드에 하나의 컨테이너만 있습니다.

이제 클러스터에 Kubernetes 네트워크 정책을 배포할 수 있습니다. 자세한 내용은 Kubernetes 네트워크 정책 단원을 참조하십시오.

Stars 네트워크 정책 데모

이 데모는 Amazon EKS 클러스터에 프런트엔드, 백엔드 및 클라이언트 서비스를 생성합니다. 데모는 또한 각 서비스 간 이용 가능한 수신 및 발신 경로를 보여주는 관리 그래픽 사용자 인터페이스를 생성합니다. 프로덕션 워크로드를 실행하지 않는 클러스터에서 데모를 완료하는 것이 좋습니다.

네트워크 정책을 생성하기 전에 모든 서비스는 양방향으로 통신할 수 있습니다. 네트워크 정책을 적용하면 클라이언트가 프런트엔드 서비스와만 통신할 수 있고 백엔드는 프런트엔드의 트래픽만 수신하는 것을 볼 수 있습니다.

Stars 정책 데모 실행

프런트엔드, 백엔드, 클라이언트 및 관리 사용자 인터페이스 서비스를 적용합니다.


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml

클러스터의 모든 Pods를 확인하세요.


kubectl get pods -A

예제 출력은 다음과 같습니다.

출력에서 다음 출력에 표시된 네임스페이스에 포드가 표시되어야 합니다. 포드의 이름과 READY 열의 포드 수는 다음 출력과 다릅니다. 이름이 비슷하고 STATUS 열에 Running이 있는 포드가 보일 때까지 계속하지 마십시오.


NAMESPACE         NAME                                       READY   STATUS    RESTARTS   AGE
[...]
client            client-xlffc                               1/1     Running   0          5m19s
[...]
management-ui     management-ui-qrb2g                        1/1     Running   0          5m24s
stars             backend-sz87q                              1/1     Running   0          5m23s
stars             frontend-cscnf                             1/1     Running   0          5m21s
[...]

관리 사용자 인터페이스에 연결하려면 클러스터에서 실행 중인 서비스의 EXTERNAL-IP에 연결합니다.
```
kubectl get service/management-ui -n management-ui
```
브라우저를 열어 이전 단계의 위치로 이동합니다. 관리 사용자 인터페이스가 표시됩니다. C 노드는 클라이언트 서비스이고, F 노드는 프런트엔드 서비스이며, B 노드는 백엔드 서비스입니다. 각 노드는 기타 모든 노드에 대한 전체 통신 액세스를 보유합니다(진한 색상의 선으로 표시).

stars 및 client 네임스페이스 모두에 다음 네트워크 정책을 적용하여 서비스를 각각 격리시킵니다.


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels: {}

다음 명령을 사용하여 두 네임스페이스 모두에 정책을 적용할 수 있습니다.


kubectl apply -n stars -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml

브라우저를 새로 고칩니다. 관리 사용자 인터페이스가 더 이상 노드에 도달하지 않아 사용자 인터페이스에 표시되지 않는 것을 확인할 수 있습니다.

다음의 다른 네트워크 정책을 적용하여 관리 사용자 인터페이스가 서비스에 액세스하도록 허용합니다. 이 정책을 적용하여 UI 허용:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

이 정책을 적용하여 클라이언트를 허용합니다.


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: client 
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

다음 명령을 사용하여 두 정책을 모두 적용할 수 있습니다.


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml

브라우저를 새로 고칩니다. 관리 사용자 인터페이스가 노드에 다시 도달할 수 있지만, 노드가 서로 통신할 수 없음을 확인할 수 있습니다.

다음 네트워크 정책을 적용하여 프런트엔드 서비스에서 백엔드 서비스로의 트래픽을 허용합니다.


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 6379

브라우저를 새로 고칩니다. 프런트엔드가 백엔드와 통신할 수 있음을 알 수 있습니다.

다음 네트워크 정책을 적용하여 클라이언트에서 프런트엔드 서비스로의 트래픽을 허용합니다.


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      role: frontend 
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: client
      ports:
        - protocol: TCP
          port: 80

브라우저를 새로 고칩니다. 클라이언트가 프런트엔드 서비스와 통신할 수 있음을 알게 됩니다. 프런트엔드 서비스는 여전히 백엔드 서비스와 통신할 수 있습니다.

(선택 사항) 데모를 마쳤으면 리소스를 삭제할 수 있습니다.


kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml

리소스를 삭제한 후에도 클러스터에서 예기치 않은 방식으로 네트워킹을 방해할 수 있는 네트워크 정책 엔드포인트가 노드에 있을 수 있습니다. 이러한 규칙을 제거하는 유일한 방법은 노드를 재부팅하거나 모든 노드를 종료하고 휴지통으로 이동하는 것입니다. 모든 노드를 종료하려면 Auto Scaling 그룹의 원하는 개수를 0으로 설정한 다음, 원하는 개수로 백업하거나 노드를 종료하면 됩니다.

네트워크 정책 문제 해결

네트워크 정책 로그의 내용을 읽고 eBPF SDK의 도구를 실행하여 네트워크 정책을 사용하는 네트워크 연결을 문제 해결 및 조사할 수 있습니다.

네트워크 정책 로그

네트워크 정책에 의해 연결이 허용 또는 거부되는지 여부는 흐름 로그에 기록됩니다. 각 노드의 네트워크 정책 로그에는 네트워크 정책이 있는 모든 포드의 흐름 로그가 포함됩니다. 네트워크 정책 로그는 /var/log/aws-routed-eni/network-policy-agent.log에 저장됩니다. 다음은 network-policy-agent.log 파일의 예입니다.

{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}

네트워크 정책 로그는 기본적으로 비활성화되어 있습니다. 네트워크 정책 로그를 활성화하려면 다음 단계를 수행합니다.

참고

네트워크 정책 로그에는 VPC CNI aws-node 데몬 세트 매니페스트의 aws-network-policy-agent 컨테이너용 vCPU 1개가 추가로 필요합니다.

Amazon EKS 추가 기능

AWS Management Console

https://console.aws.amazon.com/eks/home#/clusters에서 Amazon EKS 콘솔을 엽니다.
왼쪽 탐색 창에서 클러스터를 선택한 다음 Amazon VPC CNI 추가 기능을 구성할 클러스터의 이름을 선택합니다.
추가 기능(Add-ons) 탭을 선택합니다.
추가 기능 상자의 오른쪽 상단에 있는 상자를 선택한 다음에 Edit(편집)를 선택합니다.
Configure name of addon(추가 기능 이름 구성) 페이지에서:
1. 버전 드롭다운 목록에서 v1.14.0-eksbuild.3 이상 버전을 선택합니다.
2. 선택적 구성 설정을 확장합니다.
3. 최상위 JSON 키 "nodeAgent":를 입력하고 값은 키 "enablePolicyEventLogs":와 구성 값의 "true" 값이 포함된 객체입니다. 결과 텍스트는 유효한 JSON 객체여야 합니다. 다음 예시는 네트워크 정책과 네트워크 정책 로그가 활성화되어 있으며 CloudWatch Logs로 전송된 것을 보여줍니다.
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true"
    }
}
```

다음 스크린샷은 이 시나리오의 예를 보여줍니다.

선택적 구성에서 네트워크 정책을 포함한 VPC CNI 추가 기능과 CloudWatch Logs를 보여주는 AWS Management Console.

AWS CLI

다음 AWS CLI 명령을 실행합니다. my-cluster를 본인의 클러스터 이름으로 바꾸고 IAM 역할 ARN을 사용 중인 역할로 바꿉니다.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'

자체 관리형 추가 기능

네트워크 정책 로그를 Amazon CloudWatch Logs로 전송

Amazon CloudWatch Logs와 같은 서비스를 사용하여 네트워크 정책 로그를 모니터링할 수 있습니다. 다음 방법을 사용하여 네트워크 정책 로그를 CloudWatch Logs로 보낼 수 있습니다.

EKS 클러스터의 경우 정책 로그는 /aws/eks/cluster-name/cluster/에 있고 자체 관리형 K8S 클러스터의 경우 로그는 /aws/k8s-cluster/cluster/에 있습니다.

Amazon VPC CNI plugin for Kubernetes로 네트워크 정책 로그 전송

네트워크 정책을 활성화하면 두 번째 컨테이너가 노드 에이전트용 aws-node 포드에 추가됩니다. 이 노드 에이전트는 네트워크 정책 로그를 CloudWatch Logs로 보낼 수 있습니다.

참고

네트워크 정책 로그는 노드 에이전트에 의해서만 전송됩니다. VPC CNI에서 생성한 다른 로그는 포함되지 않습니다.

필수 조건

VPC CNI에 사용하는 IAM 역할에 다음 권한을 스탠자 또는 별도의 정책으로 추가합니다.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Amazon EKS 추가 기능

AWS Management Console

https://console.aws.amazon.com/eks/home#/clusters에서 Amazon EKS 콘솔을 엽니다.
왼쪽 탐색 창에서 클러스터를 선택한 다음 Amazon VPC CNI 추가 기능을 구성할 클러스터의 이름을 선택합니다.
추가 기능(Add-ons) 탭을 선택합니다.
추가 기능 상자의 오른쪽 상단에 있는 상자를 선택한 다음에 Edit(편집)를 선택합니다.
Configure name of addon(추가 기능 이름 구성) 페이지에서:
1. 버전 드롭다운 목록에서 v1.14.0-eksbuild.3 이상 버전을 선택합니다.
2. 선택적 구성 설정을 확장합니다.
3. 최상위 JSON 키 "nodeAgent":를 입력하고 값은 키 "enableCloudWatchLogs":와 구성 값의 "true" 값이 포함된 객체입니다. 결과 텍스트는 유효한 JSON 객체여야 합니다. 다음 예시는 네트워크 정책과 네트워크 정책 로그가 활성화되어 있으며 로그가 CloudWatch Logs로 전송된 것을 보여줍니다.
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true",
        "enableCloudWatchLogs": "true",
    }
}
```

다음 스크린샷은 이 시나리오의 예를 보여줍니다.

AWS CLI

다음 AWS CLI 명령을 실행합니다. my-cluster를 본인의 클러스터 이름으로 바꾸고 IAM 역할 ARN을 사용 중인 역할로 바꿉니다.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'

자체 관리형 추가 기능

Fluent Bit 데몬 세트로 네트워크 정책 로그 전송

데몬 세트에서 Fluent Bit를 사용하여 노드에서 로그를 전송하는 경우 네트워크 정책에서 네트워크 정책 로그를 포함하도록 구성을 추가할 수 있습니다. 다음 예제 구성을 사용할 수 있습니다.


    [INPUT]
        Name              tail
        Tag               eksnp.*
        Path              /var/log/aws-routed-eni/network-policy-agent*.log
        Parser            json
        DB                /var/log/aws-routed-eni/flb_npagent.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10

포함된 eBPF SDK

Amazon VPC CNI plugin for Kubernetes에서 노드에 eBPF SDK 도구 컬렉션을 설치합니다. eBPF SDK 도구를 사용하여 네트워크 정책 관련 문제를 식별할 수 있습니다. 예를 들어 다음 명령은 노드에서 실행 중인 프로그램을 나열합니다.


sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

이 명령을 실행하려면 임의의 방법을 사용하여 노드에 연결할 수 있습니다.

Kubernetes 네트워크 정책

생성한 Kubernetes NetworkPolicy 개체에 Kubernetes 네트워크 정책을 구현하고 이를 클러스터에 배포하려면 NetworkPolicy 개체 범위는 네임스페이스로 지정됩니다. 정책을 구현하여 레이블 선택기, 네임스페이스 및 IP 주소 범위를 기반으로 Pods 사이의 트래픽을 허용 또는 거부합니다. NetworkPolicy 개체 생성에 관한 자세한 내용은 Kubernetes 설명서의 네트워크 정책을 참조하세요.

Kubernetes NetworkPolicy 개체의 적용은 Extended Berkeley Packet Filter (eBPF)를 사용하여 구현됩니다. iptables 기반 구현에 따라 지연 시간을 낮추고 CPU 활용률 감소 및 순차 조회 방지를 포함한 성능 특성을 제공합니다. 추가로 eBPF 프로브는 복잡한 커널 수준 문제를 디버깅하고 관찰성을 개선하는 데 도움이 되도록 컨텍스트가 풍부한 데이터에 대한 액세스를 제공합니다. Amazon EKS는 프로브를 활용하여 각 노드에 정책 결과를 기록하고 외부 로그 수집기로 데이터를 내보내 디버깅을 지원하는 eBPF 기반 익스포터를 지원합니다. 자세한 내용은 eBPF 설명서를 참조하십시오.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

SNAT

사용자 지정 네트워킹

클러스터에 Kubernetes 네트워크 정책 구성

고려 사항

Pod 시작 시 정책 적용

필수 조건

최소 클러스터 버전

최소 VPC CNI 버전

최소 Linux 커널 버전

Kubernetes 네트워크 정책을 사용하도록 클러스터 구성

BPF 파일 시스템을 탑재합니다.

참고

VPC CNI에서 네트워크 정책을 활성화합니다.

Stars 네트워크 정책 데모

Stars 정책 데모 실행

네트워크 정책 문제 해결

네트워크 정책 로그

참고

Amazon EKS 추가 기능

자체 관리형 추가 기능

네트워크 정책 로그를 Amazon CloudWatch Logs로 전송

Amazon VPC CNI plugin for Kubernetes로 네트워크 정책 로그 전송

참고

필수 조건

Amazon EKS 추가 기능

자체 관리형 추가 기능

Fluent Bit 데몬 세트로 네트워크 정책 로그 전송

포함된 eBPF SDK

Kubernetes 네트워크 정책