[CKA 시험공부 노트] 9. Networking

 

[kubernetes] 쿠버네티스 관련 글 목차

 

ㅁ 들어가며

Udemy 네트워크 강의를 들으면서 노트한 글입니다.

 

197. Networking - Section Introduction

- 클러스터 네트워킹

• Pod 네트워킹
• Kubernetes CNI
• Kubernetes의 DNS 내부구성 방법
• 인그레스 네트워킹

199. Prerequisite - Switching Routing

 - 네트워크 기본사항

• Switching and Routing
  • Switching
  • Routing
  • Default Gateway
• DNS
  • DNS Configurations on Linux
  • CoreDNS Introduction
  • Network Namespaces
  • Docker Networking

- 네트워크란 무엇인가?

+ A와 B 두대의 컴퓨터를 Eth0이라는 인터페이스를 통해 IP링크 연결한다.

+ ip link

+ ip addr add 192.168.1.11/24 dev eth0

+ 하나의 네트워크 시스템 구축

 

- 시스템과 시스템의 연결은?

+ 라우터로 구성

+ A 시스템: 192.168.1.1  B 시스템: 192.168.2.1

 

- GateWay

+ 외부시스템으로 연결하는 관문이다. 이를 위해서는 다른 시스템의 문이 어디인지 설정이 필요하다.

+ route 명령어로 시스템의 기존 라우팅 구성을 볼 수 있다.

+ ip route add 192.168.2.0/24 via 192.168.1.1

 

- Internet

+ 모든 라우팅 테이블을 추가하는 대신 기본 게이트웨이 라우터 IP만 추가한다.

 

- 호스트 라우팅

+ 호스트가 패킷을 전달할 수 있는지 여부: /proc/sys/net/ipv4/ip_forward 설정이 1인지 확인

200. Prerequisite - DNS

-  /etc/hosts는 모든 서버의 이름을 저장 할 수 없기 때문에 DNS이 필요하다.

- 많은 호스트 이름과 IP가 있는 대규모 환경에서 이름 확인을 관리하는 데 도움이 되는 방법

- DNS 서버를 가리키도록 호스트를 구성하는 방법

201. Prerequisite - CoreDNS

DNS 서버 전용 서버와 서버의 항목으로 구성할 일련의 IP가 제공됩니다. 시중에는 많은 DNS 서버 솔루션이 있습니다. 이 강의에서는 특정 솔루션인 CoreDNS에 중점을 둘 것입니다.

 

CoreDNS Github 다운로드
  그렇다면 코어 DNS는 어떻게 얻습니까? CoreDNS 바이너리는 Github 릴리스 페이지에서 또는 도커 이미지로 다운로드할 수 있습니다. curl 또는 wget을 사용하여 바이너리를 다운로드하여 coredns 실행 파일을 얻습니다. 

 

CoreDNS 실행
  실행 파일을 실행하여 DNS 서버를 시작하십시오. 기본적으로 DNS 서버의 기본 포트인 포트 53에서 수신 대기합니다. 호스트 이름 매핑에 대한 IP를 지정하지 않았습니다. 먼저 모든 항목을 DNS 서버의 /etc/hosts 파일에 넣습니다.

 

CoreDNS 구성
  그런 다음 해당 파일을 사용하도록 CoreDNS를 구성합니다. CoreDNS는 Corefile이라는 파일에서 구성을 로드합니다. 다음은 /etc/hosts 파일에서 호스트 이름 매핑에 대한 IP를 가져오도록 CoreDNS에 지시하도록 구성한다. DNS 서버가 실행되면 이제 서버의 /etc/hosts 파일에서 IP와 이름을 선택합니다.

 

CoreDNS 플러그인
  CoreDNS는 플러그인을 통해 DNS 항목을 구성하는 다른 방법도 지원합니다. Kubernetes에 사용되는 플러그인 CoreDNS에 대해 자세히 알아보세요.
https://coredns.io/plugins/kubernetes/

 

202. Prerequisite - Network Namespaces

+ Namespace는 무엇인가?

Namespace의 집에 대한 비유.  호스트=집, 네임스페이스=방(Private)

그러나 부모는 집안의 모든 방과 집안의 다른 영역을 볼 수 있습니다. 원하는 경우 집안의 두 방을 연결할 수 있습니다. 컨테이너를 생성할 때 컨테이너가 격리되어 있는지 확인하고 호스트의 다른 프로세스나 다른 컨테이너를 볼 수 없도록 해야 합니다.

그래서 네임스페이스를 사용하여 호스트에 특별한 방을 만듭니다. 컨테이너에 관한 한 컨테이너는 자신이 실행하는 프로세스만 보고 자체 호스트에 있다고 생각합니다. 그러나 기본 호스트는 컨테이너 내부에서 실행되는 프로세스를 포함하여 모든 프로세스를 볼 수 있습니다. 이것은 컨테이너 내에서 프로세스를 나열할 때 볼 수 있습니다. 프로세스 ID가 1인 단일 프로세스가 표시됩니다. 기본 호스트의 루트 사용자와 동일한 프로세스를 나열하면 컨테이너 내에서 실행 중인 프로세스와 함께 이번에는 다른 프로세스 ID로 다른 모든 프로세스가 표시됩니다. 
컨테이너 내부와 외부에서 서로 다른 프로세스 ID로 실행되는 동일한 프로세스입니다. 네임스페이스가 작동하는 방식입니다. 

 

