Ssoon

[2주차] Container Networking Interface (CNI) & Flannel 본문

쿠버네티스 네트워크 스터디 3기

[2주차] Container Networking Interface (CNI) & Flannel

구구달스 2024. 9. 3. 23:15 
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 3기

컨테이너 환경에서 네트워킹을 관리하는 표준 인터페이스

 

  • 네트워크 구성: CNI는 컨테이너 런타임과 통합되어 컨테이너의 네트워크 인터페이스를 추가하고 IP 주소를 할당합니다.
  • 오버레이 및 언더레이 네트워크: 오버레이 네트워크(예: VXLAN)는 네트워크 트래픽을 가상화하여 캡슐화하고, 언더레이 네트워크는 물리적 스위치와 라우터를 사용합니다.
  • 쿠버네티스 및 다른 플랫폼 지원: CNI는 Kubernetes와 통합되어 파드 간의 네트워크를 자동으로 구성하고, OpenShift와 같은 다른 쿠버네티스 기반 플랫폼과도 호환됩니다.
  • SDN 접근: 소프트웨어 정의 네트워킹(SDN) 방식을 사용하여 클러스터 전체에서 컨테이너 통신을 관리합니다.
  • 네트워크 플러그인과 IP 주소 관리(IPAM) 플러그인 : 네트워크 구성을 자동화하고, 효율적인 네트워킹을 지원합니다.

✅ CNI 플러그인의 실행 흐름

  • 컨테이너 런타임(예: 쿠버네티스)이 컨테이너에서 네트워크 작업을 수행해야 하는 경우, 원하는 명령어로 CNI 플러그인을 호출합니다.
  • 컨테이너 런타임은 또한 관련 네트워크 구성 및 컨테이너별 데이터를 플러그인에 제공하며, 플러그인은 필요한 작업을 수행하고 결과를 보고합니다.

https://www.cncf.io/blog/2017/05/23/cncf-hosts-container-networking-interface-cni/

  • CNI는 포드에 대한 루프백 및 eth0 인터페이스를 설정하기 위해 k8의 kubelet에서 두 번 호출됩니다.
    • K8s kubelet이 파드에 대해 루프백 및 eth0 인터페이스를 설정하는 경우 
    • 외부 IP 주소에 연결할 수 있는 외부 인터페이스에 대해 루프백 및 eth0 인터페이스를 설정하는 경우 K8s kubelet이 외부 인터페이스를 설정하는 경우.

✅ CNI 구성 요소

컨테이너 관리 시스템(CMS)과 네트워크 플러그인은 함께 작동하여 컨테이너의 기능을 활성화합니다. CMS는 컨테이너를 관리하고, 네트워크 플러그인은 JSON 형식의 파일을 통해 컨테이너 간의 통신을 제어합니다. 단계는 다음과 같은 플러그인을 통해 구현됩니다:

  • 컨테이너 네트워크 네임스페이스 만들기 
  • 해당 네트워크 공간에 네트워크 인터페이스(인터페이스) 배치하기 
  • 네트워크 인터페이스에 IP 할당하기

공식 CNI 플러그인은 현재 세 가지 카테고리로 나뉩니다:

https://blog.fourninecloud.com/container-network-interface-101-231537d7967a

  • main  - 특정 네트워크 기능을 구현하는 메인 플러그인
  • meta  - 자체적으로 특정 네트워크 기능을 제공하지 않으며, 다른 플러그인을 호출하거나 단순히 테스트 용도로 사용됩니다.
  • ipam - IP 주소 할당용 플러그인

🧿main functions

  • loopback:루프백 lo 네트워크를 생성하고 주소 127.0.0.1/8로 구성할 수 있는 사용하기 쉬운 플러그인입니다.
  • bridge: 도커의 기본 네트워크 모델과 유사하게 모든 컨테이너를 가상 스위치에 연결합니다.
  • macvlan: 하나의 물리적 네트워크 카드에서 가상 네트워크 카드를 만들려면 macvlan을 사용합니다. 가상 네트워크 카드에는 자체 IP 주소가 있으며 별도의 MAC 주소가 있습니다.
  • ipvlan: 하나의 물리적 네트워크 카드에서 가상 네트워크 카드를 만들려면 ipvlan을 사용합니다. 가상 네트워크 카드의 MAC 주소가 동일합니다.
  • ptp: veth pair 을 통해 컨테이너와 호스트 사이에 채널을 설정하려면 PTP를 사용합니다.