네트워킹과 관련하여 호스트에는 로컬 영역 네트워크에 연결하는 자체 인터페이스가 있습니다. 호스트에는 나머지 네트워크에 대한 정보가 포함된 자체 라우팅 및 ARP 테이블이 있습니다. 컨테이너에서 이러한 모든 세부 정보를 봉인하려고 합니다. 컨테이너가 생성되면 네트워크 네임스페이스를 생성하므로 호스트의 네트워크 관련 정보를 볼 수 없습니다. 네임스페이스 내에서 컨테이너는 자체 가상 인터페이스, 라우팅 및 ARP 테이블을 가집니다. 컨테이너에는 자체 인터페이스가 있습니다.

 

정리: Namespace는 호스트에서 가동되는 컨테이너 그룹의 Private(독립성)을 보장하기 위한 개별 VPN 역할을 한다.

 

+ Network Namespaces
Linux 호스트에서 새 네트워크 네임스페이스를 만들려면 ip netns add 명령을 실행합니다. 이 경우 두 개의 네트워크 네임스페이스를 생성합니다. 네트워크 네임스페이스를 나열하려면 ip netns 명령을 실행합니다. 내 호스트의 인터페이스를 나열하기 위해 ip link 명령을 실행합니다. 호스트에 루프백 인터페이스와 80 인터페이스가 있는 것을 확인했습니다.

이제 우리가 만든 네트워크 네임스페이스 내에서 동일한 것을 어떻게 봅니까? red 또는 blue 네임스페이스 내에서 동일한 명령을 어떻게 실행합니까? 명령 앞에 ip netns exec 명령을 붙인 다음 네임스페이스 이름(빨간색)을 붙입니다. 이제 빨간색 네임스페이스 내에서 ip link 명령이 실행됩니다. 이를 수행하는 또 다른 방법은 원래 ip link 명령에 -n 옵션을 추가하는 것입니다. 이 둘은 동일합니다. 두 번째는 더 간단하지만 네임스페이스 내에서 ip 명령을 실행하려는 경우에만 작동한다는 점을 기억하십시오.

보시다시피 루프백 인터페이스만 나열되며 호스트에서 80 인터페이스는 볼 수 없습니다. 따라서 네임스페이스를 사용하여 컨테이너가 호스트 인터페이스를 보지 못하도록 성공적으로 방지했습니다. ARP 테이블도 마찬가지입니다. 호스트에서 ARP 명령을 실행하면 항목 목록이 표시되지만 컨테이너 내부에서 실행하면 항목이 표시되지 않습니다. 라우팅 테이블도 마찬가지입니다. 현재로서는 이러한 네트워크 네임스페이스에는 네트워크 연결이 없고 자체 인터페이스가 없으며 기본 호스트 네트워크를 볼 수 없습니다.

 

+ Network Connectivity 

네임스페이스 자체 간의 연결 설정을 먼저 살펴보겠습니다. 케이블을 사용하여 두 개의 물리적 머신을 각 머신의 인터넷 인터페이스에 연결하는 것과 마찬가지로 가상 이더넷 쌍 또는 가상 케이블을 사용하여 두 개의 네임스페이스를 함께 연결할 수 있습니다. 흔히 파이프라고 부르지만 저는 양쪽 끝에 두 개의 인터페이스가 있는 가상 케이블이라고 부르고 싶습니다.
케이블을 생성하려면 유형을 v8로 설정하고 ip link at 명령을 실행하고 두 끝 v8 red 및 v8 blue를 지정합니다. 다음 단계는 각 인터페이스를 적절한 네임스페이스에 연결하는 것입니다. 그렇게 하려면 ip link set v8 red netns red 명령을 사용하십시오. 마찬가지로 파란색 인터페이스를 파란색 네임스페이스에 연결합니다. 그런 다음 이러한 각 네임스페이스에 IP 주소를 할당할 수 있습니다. 일반적인 ip addr 명령을 사용하여 IP 주소를 할당하지만 각 네임스페이스 내에서 사용합니다.

빨간색 네임스페이스에 ip 192.168.15.1을 할당합니다. 그런 다음 파란색 네임스페이스에 ip 192.168.15.2를 할당했습니다. 그런 다음 각 네임스페이스 내의 각 장치에 대해 ip link setup 명령을 사용하여 인터페이스를 불러옵니다. 링크가 작동하고 이제 네임스페이스가 서로 연결할 수 있습니다. 빨간색 네임스페이스에서 ping을 시도하여 파란색의 IP에 도달하십시오. 빨간색 네임스페이스의 ARP 테이블을 보면 MAC 주소가 있는 192.168.15.2에서 파란색 이웃을 식별하는 것을 볼 수 있습니다.
마찬가지로 파란색 네임스페이스에 ARP 테이블을 나열하면 빨간색 이웃으로 식별되는 것을 볼 수 있습니다. 이것을 호스트의 ARP 테이블과 비교하면 호스트 ARP 테이블은 우리가 생성한 이러한 새 네임스페이스에 대해 전혀 모르고 그 안에 생성한 인터페이스에 대해 전혀 모른다는 것을 알 수 있습니다.

이제 네임스페이스가 두 개뿐이었을 때는 효과가 있었습니다. 네임스페이스가 더 많으면 어떻게 해야 할까요? 그들 모두가 서로 의사 소통을 할 수 있게 하려면 어떻게 해야 합니까? 실제 세계에서와 마찬가지로 호스트 내부에 가상 네트워크를 만듭니다.

 

+ Virtual Network
네트워크를 생성하려면 스위치가 필요하므로 가상 네트워크를 생성하려면 가상 스위치가 필요합니다. 따라서 호스트 내에 가상 스위치를 생성하고 여기에 네임스페이스를 연결합니다.

그러나 호스트 내에서 가상 스위치를 어떻게 생성합니까? Linux 브리지라고 하는 기본 솔루션과 개방형 V 스위치 등 여러 솔루션을 사용할 수 있습니다. 이 예에서는 Linux 브리지 옵션을 사용합니다. 내부 브리지 네트워크를 생성하기 위해 유형이 bridge로 설정된 ip link add 명령을 사용하여 호스트에 새 인터페이스를 추가합니다.
이름은 Vnet0입니다. 우리 호스트에 관한 한 그것은 80 인터페이스와 같은 또 다른 인터페이스일 뿐입니다. 다른 인터페이스와 함께 ip link 명령의 출력에 나타납니다. 현재 꺼져 있으므로 켜야 합니다. ip link setup 명령을 사용하여 불러옵니다.
이제 네임스페이스의 경우 이 인터페이스는 연결할 수 있는 스위치와 같습니다. 따라서 호스트를 위한 인터페이스이자 네임스페이스를 위한 스위치라고 생각하십시오.
따라서 다음 단계는 네임스페이스를 이 새로운 가상 네트워크 스위치에 연결하는 것입니다. 이전에는 두 네임스페이스를 직접 연결하기를 원했기 때문에 한쪽 끝에 v8 빨간색 인터페이스가 있고 다른 쪽 끝에 파란색 인터페이스가 있는 케이블 또는 eth 쌍을 만들었습니다. 이제 모든 네임스페이스를 브리지 네트워크에 연결합니다. 따라서 이를 위해서는 새로운 케이블이 필요합니다. 이 케이블은 더 이상 의미가 없으므로 제거하겠습니다. ip link delete 명령을 사용하여 케이블을 삭제합니다. 한쪽 끝이 있는 링크를 삭제하면 다른 쪽 끝은 쌍이기 때문에 자동으로 삭제됩니다.

 

+ Bridge Network
이제 네임스페이스를 브리지에 연결하는 새 케이블을 만들어 보겠습니다. ip link add 명령을 실행하고 이전과 같이 한쪽 끝에 v8 red가 있는 쌍을 생성하지만 이번에는 다른 쪽 끝에 이름이 지정됩니다. 브리지 네트워크에 연결되는 V8 red VR.
이 명명 규칙은 빨간색 네임스페이스와 관련된 인터페이스를 쉽게 식별하는 데 도움이 됩니다.
마찬가지로 파란색 네임스페이스를 브리지 네트워크에 연결하는 케이블을 만듭니다.
이제 케이블이 준비되었으므로 네임스페이스에 연결할 차례입니다.
인터페이스의 한쪽 끝을 red 네임스페이스에 연결하려면 ip link set v8 red netns red 명령을 실행합니다.
다른 쪽 끝을 브리지 네트워크에 연결하려면 v8 red VR 끝에서 ip link set 명령을 실행하고 이에 대한 마스터를 지정합니다.
VNET 제로 네트워크로.
동일한 절차에 따라 파란색 케이블을 파란색 네임스페이스 및 브리지 네트워크에 연결합니다.
이제 이러한 링크에 대한 IP 주소를 설정하고 활성화하겠습니다.
192.168.15.1 및 192.168.15.2 이전에 사용했던 것과 동일한 IP 주소를 사용합니다.
그리고 마지막으로 장치를 켜십시오.
이제 컨테이너는 네트워크를 통해 서로 도달할 수 있습니다.
따라서 동일한 절차에 따라 나머지 두 네임스페이스를 동일한 네트워크에 연결합니다.
이제 네 개의 네임스페이스가 모두 내부 브리지 네트워크에 연결되어 있으며 모두 서로 통신할 수 있습니다.
그들은 모든 IP 주소를 가지고 있습니다.
192.168.15.1, 2, 3, 4.
그리고 호스트에 내 호스트의 IP 192.168.1.2를 할당했음을 기억하십시오.

이러한 네임스페이스에서 이러한 인터페이스 중 하나에 도달하려고 하면 어떻게 됩니까?
작동할까요? 아니요.
내 호스트는 한 네트워크에 있고 네임스페이스는 다른 네트워크에 있습니다.
하지만 내 호스트와 이러한 네임스페이스 간에 연결을 설정하고 싶다면 어떻게 해야 할까요?
virt 스위치는 실제로 호스트의 네트워크 인터페이스라고 말한 것을 기억하십시오.
따라서 호스트의 192.168.15 네트워크에 인터페이스가 있습니다.
이것은 단지 또 다른 인터페이스이기 때문에 우리가 해야 할 일은 IP 주소를 할당하여 이를 통해 네임스페이스에 도달할 수 있도록 하는 것입니다.
ip addr 명령을 실행하여 IP 192.168.15.5를 이 인터페이스로 설정합니다.
이제 로컬 호스트에서 빨간색 네임스페이스를 ping할 수 있습니다.
이제 이 전체 네트워크는 여전히 비공개이며 호스트 내에서 제한된다는 점을 기억하십시오.
네임스페이스 내에서 외부 세계에 도달할 수 없습니다.
또한 외부 세계의 누구도 내부에서 호스팅되는 서비스나 애플리케이션에 접근할 수 없습니다.
외부 세계로 통하는 유일한 문은 호스트의 이더넷 포트입니다.
그렇다면 이더넷 포트를 통해 회선 네트워크에 도달하도록 이 브리지를 구성하려면 어떻게 해야 할까요?
주소가 192.168.1.3인 회선 네트워크에 다른 호스트가 연결되어 있다고 가정합니다.
내 네임스페이스 내에서 이 호스트에 도달하려면 어떻게 해야 합니까?
내 네임스페이스에서 이 호스트에 ping을 시도하면 어떻게 됩니까?
파란색 네임스페이스는 내가 현재 네트워크인 192.168.15와 다른 192.168.1에서 네트워크에 연결하려고 시도하고 있음을 확인합니다.
따라서 해당 네트워크를 찾는 방법을 알아보기 위해 라우팅 테이블을 살펴봅니다.
라우팅 테이블에는 다른 네트워크에 대한 정보가 없습니다.
그래서 네트워크에 연결할 수 없다는 메시지가 나타납니다.
따라서 외부 세계에 대한 관문이나 문을 제공하기 위해 라우팅 테이블에 항목을 추가해야 합니다.
그렇다면 그 게이트웨이를 어떻게 찾을 수 있을까요?
이전에 논의한 것처럼 도어 또는 게이트웨이는 다른 네트워크에 연결되는 로컬 네트워크의 시스템입니다.
그렇다면 192.168.15 네트워크인 파란색 네임스페이스에 로컬인 네트워크에 하나의 인터페이스가 있고 외부 LAN 네트워크에도 연결되는 시스템은 무엇입니까?
다음은 논리적인 견해입니다.

 