🧿meta functions

  • flannel: 플란넬 브리지 플러그인은 플란넬 네트워크 세분화 도구와 함께 사용하여 네트워크 세그먼트에서 많은 호스트가 감지될 때 브리지 플러그인을 호출할 수 있습니다.

🧿ipam functions

  • host-local: 로컬 파일을 기반으로 IP 할당 및 관리, 할당된 IP 주소를 파일에 저장합니다.
  • dhcp: 이미 실행 중인 DHCP 서버에서 IP 주소 가져오기

✅Kubernetes에서 cni0의 역할

  • 같은 노드 내에서의 파드 간 통신
    • 새로운 파드가 생성되면, Kubernetes 네트워크 플러그인은 파드에 가상 이더넷 인터페이스(veth 쌍)를 붙입니다. 이 veth 쌍의 반대쪽 끝은 cni0 브리지에 연결됩니다.
    • 이 브리지를 통해 같은 노드에 있는 모든 파드가 서로 Layer 2 (이더넷) 네트워크 상에서 통신할 수 있습니다.
  • 호스트 네트워크와의 연결
    • cni0는 호스트의 네트워크 인터페이스(예: eth0)와 연결됩니다. 이를 통해 파드들은 외부 네트워크(클러스터 외부) 또는 클러스터 내의 다른 노드와 통신할 수 있습니다.
    • 네트워크 플러그인은 보통 CNI 설정에 정의된 IP 범위를 사용해 각 파드에 적절한 IP 주소를 할당합니다.
  • 트래픽 라우팅
    • cni0 브리지는 같은 노드 내에서 파드 간 트래픽을 처리하며, 다른 노드나 외부 네트워크로 향하는 트래픽도 올바른 인터페이스로 포워딩되도록 합니다. 이는 IP 라우트를 통해 이루어지거나, Flannel, Calico와 같은 다른 CNI 플러그인을 통해 관리될 수 있습니다.

✅ 실습

🧿 kind & Flannel 배포

  • networking.disableDefaultCNI: true
    • 기본 CNI 비활성화
      • Kubernetes는 클러스터의 Pod 간 통신을 관리하기 위해 네트워크 플러그인을 사용합니다. 이 플러그인은 CNI 표준을 따릅니다.
      • 만약 disableDefaultCNI: true로 설정하면, Kubernetes는 기본적으로 제공되는 CNI(예: kubenet)를 사용하지 않게 됩니다.
    • 사용자 정의 CNI 사용
      • 이 설정을 활성화하면 사용자가 Flannel, Calico, Weave 등의 CNI 플러그인을 별도로 설치하고 구성해야 합니다. 이는 네트워킹 요구사항에 맞춰 CNI를 선택하고 설정할 수 있는 유연성을 제공합니다.
    • 어떤 상황에서 사용?
      • 클러스터 관리자가 기본 네트워크 구성을 사용하지 않고, 특정 요구사항에 맞춰 사용자 정의 네트워크 플러그인을 설정하려고 할 때 유용합니다.
      • 예를 들어, 기본 네트워크보다 더 복잡한 네트워크 정책이 필요하거나, 다른 오버레이 네트워크 기술을 사용하고 싶을 때 이 설정을 사용합니다.

  • Kubernetes 클러스터를 Kind(Kubernetes in Docker) 도구를 사용하여 특정 설정 파일(kind-cni.yaml)과 이미지( v1.30.4 )를 기반으로 생성

  • kind get clusters: Kind로 생성된 모든 클러스터 목록을 표시합니다.
  • kind get nodes --name myk8s: 지정된 클러스터(myk8s)의 노드 목록을 표시합니다.
  • kubectl cluster-info: 현재 연결된 Kubernetes 클러스터의 주요 정보(API 서버, DNS 등)를 표시합니다.

  • kubectl cluster-info dump 출력을 통해 클러스터 CIDR, 서비스 클러스터 IP 범위 정보를 표시합니다.
    • cluster-cidr: 클러스터 내에서 Pod에 할당되는 IP 범위.
    • service-cluster-ip-range: 클러스터 내에서 서비스에 할당되는 IP 범위.

  • myk8s-control-plane 컨테이너 내부 IPv4 주소 정보를 확인합니다.

  • bridge 실행파일 생성 후 로컬에 복사
    • build_linux.sh 스크립트를 실행합니다. 이 스크립트는 다양한 네트워크 플러그인을 빌드하는 작업을 수행합니다. 예를 들어 bandwidth, bridge, dhcp와 같은 플러그인들을 빌드합니다.

  • Flannel cni 를 설치합니다.

  • Flannel 네트워크 플러그인이 Pod 네트워크를 설정하려다 실패합니다.

  • 이 문제는 Flannel 네트워크 플러그인이 Pod 네트워크를 설정할 때 **CNI 플러그인 중 "bridge"**를 찾을 수 없어서 발생한 것입니다. 이를 해결하려면 /opt/cni/bin 경로에 필요한 CNI 플러그인들이 제대로 설치되어 있는지 확인하고, 네트워크 플러그인 설정을 다시 점검해야 합니다.