+ Local Host
로컬 호스트에는 개인 네트워크를 연결하는 인터페이스가 있으므로 네임스페이스를 ping할 수 있습니다. 따라서 로컬 호스트는 두 네트워크를 함께 연결하는 게이트웨이입니다. 이제 파란색 네임스페이스에 행 항목을 추가하여 192.168.15.5의 게이트웨이를 통해 모든 트래픽을 192.168.1 네트워크로 라우팅할 수 있습니다.
이제 호스트에는 두 개의 IP 주소가 있습니다. 하나는 1925.168.15.5의 브리지 네트워크에 있고 다른 하나는 192.168.1.2의 외부 네트워크에 있습니다.

경로에서 사용할 수 있습니까?
아니요, 파란색 네임스페이스는 192.168.15.5의 로컬 네트워크에 있는 게이트웨이에만 도달할 수 있기 때문입니다.
기본 게이트웨이는 경로에 추가할 때 네임스페이스에서 연결할 수 있어야 합니다.
지금 ping을 시도하면 더 이상 네트워크에 연결할 수 없다는 메시지가 표시되지 않지만 여전히 ping에서 응답을 받지 못합니다.

 

무엇이 문제일까요?
우리는 홈 네트워크에서 라우터를 통해 외부 인터넷에 도달하려고 시도한 이전 강의 중 하나에서 유사한 상황에 대해 이야기했습니다.
우리의 홈 네트워크에는 대상 네트워크가 알지 못하는 내부 사설 IP 주소가 있으므로 다시 연결할 수 없습니다.
이를 위해 자체 주소를 사용하여 자체 이름으로 LAN에 메시지를 보낼 수 있도록 여기에서 게이트웨이 역할을 하는 호스트에서 NAT 활성화가 필요합니다.

 

+ NAT

Network Address Translation 의 약자로써 네트워크 주소 변환을 의미합니다. 기본적으로 192.168.xx와 같은 사설(Private) IP 주소로는 외부와 통신(인터넷 연결 등) 할 수 없습니다. 외부와 통신할 수있는 IP주소는 오직 인터넷 IP 주소 관리 기관에서 공식적으로 발급한 공인(Public) IP 주소 뿐 입니다.

 

그렇다면 호스트에 NAT 기능을 추가하려면 어떻게 해야 할까요?
IP 테이블을 사용하여 이를 수행해야 합니다.
포스트 라우팅 체인의 NAT IP 테이블에 새 규칙을 추가하여 원본 네트워크에서 오는 모든 패킷의 발신 주소를 위장하거나 교체합니다.
네임스페이스가 인터넷에 연결되기를 원합니다. 라우팅 테이블에 사설IP(192.168.1)에 대한 경로가 있지만 다른 경로는 없습니다. 하지만 네임스페이스가 있는 호스트는 모든 네트워크에 도달이 가능한 상태입니다. 그래서 클러스터 내부에서 외부 네트워크를 도달하기 위해서는 호스트를 지정하는 기본 게이트웨이를 추가합니다.

 

+ Connectivity
이제 외부 세계에서 네임스페이스 내부로의 연결은 어떻습니까?
예를 들어 파란색 네임스페이스는 포트 80에서 웹 애플리케이션을 호스팅합니다.
현재 네임스페이스는 내부 사설 네트워크에 있으며 외부 세계의 다른 네트워크에 있는 다른 호스트에서 이 개인 네트워크에 대해 알지 못합니다. 이러한 통신을 가능하게 하려면 두 가지 옵션이 있습니다.
첫 번째, 개인 네트워크의 ID를 두 번째 호스트에 제공하는 것입니다. 따라서 기본적으로 두 번째 호스트에 IP 경로 항목을 추가하여 호스트에 네트워크 192.168.15가 192.168.1.2의 호스트를 통해 도달할 수 있음을 알려줍니다.

두 번째, 로컬 호스트의 포트 80으로 들어오는 모든 트래픽이 파란색 네임스페이스에 할당된 IP의 포트 80으로 전달되도록 IP 테이블을 사용하여 포트 전달 역할을 추가하는 것입니다.

 

204. Prerequisite - Docker Networking

Docker의 네트워킹

- none 네트워크

네트워크가 없는 경우 Docker 컨테이너는 어떤 네트워크에도 연결되지 않습니다.
컨테이너는 외부 세계에 도달할 수 없으며 외부 세계의 누구도 컨테이너에 도달할 수 없습니다.

여러 컨테이너에 있는 경우 모든 컨테이너는 네트워크의 일부가 되지 않고 생성되며 서로 또는 외부 세계와 통신할 수 없습니다.

 

- 호스트 네트워크
호스트 네트워크를 사용하면 컨테이너가 호스트 네트워크에 연결됩니다. 호스트와 컨테이너 사이에는 네트워크 격리가 없습니다.
컨테이너의 포트 80에서 수신 대기하는 웹 애플리케이션을 배포하는 경우 추가 포트 매핑을 수행하지 않고도 호스트의 포트 80에서 웹 애플리케이션을 사용할 수 있습니다. 
동일한 포트에서 수신 대기하는 동일한 컨테이너의 다른 인스턴스를 실행하려고 하면 호스트 네트워킹을 공유하므로 작동하지 않으며 두 프로세스가 동시에 동일한 포트에서 수신 대기할 수 없습니다.

 

- 브리지 네트워크
이 경우 Docker 호스트와 컨테이너가 연결되는 내부 사설 네트워크가 생성됩니다. 네트워크는 기본적으로 172.17.0.0 주소를 가지며 이 네트워크에 연결하는 각 장치는 이 네트워크에서 자체 내부 사설 네트워크 주소를 얻습니다.
Docker가 호스트에 설치되면 기본적으로 Bridge라는 내부 사설망이 생성됩니다. docker network ls 명령을 실행하면 이를 볼 수 있습니다.

 

이제 Docker는 Bridge라는 이름으로 네트워크를 호출하지만 

호스트에서는 네트워크가 Docker0이라는 이름으로 생성됩니다.
IP 링크 명령의 출력에서 이를 확인할 수 있습니다. 
Docker는 유형이 브리지로 설정된 IP 링크 추가 명령을 실행하여 네임스페이스에 대한 비디오에서 본 것과 유사한 기술을 내부적으로 사용합니다. 따라서 Docker network ls 출력의 name bridge는 호스트의 Docker0이라는 이름을 나타냅니다.
그것들은 하나이고 같은 것입니다. 
또한 인터페이스 또는 네트워크가 현재 작동 중지된 상태입니다.

브리지 네트워크는 호스트에 대한 인터페이스와 같지만 호스트 내의 네임스페이스 또는 컨테이너에 대한 스위치라고 말했습니다.
따라서 호스트의 Docker0 인터페이스에는 IP 172.17.0.1이 할당됩니다.
IP ADDR 명령의 출력에서 이를 확인할 수 있습니다.
컨테이너가 생성될 때마다 Docker는 컨테이너에 대한 네트워크 네임스페이스를 생성합니다.

 

그렇다면 Docker는 컨테이너 또는 해당 네트워크 네임스페이스를 브리지 네트워크에 어떻게 연결합니까?
이 강의의 나머지 부분에서 컨테이너와 네트워크 네임스페이스는 같은 의미입니다.
컨테이너라고 하면 Docker가 해당 컨테이너에 대해 생성한 네트워크 네임스페이스를 의미합니다.

 

그렇다면 Docker는 컨테이너를 브리지에 어떻게 연결합니까?
이전에 했던 것처럼 각 끝에 두 개의 인터페이스가 있는 가상 케이블인 케이블을 생성합니다.
여기에서 Docker가 무엇을 생성했는지 알아봅시다.
Docker 호스트에서 IP 링크 명령을 실행하면 로컬 브리지인 Docker0에 연결된 인터페이스의 한쪽 끝이 표시됩니다.
동일한 명령을 다시 실행하면 이번에는 네임스페이스가 있는 대시 끝 옵션을 사용하여 컨테이너 네임스페이스 내 인터페이스의 다른 쪽 끝을 나열합니다.
인터페이스는 또한 네트워크 내에서 할당된 IP를 가져옵니다.
IP ADDR 명령을 실행하여 컨테이너의 네임스페이스 내에서 이를 볼 수 있습니다.
컨테이너에 172.17.0.3이 할당됩니다.
컨테이너에 연결하고 할당된 IP 주소를 확인하여 이를 볼 수도 있습니다.
새 컨테이너를 만들 때마다 동일한 절차를 따릅니다.
Docker는 네임스페이스를 만들고 인터페이스 쌍을 만들고 한쪽 끝을 컨테이너에 연결하고 다른 쪽 끝을 브리지 네트워크에 연결합니다.
인터페이스 쌍은 번호를 사용하여 식별할 수 있습니다.
이상하고 짝을 이룬다. 아홉과 열은 한 쌍입니다. 일곱과 여덟은 또 다른 것입니다. 11과 12는 한 쌍입니다.
컨테이너는 이제 모두 네트워크의 일부입니다. 그들은 모두 서로 통신할 수 있습니다.

이제 포트 매핑을 살펴보겠습니다.

우리가 만든 컨테이너는 Nginx이므로 포트 80에서 웹 페이지를 제공하는 웹 애플리케이션입니다.
컨테이너가 호스트 내부의 사설 네트워크 내에 있기 때문에 동일한 네트워크의 다른 컨테이너 또는 호스트 자체만 이 웹 페이지에 액세스할 수 있습니다.
포트 80의 Docker 호스트 내에서 컨테이너의 IP로 curl을 사용하여 웹 페이지에 액세스하려고 하면 웹 페이지가 표시됩니다.
호스트 외부에서 동일한 작업을 시도하면 웹 페이지를 볼 수 없습니다.
외부 사용자가 컨테이너에서 호스팅되는 애플리케이션에 액세스할 수 있도록 Docker는 포트 게시 또는 포트 매핑 옵션을 제공합니다.
컨테이너를 실행할 때 Docker에 Docker 호스트의 포트 8080을 컨테이너의 포트 80에 매핑하도록 지시하십시오.
이렇게 하면 Docker 호스트의 IP와 포트 8080을 사용하여 웹 애플리케이션에 액세스할 수 있습니다.
Docker 호스트의 포트 8080에 대한 모든 트래픽은 컨테이너의 포트 80으로 전달됩니다.

이제 모든 외부 사용자와 기타 애플리케이션 또는 서버가 이 URL을 사용하여 호스트에 배포된 애플리케이션에 액세스할 수 있습니다.
그러나 Docker는 어떻게합니까?

 