에러 원인:

  1. plugin type="flannel" failed (add):
    • Flannel 네트워크 플러그인이 Pod 네트워크를 설정하려다 실패했습니다. Flannel은 Kubernetes에서 많이 사용하는 네트워크 플러그인 중 하나입니다.
  2. failed to find plugin "bridge" in path [/opt/cni/bin]:
    • Kubernetes에서 Pod의 네트워크를 설정할 때 필요한 bridge 플러그인을 찾을 수 없다는 의미입니다. 이 플러그인은 CNI(Container Network Interface) 플러그인의 일부로, 노드 간 네트워크 연결을 설정하는 데 중요한 역할을 합니다.
    • 이 문제는 /opt/cni/bin 경로에 bridge 플러그인이 없거나 잘못 설치된 경우 발생합니다.
  3. Failed to create pod sandbox:
    • Pod가 실행되기 전에 네트워크 설정을 포함한 "Pod sandbox"를 생성하는데, 네트워크 설정에 실패했기 때문에 Pod가 배포되지 않고 계속 실패하고 있습니다.

해결 방법:

  1. CNI 플러그인 설치 확인:
    • /opt/cni/bin 경로에 CNI 플러그인들이 제대로 설치되어 있는지 확인합니다.bridge 플러그인이 존재해야 합니다.
    • 만약 설치되어 있지 않다면, CNI 플러그인을 다시 설치하거나 제대로 설치되었는지 확인해야 합니다.
  • bridge 플러그인 파일을 Kubernetes 클러스터의 각 노드(myk8s-control-plane, myk8s-worker, myk8s-worker2)로 복사합니다.
    • Kubernetes에서 네트워크 플러그인(CNI)들이 각 노드의 /opt/cni/bin/ 경로에 설치되어 있어야 정상적으로 동작합니다. bridge 플러그인이 없으면 Pod의 네트워크 설정이 실패할 수 있기 때문에, 이 플러그인을 수동으로 각 노드에 복사하여 네트워크 설정 문제를 해결하려는 시도입니다.

  • Kubernetes 클러스터에서 각 노드에 할당된 Pod CIDR 범위를 출력합니다. 이 CIDR 범위는 해당 노드에서 실행되는 Pod들이 사용할 수 있는 IP 주소 범위를 의미합니다.
    • Pod CIDR란?
      • Pod CIDR(Classless Inter-Domain Routing)은 Kubernetes 클러스터의 각 노드가 Pod에게 할당할 수 있는 IP 주소 범위를 지정합니다. 즉, 각 노드는 해당 범위 내에서 Pod에 고유 IP 주소를 부여하여 네트워크 통신을 가능하게 합니다.
    • Flannel과의 관계:
      • 이 설정은 Flannel과 같은 CNI 플러그인에서 관리하는 Pod 네트워크와 밀접한 관련이 있습니다. Flannel은 각 노드에 고유한 서브넷(CIDR)을 할당하고, 해당 서브넷 내에서 Pod들이 서로 통신할 수 있도록 오버레이 네트워크를 설정합니다. 출력된 CIDR 범위는 Flannel이 각 노드에 어떻게 서브넷을 할당했는지 보여줍니다.

  • Flannel 네트워크 플러그인과 관련된 Annotations를 보여줍니다. 이 애노테이션들은 Flannel이 각 노드에 설정한 네트워크 정보를 설명합니다. 각 노드는 Flannel 네트워크를 통해 VXLAN(가상 확장 LAN)을 사용하여 다른 노드와 통신합니다.
    • flannel.alpha.coreos.com/public-ip:
      • 각 노드의 공개 IP 주소입니다. 이 IP는 해당 노드가 Flannel 네트워크에 참여할 때 사용하는 주소입니다.

  • lsns -p $(pgrep flanneld) (Flannel 프로세스 분석)
    • Flannel이 별도의 네트워크 네임스페이스를 사용하지 않는다는 것은, Flannel이 기본적으로 클러스터의 네트워크와 동일한 네트워크 네임스페이스에서 동작한다는 뜻입니다.
    • 따라서 호스트 네트워크와 동일한 네트워크 네임스페이스를 사용하여, 각 노드 간에 패킷을 전달하고 통신할 수 있도록 네트워크를 설정합니다.
    • Flannel은 Kubernetes 노드 전체의 네트워크 설정을 관리해야 하기 때문에, 컨테이너와 달리 네트워크를 격리하지 않고 호스트 네트워크를 사용하여 다른 노드들과 통신합니다.
  • lsns -p $(pgrep kube-proxy) (kube-proxy 프로세스 분석)
    • kube-proxy 프로세스 (/usr/local/bin/kube-proxy): 이 프로세스는 Kubernetes의 클러스터 네트워크에서 서비스 간의 트래픽을 라우팅하는 역할을 합니다.
    • 네임스페이스:
      • mnt, pid, ipc: kube-proxy도 마운트, 프로세스 ID, 인터프로세스 통신에 대해 고유의 네임스페이스를 가지고 실행됩니다.
      • kube-proxy는 네트워크 네임스페이스에서 init 프로세스와 동일한 환경에서 실행되고 있음을 보여줍니다. 이는 kube-proxy가 호스트 네트워크와 직접 상호작용하는 구조 때문입니다.

 

  • Flannel 인터페이스 (flannel.1): Flannel CNI 플러그인이 생성한 가상 인터페이스로, Kubernetes의 Pod 네트워크를 위한 IP를 제공합니다.
  • CNI 브릿지 인터페이스 (cni0): Kubernetes CNI 플러그인에 의해 생성된 브릿지 인터페이스로, 노드 내의 Pod 간 통신을 관리합니다.

 

  • cni0 브리지는 세 개의 가상 이더넷 인터페이스와 연결되어 있습니다 (veth10b401a9, veth875a4143, veth9a4f2969).
    • 이러한 veth 인터페이스들은 Pod 간의 네트워크 트래픽을 cni0 브리지를 통해 라우팅합니다.

 

    1. default via 172.18.0.1 dev eth0:이 항목은 클러스터 외부로 나가는 모든 트래픽이 172.18.0.1 게이트웨이를 통해 eth0 인터페이스를 통해 전송된다는 것을 의미합니다.
    2. 10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink: 이 항목은 10.244.0.0/24 네트워크로 가는 트래픽이 flannel.1 인터페이스를 통해 직접 연결되어 있다는 것을 의미합니다.
    3. 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1:  10.244.1.0/24 네트워크로 가는 트래픽이 cni0 인터페이스를 통해 전송된다는 것을 의미합니다.
    4. 10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink:  10.244.2.0/24 네트워크로 가는 트래픽이 flannel.1 인터페이스를 통해 직접 연결되어 있다는 것을 의미합니다.
    5. 172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.5:  172.18.0.0/16 네트워크로 가는 트래픽이 eth0 인터페이스를 통해 전송된다는 것을 의미합니다.

 

 

  • FLANNEL-FWD 체인은 Flannel 플러그인이 사용하는 방화벽 체인입니다. 이 체인은 Flannel 네트워크가 올바르게 작동하도록 트래픽을 허용하는 역할을 합니다.
  • 10.244.0.0/16 네트워크 대역에 대해 다음과 같은 두 가지 규칙이 설정되어 있습니다:
    • 출발지 주소가 10.244.0.0/16인 패킷을 허용합니다.
    • 목적지 주소가 10.244.0.0/16인 패킷을 허용합니다.