한 포트에서 다른 포트로 트래픽을 어떻게 전달합니까?
  요구 사항은 한 포트에서 들어오는 트래픽을 서버의 다른 포트로 전달하는 것입니다. 이를 위해 NAT 규칙을 만듭니다. 
 IP 테이블을 사용하여 대상 포트를 8080에서 80으로 변경하기 위해 사전 라우팅 체인에 규칙을 추가하기 위해 NAT 테이블에 항목을 만듭니다.  Docker는 동일한 방식으로 수행합니다. Docker는 Docker 체인에 규칙을 추가하고 컨테이너의 IP도 포함하도록 대상을 설정합니다. IP 테이블에 규칙을 나열하면 Docker가 생성하는 규칙을 볼 수 있습니다. 

 

205. Prerequisite - CNI

 컨테이너 네트워킹 인터페이스

동일한 네트워킹 문제를 해결하기 위해 조사하고 최종적으로 식별함으로써 약간의 차이가 있는 유사한 접근 방식을 개발함.

Container Network Interface컨테이너 네트워크 인터페이스를 결성하여 모든 사람이 단일 표준 세트를 준수할 수 있도록 솔루션을 개발함.

 

206.  Cluster Networking

이 강의는 Kubernetes 클러스터의 마스터 및 작업자 노드에 필요한 네트워킹 구성을 설명한다.
Kubernetes 클러스터는 마스터와 워커 노드가 있고, 각 노드에는 네트워크 인터페이스가 구성되어 있다.
호스트에는 고유한 호스트 이름 세트와 고유한 MAC 주소가 있어야 합니다.

포트설정
마스터 

 ㄴ API 서버: 6443

작업자 노드

 ㄴ Kube 제어 도구, 외부 사용자 및 기타 모든 제어 평면 구성 요소는 이 포트를 통해 Kube API 서버에 액세스합니다.
kubelet포트: 10250
Kube 스케줄러 포트: 10259
Kube 컨트롤러 관리자 포트: 10257

etcd 서버 포트: 2379

etcd 클라이언트 포트: 2380

외부 액세스를 위한 서비스 예약 포트:  30000-32767

열 포트 목록은 Kubernetes 설명서 페이지에서도 사용할 수 있으므로 TCP 또는 Azure, 또는 AWS와 같은 클라우드 환경에서 방화벽, IP 테이블 규칙 또는 네트워크 보안 그룹의 노드에 대한 네트워킹을 설정할 때 이를 고려하십시오. 

작동하지 않는 경우 조사하는 동안 찾을 수 있는 한 곳입니다.
연습 세션으로 이동하여 기존 환경에서 네트워킹 설정을 탐색합니다.
정보를 찾는 동안 이러한 명령을 편리하게 보관하십시오.

 

Kubernetes 클러스터를 탐색하고 인터페이스, IP, 호스트 이름, 포트 등에 대한 정보를 보는 간단한 연습부터 시작하겠습니다.

 

207. Important Note about CNI and CKA Exam

CNI 및 CKA 시험에 대한 중요 참고 사항

Kubernetes 클러스터에서 Network Addons 배포에 대한 중요한 팁입니다.

 

다음 실습에서는 네트워크 애드온을 다룰 것입니다. 여기에는 클러스터에 네트워크 플러그인 설치가 포함됩니다. weave-net을 예로 사용했지만 여기에 설명된 모든 플러그인을 사용할 수 있습니다.

https://kubernetes.io/docs/concepts/cluster-administration/addons/

https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model

 

CKA 시험에서 네트워크 애드온을 배포해야 하는 문제의 경우 특별히 지시되지 않는 한 위 링크에 설명된 솔루션을 사용할 수 있습니다.

 

그러나 현재 설명서에는 타사 네트워크 애드온을 배포하는 데 사용되는 정확한 명령에 대한 직접적인 참조가 포함되어 있지 않습니다.

위의 링크는 시험에서 사용할 수 없는 타사/공급업체 사이트 또는 GitHub 리포지토리로 리디렉션됩니다. 이는 Kubernetes 문서의 내용을 벤더 중립적으로 유지하기 위해 의도적으로 수행되었습니다.

현재로서는 위브 네트워크 애드온을 배포하기 위한 정확한 명령을 찾을 수 있는 문서 내 한 곳이 여전히 있습니다.

 

https://v1-22.docs.kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/#steps-for-the-first-control-plane-node(2 단계)

 

209. Practice Test - Explore Kubernetes Environment

 

What is the network Interface?

$ ip address

eth0@~~

 

What is the MAC address of the interface on the controlplane node?

$ ip address show etho0

 

What is the IP address assigned to node01?

$ kubectl get nodes -o wide 

=> internal-ip 확인

 

What is the MAC address assigned to node01?

$ ip address

=> ip로 mac 주소 확인

 

What is the MAC address assigned to node01?

$ ip link show eth0

16996: eth0@if16997: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:c0:27:89:09 brd ff:ff:ff:ff:ff:ff link-netnsid 0

  설명: ip address를 통해 node01의 ip는 확인할 수 없었다. 현재는 controlplane 서버에서 kubectl 명령어를 수행했기 때문이다.

 

// node01 접속
controlplane ~ ➜  ssh node01

// ip address 수행
root@node01 ~ ➜  ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default 
    link/ether 2e:7f:77:3d:f2:fd brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever
15337: eth0@if15338: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
    link/ether 02:42:c0:27:89:0c brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.39.137.12/24 brd 192.39.137.255 scope global eth0
       valid_lft forever preferred_lft forever
15339: eth1@if15340: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:19:00:14 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet 172.25.0.20/24 brd 172.25.0.255 scope global eth1
       valid_lft forever preferred_lft forever
       
       