이 규칙들은 Flannel 네트워크가 내부적으로 사용하는 IP 대역에 대해 패킷이 차단되지 않고 허용되도록 보장합니다. Flannel은 이 IP 대역 내에서 패킷을 자유롭게 전달할 수 있게 하며, 네트워크 간의 통신이 원활하게 이루어지도록 합니다.

  1. -A POSTROUTING -m comment --comment "flanneld masq" -j FLANNEL-POSTRTG
    • POSTROUTING 체인에서 FLANNEL-POSTRTG 체인으로 트래픽을 전달합니다. 주석으로 "flanneld masq"가 달려 있습니다.
  2. -A FLANNEL-POSTRTG -m mark --mark 0x4000/0x4000 -m comment --comment "flanneld masq" -j RETURN
    • FLANNEL-POSTRTG 체인에서 특정 마크(0x4000)를 가진 패킷을 그대로 반환합니다. 주석으로 "flanneld masq"가 달려 있습니다.
  3. -A FLANNEL-POSTRTG -s 10.244.1.0/24 -d 10.244.0.0/16 -m comment --comment "flanneld masq" -j RETURN
    • 소스 IP가 10.244.1.0/24이고 목적지 IP가 10.244.0.0/16인 패킷을 FLANNEL-POSTRTG 체인에서 그대로 반환합니다. 주석으로 "flanneld masq"가 달려 있습니다.
  4. -A FLANNEL-POSTRTG -s 10.244.0.0/16 -d 10.244.1.0/24 -m comment --comment "flanneld masq" -j RETURN
    • 소스 IP가 10.244.0.0/16이고 목적지 IP가 10.244.1.0/24인 패킷을 FLANNEL-POSTRTG 체인에서 그대로 반환합니다. 주석으로 "flanneld masq"가 달려 있습니다.
  5. -A FLANNEL-POSTRTG -s 10.244.0.0/16 ! -d 224.0.0.0/4 -m comment --comment "flanneld masq" -j MASQUERADE --random-fully
    • 소스 IP가 10.244.0.0/16이고 목적지 IP가 224.0.0.0/4이 아닌 패킷을 MASQUERADE 대상으로 변환합니다. 이 규칙은 출발지 IP를 변경하여 패킷이 Flannel 네트워크 외부와 통신할 수 있도록 합니다. --random-fully 옵션은 변환된 출발지 IP의 포트를 무작위로 변경하여 보안을 강화합니다.