// node01로 접속하여 실행할 수 있는 다른 명령어들
$ ip a | grep -B2 192

3912: eth0@if3913: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
    link/ether 02:42:c0:0c:20:09 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.12.32.9/24 brd 192.12.32.255 scope global eth0

$ip link show eth0

3912: eth0@if3913: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:c0:0c:20:09 brd ff:ff:ff:ff:ff:ff link-netnsid 0

 

 

 

We use Containerd as our container runtime. What is the interface/bridge created by Containerd on the controlplane node?

ㅇ I can't know what is the bridge??

 

 ㅇ ip address show type bridge.

 

 

What is the state of the interface cni0?

3: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether a6:8d:69:b9:f2:8a brd ff:ff:ff:ff:ff:ff

 

If you were to ping google from the controlplane node, which route does it take?

What is the IP address of the Default Gateway?

$ controlplane ~  ip route show default
default via 172.25.0.1 dev eth1

 

 

What is the port the kube-scheduler is listening on in the controlplane node?

controlplane ~ ➜  netstat -nplt | grep scheduler
tcp        0      0 127.0.0.1:10259         0.0.0.0:*               LISTEN      3326/kube-scheduler

 

Notice that ETCD is listening on two ports. Which of these have more client connections established?

netstat -anp | grep etcd
tcp        0      0 192.39.137.9:2379       0.0.0.0:*               LISTEN      3341/etcd           
tcp        0      0 127.0.0.1:2379          0.0.0.0:*               LISTEN      3341/etcd           
tcp        0      0 192.39.137.9:2380       0.0.0.0:*               LISTEN      3341/etcd           
tcp        0      0 127.0.0.1:2381          0.0.0.0:*               LISTEN      3341/etcd           
tcp        0      0 127.0.0.1:2379          127.0.0.1:33560         ESTABLISHED 3341/etcd           
tcp        0      0 127.0.0.1:2379          127.0.0.1:33790         ESTABLISHED 3341/etcd           
tcp        0      0 127.0.0.1:2379          127.0.0.1:33808         ESTABLISHED 3341/etcd           
tcp        0      0 127.0.0.1:2379          127.0.0.1:33936         ESTABLISHED 3341/etcd           
tcp        0      0 127.0.0.1:2379          127.0.0.1:33396         ESTABLISHED 3341/etcd           
tcp        0      0 127.0.0.1:2379          127.0.0.1:33818         ESTABLISHED 3341/etcd

 

 

211. Pod Networking

Pod는 어떻게 서로 통신을 하는가?

Kubernetes는 모든 Pod가 고유한 IP 주소를 가지며 모든 Pod가 해당 IP 주소를 사용하여 동일한 노드 내의 다른 모든 Pod에 도달할 수 있어야 합니다.

 노드간에 브릿지 네트워크를 구성합니다. 이를 구성하기 위해 우리가 사용할 모든 명령이 포함된 파일일 뿐이며 앞으로 각 컨테이너에 대해 이것을 여러 번 실행할 수 있습니다.

컨테이너를 네트워크에 연결하려면 파이프 또는 가상 네트워크 케이블이 필요합니다. ip link add 명령을 사용하여 생성합니다. 그런 다음 ip addr 명령을 사용하여 IP 주소를 할당합니다.

각 컨테이너를 네트워크에 연결하기 위해 스크립트를 수동으로 실행했습니다. 물론 우리는 그렇게 하고 싶지 않습니다. 수천 개의 포드가 있는 대규모 환경에서와 같이 매분 생성됩니다.

 

kubelet은 CNI 구성을 보고 실행될 때 명령줄 인수로 전달되었습니다. 스크립트의 이름을 식별합니다. 그런 다음 CNI의 bin 디렉토리에서 스크립트를 찾습니다. 그런 다음 add 명령으로 스크립트를 실행합니다. 컨테이너의 이름과 네임스페이스 ID입니다. 그런 다음 스크립트가 나머지를 처리합니다.

 

212. CNI in kubernetes

이번 강의에서는 쿠버네티스가 어떻게 CNI에서 사용할 수 있는 지원되는 다양한 플러그인을 사용하도록 구성되어 있습니다.

CNI bin 디렉터리에는 지원되는 모든 CNA 플러그인이 있습니다. 실행 파일로, 브리지, dscp, 플란넬 등. CNI conflict(충돌??) 디렉토리에는 구성 파일 세트가 있습니다.

213. Note CNI Weave

Important Update: -

Before going to the CNI weave lecture, we have an update for the Weave Net installation link. They have announced the end of service for Weave Cloud.

To know more about this, read the blog from the link below: -

https://www.weave.works/blog/weave-cloud-end-of-service

As an impact, the old weave net installation link won’t work anymore: -

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Instead of that, use the below latest link to install the weave net: -

kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

Reference links: -

1. https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#-installation
2. https://github.com/weaveworks/weave/releases

214. CNI weave

이제 Weave 솔루션이 어떻게 작동하는지 살펴보겠습니다. 하나의 솔루션을 잘 이해하면 이것을 연관시켜서 다른 솔루션에도 잘 적용할 수 있다. 이제 패킷이 한 포드에서 다른 포드로 전송될 때 출발 노드에서 Weave가 이 패킷을 새 패킷으로 캡슐화합니다. 새로운 소스와 대상 네트워크를 통해 전송합니다. 반대편에 다른 Weave 에이전트가 패킷을 검색하고 캡슐화 해제하여 패킷을 올바른 포드로 라우팅합니다.

 

Kubernetes 클러스터에 Weave를 어떻게 배포합니까?

Weave 피어가 DaemonSet으로 클러스터의 모든 노드에 배포됩니다.

 

215. Practice Test - Explore CNI

Inspect the kubelet service and identify the container runtime endpoint value is set for Kubernetes.

controlplane ~ ➜  ps -aux | grep kubelet | grep --color endpoint
root        4303  0.0  0.0 3938376 108892 ?      Ssl  09:35   0:20 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtimeendpoint=unix:///var/run/containerd/containerd.sock --pod-infra-container-image=registry.k8s.io/pause:3.9

 

 

What is the path configured with all binaries of CNI supported plugins?

 

 

 

217. Practice Test - Deploy Network Solution

Warning  FailedCreatePodSandBox  1s    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "919c6d0a5a277990d3b850455961e506b3a1550c3f6a929f09c22b37fe8b5fa7": plugin type="weave-net" name="weave" failed (add): unable to allocate IP address: Post "http://127.0.0.1:6784/ip/919c6d0a5a277990d3b850455961e506b3a1550c3f6a929f09c22b37fe8b5fa7": dial tcp 127.0.0.1:6784: connect: connection refused controlplane ~/weave ➜  k apply -f weave-daemonset-k8s.yaml  serviceaccount/weave-net created clusterrole.rbac.authorization.k8s.io/weave-net created clusterrolebinding.rbac.authorization.k8s.io/weave-net created role.rbac.authorization.k8s.io/weave-net created rolebinding.rbac.authorization.k8s.io/weave-net created daemonset.apps/weave-net created

 

 

219. IP Address Management - Weave

 

그냥 weave yaml apply가 다임.

220. Practice Test - Networking Weave

what is the Newworking Solution?

controlplane /etc/cni/net.d ➜  cat 10-weave.conflist 
{
    "cniVersion": "0.3.0",
    "name": "weave",
    "plugins": [
        {
            "name": "weave",
            "type": "weave-net",
            "hairpinMode": true
        },
        {
            "type": "portmap",
            "capabilities": {"portMappings": true},
            "snat": true
        }
    ]
}

 

Identify the name of the bridge network/interface created by weave on each node.

controlplane ~ ➜  ip link show type bridge
4: weave: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 22:05:17:46:85:d1 brd ff:ff:ff:ff:ff:ff

 

What is the POD IP address range configured by weave?

controlplane /etc/cni/net.d ➜  ip address show weave 
4: weave: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UP group default qlen 1000
    link/ether 22:05:17:46:85:d1 brd ff:ff:ff:ff:ff:ff
    inet 10.244.0.1/16 brd 10.244.255.255 scope global weave
       valid_lft forever preferred_lft forever

 

What is the default gateway configured on the PODs scheduled on node01?
Try scheduling a pod on node01 and check ip route output

controlplane /etc/cni/net.d ➜  ssh node01

root@node01 ~ ➜  ip route
default via 172.25.0.1 dev eth1 
10.244.0.0/16 dev weave proto kernel scope link src 10.244.192.0 
172.25.0.0/24 dev eth1 proto kernel scope link src 172.25.0.60 
192.33.199.0/24 dev eth0 proto kernel scope link src 192.33.199.9

 

222. Service Networking

223. Practice Test - Service Networking

What network range are the nodes in the cluster part of?

controlplane ~ ➜  ip a | grep eth0
13197: eth0@if13198: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
    inet 192.35.145.3/24 brd 192.35.145.255 scope global eth0

controlplane ~ ➜  ipcalc -b 192.35.145.3
Address:   192.35.145.3         
Netmask:   255.255.255.0 = 24   
Wildcard:  0.0.0.255            
=>
Network:   192.35.145.0/24      
HostMin:   192.35.145.1         
HostMax:   192.35.145.254       
Broadcast: 192.35.145.255       
Hosts/Net: 254                   Class C

 

What network range are the nodes in the cluster part of?

controlplane ~ ✖ k logs -n kube-system weave-net-8zh4f 
Defaulted container "weave" out of: weave, weave-npc, weave-init (init)
INFO: 2023/05/10 19:01:35.213040 Command line options: map[conn-limit:200 datapath:datapath db-prefix:/weavedb/weave-net docker-api: expect-npc:true http-addr:127.0.0.1:6784 ipalloc-init:consensus=1 ipalloc-range:10.244.0.0/16 metrics-addr:0.0.0.0:6782 name:7e:18:23:73:9d:8d nickname:node01 no-dns:true no-masq-local:true port:6783]

ㅇ ipalloc-range:10.244.0.0/16

 

What is the IP Range configured for the services within the cluster?

controlplane ~ ➜  cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep cluster-ip-range
    - --service-cluster-ip-range=10.96.0.0/12

What type of proxy is the kube-proxy configured to use?

controlplane /usr/local/bin ➜  k logs -n kube-system kube-proxy-69zbr 
I0510 19:01:17.690538       1 node.go:163] Successfully retrieved node IP: 192.35.145.3
I0510 19:01:17.690682       1 server_others.go:109] "Detected node IP" address="192.35.145.3"
I0510 19:01:17.690716       1 server_others.go:535] "Using iptables proxy"
I0510 19:01:17.786282       1 server_others.go:176] "Using iptables Proxier"
I0510 19:01:17.786321       1 server_others.go:183] "kube-proxy running in dual-stack mode" ipFamily=IPv4
I0510 19:01:17.786329       1 server_others.go:184] "Creating dualStackProxier for iptables"
I0510 19:01:17.786361       1 server_others.go:465] "Detect-local-mode set to ClusterCIDR, but no IPv6 cluster CIDR defined, , defaulting to no-op detect-local for IPv6"
I0510 19:01:17.786410       1 proxier.go:242] "Setting route_localnet=1 to allow node-ports on localhost; to change this either disable iptables.localhostNodePorts (--iptables-localhost-nodeports) or set nodePortAddresses (--nodeport-addresses) to filter loopback addresses"