🧿 파드 2개 생성

  • 이 네트워크 인터페이스들은 파드와의 연결을 위해 cni0 브리지에 연결되며, 이는 파드가 서로 통신할 수 있도록 하는 네트워크 구조를 형성합니다.

  • @flannel.1: 각 인터페이스가 flannel.1이라는 다른 브리지나 네트워크와 연결되어 있음을 나타냅니다.
  • master cni0: 이 인터페이스가 cni0 브리지의 하위 인터페이스임을 나타냅니다. 즉, cni0 브리지의 일부분입니다.
  • state forwarding: 이 인터페이스의 브리지 상태가 "포워딩" 상태임을 의미합니다. 포워딩 상태는 이 인터페이스가 네트워크 트래픽을 전달할 수 있음을 나타냅니다.
  • bridge link 명령어의 출력은 cni0 브리지에 연결된 가상 이더넷 인터페이스들이 정상적으로 작동하고 있으며, 이들이 Flannel 네트워크의 일부분으로 설정되어 있음을 보여줍니다. 각 인터페이스는 cni0 브리지와 연결되어 있으며, 네트워크 트래픽을 포워딩할 준비가 되어 있습니다.

 

  • cni0 브리지와 그 하위 인터페이스들이 VLAN 1에 속해 있으며, 모든 포트에서 VLAN 1이 기본 VLAN으로 설정되어 있음을 보여줍니다.
  • 이 포트들에서 나가는 패킷은 태그가 없게 설정되어 있습니다. 이러한 설정은 주로 기본 VLAN을 처리하는 방법을 정의하고, VLAN 태그가 없는 패킷을 VLAN 1로 처리하도록 설정합니다.

 

  • 이 디렉토리는 cbr0 네트워크에 대해 사용 중인 IP 주소와 관련된 정보를 저장합니다.
  • 각 IP 주소에 대한 파일은 해당 IP를 가진 컨테이너에 대한 정보를 포함하며, last_reserved_ip.0 파일은 마지막으로 예약된 IP 주소를 기록하고, lock 파일은 네트워크 설정의 동시 수정을 방지합니다.
    • last_reserved_ip.0:
      • 이 파일은 마지막으로 예약된 IP 주소에 대한 정보를 저장합니다. 컨테이너가 네트워크에 추가될 때 이 파일의 값이 업데이트되어 IP 주소 풀에서 어떤 IP가 마지막으로 사용되었는지를 추적합니다.
    • lock:
      • 이 파일은 cbr0 네트워크의 상태를 업데이트하거나 수정할 때 다른 프로세스와의 충돌을 방지하기 위한 잠금 파일입니다. 이 파일이 존재하면 다른 프로세스가 동시에 이 네트워크의 설정을 변경하지 못하도록 하는 역할을 합니다.

 

  • 다른 노드에 배포된 파드 통신 확인
  • 외부 인터넷 IP   접속 확인
  • 외부 인터넷 도메인 접속 확인
  • GW IP는 어떤 인터페이스인가?   cni0:10.244.1.1

 

1) tcpdump -i cni0 -nn icmp

  • ping -c 2 10.244.2.2

  •  ping -c 2 8.8.8.8

 

2) tcpdump -i flannel.1 -nn icmp

  • ping -c 2 10.244.2.2

  •  ping -c 2 8.8.8.8

 

3) tcpdump -i eth0 -nn icmp

  • ping -c 2 10.244.2.2

  •  ping -c 2 8.8.8.8

  • myk8s-worker 컨테이너에서 /root/vxlan.pcap 파일을 호스트의 현재 디렉터리로 복사합니다.
  • 원격 서버 192.168.50.10의 /root/vxlan.pcap 파일이 로컬 시스템의 현재 디렉터리로 복사합니다.

  • VXLAN(Virtual eXtensible LAN) 프로토콜을 통해 전송된 네트워크 트래픽을 보여줍니다.

 

패킷 분석

  1. Ethernet II (외부 Ethernet 헤더)
    • Src (출발지 MAC 주소): 02:42:ac:12:00:05
    • Dst (목적지 MAC 주소): 02:42:ac:12:00:03
    • 이 헤더는 물리적 또는 가상 네트워크에서 사용하는 MAC 주소를 나타냅니다.
  2. IPv4 (외부 IP 헤더)
    • Src (출발지 IP 주소): 172.18.0.5
    • Dst (목적지 IP 주소): 172.18.0.3
    • 이 헤더는 실제 네트워크 상의 IP 주소를 나타냅니다. 172.18.0.5에서 172.18.0.3으로 가는 트래픽입니다.
    • 172.18.0.X는 Docker가 기본적으로 사용하는 브리지 네트워크 서브넷입니다.
  3. UDP (User Datagram Protocol)
    • Src Port (출발지 포트): 41820
    • Dst Port (목적지 포트): 8472
    • VXLAN 트래픽은 일반적으로 UDP 프로토콜을 사용하며, 목적지 포트 8472는 VXLAN을 나타냅니다.
  4. VXLAN (Virtual eXtensible LAN)
    • VXLAN은 L2 네트워크 트래픽을 L3 네트워크 위에 캡슐화하여 전송합니다.
    • 이 구간은 VXLAN 터널링을 통해 내부 네트워크 트래픽을 전달하는 부분입니다.
  5. Ethernet II (내부 Ethernet 헤더)
    • Src (출발지 MAC 주소): d6:03:e8:20:3c:8b
    • Dst (목적지 MAC 주소): a2:0b:b0:08:d6:28
    • VXLAN 터널 안에 캡슐화된 실제 네트워크 트래픽의 MAC 주소입니다.
  6. IPv4 (내부 IP 헤더)
    • Src (출발지 IP 주소): 10.244.1.5
    • Dst (목적지 IP 주소): 10.244.2.2
    • 이 IP 주소는 Kubernetes에서 사용하는 Pod 네트워크 범위 내의 주소입니다.
    • 10.244.X.X는 Flannel과 같은 CNI 플러그인에서 사용하는 Pod 네트워크 CIDR입니다.
  7. ICMP (Internet Control Message Protocol)
    • 내부 트래픽이 ICMP 프로토콜을 사용하고 있습니다. ICMP는 네트워크 진단과 관련된 트래픽, 예를 들어 핑(ping) 요청 및 응답에 사용됩니다.
저작자표시

'쿠버네티스 네트워크 스터디 3기' 카테고리의 다른 글

[3주차] Calico CNI  (1) 2024.09.10
[2주차] Pause Container 란 ?  (1) 2024.09.04
[2주차] 쿠버네티스에서 파드 간 통신은 어떻게 작동하나요?  (0) 2024.09.02
[1주차] Sysbox Container Runtime : Storage/Security  (0) 2024.08.27
[1주차] Sysbox Container Runtime : Kubernetes-in-Docker  (0) 2024.08.26
'쿠버네티스 네트워크 스터디 3기' Related Articles more
Comments