[CKA] Networking - 1

CKA (https://www.credly.com/org/the-linux-foundation/badge/cka-certified-kubernetes-administrator)

Networking

선수 지식 - Switching Routing

• 네트워크란 무엇인가? 
• 클라우드에 두 대의 컴퓨터(A와 B), 노트북, 데스크탑, 가상 머신이 있는 경우 시스템 A가 B에 어떻게 도달하는가? 
• 이를 스위치에 연결하면 스위치는 두 시스템을 모두 포함하는 네트워크를 생성한다. 각 호스트에는 스위치에 연결하기 위한 물리적 또는 가상 인터페이스가 필요하다.
• 호스트의 인터페이스를 보려면 IP link 명령을 사용
• 이 경우 스위치에 연결하기 위해 Eth0이라는 인터페이스를 살펴보자. 네트워크 주소가 192.168.1.0인 네트워크라고 가정한다. 그런 다음 시스템에 동일한 네트워크의 IP 주소를 할당하면된다. 이렇게 하려면 ip addr 명령을 사용하면된다. 링크가 연결되고 IP 주소가 할당되면 이제 컴퓨터는 스위치를 통해 서로 통신할 수 있다.
• 스위치는 네트워크 내 호스트로부터 패킷을 수신하고 해당 패킷을 동일한 네트워크 내의 다른 시스템으로 전달하는 네트워크 내 통신만 활성화할 수 있다.

• 다른 네트워크로의 통신은 어떻게 하는가?
• 라우터는 두 개의 네트워크를 연결하는 데 도움이 된다. 이것은 지능형 장치이다. 따라서 이를 다른 네트워크 포트를 가진 또 다른 서버로 생각하면 된다. 두 개의 별도 네트워크에 연결되어 있으므로 각 네트워크에는 하나의 IP가 할당된다. 첫 번째 네트워크는 IP 주소 192.168.1.1을 할당하고 두 번째 네트워크는 2.1을 할당한다. 이제 라우터가 두 네트워크 모두에 연결되었으므로 두 네트워크 간의 통신을 활성화할 수 있다. 
• 시스템 B가 시스템 C에 패킷을 보내려고 할 때 패킷을 보내는 방법을 어떻게 아는가? 
• 라우터는 네트워크의 또 다른 장치일 뿐이다. 다른 장치가 많이 있을 수 있다. 여기에서 시스템에 대한 게이트웨이나 경로를 구성할 수 있다. 네트워크가 방이라면 게이트웨이는 다른 네트워크나 인터넷으로 나가는 문이다. 시스템이 문을 통과하려면 위치를 알아야 합니다.

• 여기에서 시스템에 대한 게이트웨이나 경로를 구성할 수 있다. 네트워크가 방이라면 게이트웨이는 다른 네트워크나 인터넷으로 나가는 문이다. 시스템이 문을 통과하려면 위치를 알아야 한다.

• 시스템의 기존 라우팅 구성을 보려면 'route' 명령을 실행하면된다. 커널의 라우팅 테이블을 표시한다.
• 보시다시피 현재로서는 라우팅 구성이 없다. 이 조건에서는 시스템 B가 시스템 C에 도달할 수 없습니다. 192.168.1.0 범위의 동일한 네트워크 내의 다른 시스템에만 도달할 수 있다. 네트워크 192.168.2.0의 시스템에 도달하도록 시스템 B의 게이트웨이를 구성하려면 'ip Route add' 명령을 실행하고 192.168.1.1의 도어 또는 게이트웨이를 통해 192.168.2.0 네트워크에 연결할 수 있음을 지정해야한다.
• 'route' 명령을 다시 실행하면 라우터를 통해 192.168.2.0 시리즈 네트워크에 도달하기 위한 경로가 추가되었음을 알 수 있다. 이제 모든 시스템에서 이를 구성해야 한다는 점을 기억 해야한다. 예를 들어, 시스템 C가 시스템 B로 패킷을 보내려면 시스템 C의 라우팅 테이블에 경로를 추가해야 IP 주소 2.1로 구성된 라우터를 통해 1.0의 네트워크에 액세스할 수 있다.

• 이제 이러한 시스템이 인터넷에 액세스해야 한다고 가정해보자
• 인터넷의 172.217.194.0 네트워크에서 Google에 액세스해야 한다고 가정 해보자. 따라서 라우터를 인터넷에 연결한 다음 라우팅 테이블에 새 경로를 추가하여 모든 트래픽을 라우터를 통해 네트워크 172.217.194로 라우팅한다.

• 인터넷의 다양한 네트워크에는 매우 다양한 사이트가 있습니다. 각 네트워크에 대해 동일한 라우터의 IP 주소에 대한 라우팅 테이블 항목을 추가하는 대신 경로를 모르는 네트워크에 대해 이 라우터를 기본 게이트웨이로 사용한다고 간단히 말할 수 있다. 이렇게 하면 기존 네트워크 외부의 네트워크에 대한 모든 요청이 이 특정 라우터로 전달된다.
• 따라서 이와 같은 간단한 설정에서는 기본 게이트웨이가 라우터의 IP 주소로 설정된 단일 라우팅 테이블 항목만 있으면 된다. 기본값이라는 단어 대신 0.0.0.0이라고 말할 수도 있습니다. 이는 모든 IP 대상을 의미한다. 이 두 줄은 모두 같은 의미다. 게이트웨이 필드의 0.0.0.0 항목은 게이트웨이가 필요하지 않음을 나타냅니다. 예를 들어, 이 경우 시스템 C가 192.168.2.0 네트워크의 모든 장치에 액세스하려면 자체 네트워크에 있으므로 게이트웨이가 필요하지 않습니다.

• 그러나 네트워크에 여러 개의 라우터가 있다고 가정해 보겠다. 하나는 인터넷용이고 다른 하나는 내부 사설망용이다. 그런 다음 각 네트워크에 대해 두 개의 별도 항목이 필요하다. 내부 사설 네트워크에 대한 항목 하나와 공용 네트워크를 포함한 기타 모든 네트워크에 대한 기본 게이트웨이가 포함된 다른 항목이다. 따라서 시스템에서 인터넷에 연결하는 데 문제가 있는 경우 이 라우팅 테이블과 기본 게이트웨이 구성을 시작하는 것이 좋다.

• 이제 Linux 호스트를 라우터로 설정하는 방법을 살펴보자.
• 세 개의 호스트 A, B, C가 있다. A와 B는 네트워크 192.168.1에 연결되고 B와 C는 192.168.2의 다른 네트워크에 연결된다. 따라서 호스트 B는 8.0과 8.1의 두 인터페이스를 사용하여 두 네트워크에 모두 연결된다. A의 IP는 192.168.1.5이다. C에는 192.168.2.5가 있다. 그리고 B는 네트워크 1.6과 2.6 모두에 IP를 가지고 있다. A가 C와 대화하도록 하려면 어떻게 해야 하는가? 기본적으로 A에서 2.5로 ping을 시도하면 네트워크에 연결할 수 없다는 메시지가 나타난다. 그리고 이제 우리는 그 이유를 알고 있습니다.
• 호스트 A는 192.168.2에서 네트워크에 연결하는 방법을 모른다. 우리는 호스트 A에게 네트워크 2.0 에 대한 문이나 게이트웨이가 호스트 B를 통과한다고 알려야 한다. 그리고 라우팅 테이블 항목을 추가하여 이를 수행한다. 게이트웨이 192.168.1.6을 통해 네트워크 192.168.2에 액세스하는 경로를 추가한다. 패킷이 호스트 C를 통과하려면 호스트 C는 호스트 A로 응답을 다시 보내야 한다. 호스트 C가 192.168.1 네트워크에서 호스트 A에 연결하려고 하면 동일한 문제에 직면하게 된다. 따라서 호스트 C에게 라우터 역할을 하는 호스트 B를 통해 호스트 A에 도달할 수 있음을 알려야 한다. 따라서 호스트 C의 라우팅 테이블에 유사한 항목을 추가한다. 이번에는 네트워크 192.168.1.0에 도달하고 192.168.2.6에서 호스트 B와 통신하라고 말한다.
•  

• 지금 ping을 시도하면 더 이상 네트워크에 연결할 수 없다는 오류 메시지가 표시되지 않는다. 이는 라우팅 항목이 옳다는 것을 의미한다. 하지만 우리는 여전히 어떤 응답도 받지 못하고 있다.
• 기본적으로 Linux에서는 패킷이 한 인터페이스에서 다음 인터페이스로 전달되지 않는다. 예를 들어 호스트 B의 Eth0에서 수신된 패킷은 Eth1을 통해 다른 곳으로 전달되지 않는다. 보안상의 이유로 이 방법을 사용한다. 예를 들어, Eth0을 개인 네트워크에 연결하고 Eth1을 공용 네트워크에 연결한 경우 명시적으로 허용하지 않는 한 공용 네트워크의 누구도 개인 네트워크에 메시지를 쉽게 보내는 것을 원하지 않는다. 그러나 이 경우에는 둘 다 개인 네트워크이고 둘 사이의 통신이 안전하다는 것을 알고 있으므로 호스트 B가 한 네트워크에서 다른 네트워크로 패킷을 전달하도록 허용할 수 있다.
• 호스트가 인터페이스 간에 패킷을 전달할 수 있는지 여부는 이 시스템의 /proc/sys/net/ipv4/ip_forward 파일 설정에 따라 결정된다. 기본적으로 이 파일의 값은 0으로 설정되어 있으며 이는 전달되지 않음을 의미한다. 이것을 1로 설정하면 핑이 진행되는 것을 볼 수 있다. 이 값을 설정하고나서 재부팅 시 변경 사항이 유지되지 않는다. 이를 위해서는 /etc/sysctl.conf 파일에서 동일한 값을 수정해야 한다.

• ip link는 호스트의 인터페이스를 나열하고 수정하는 데 사용된다.
• ip addr 명령은 해당 인터페이스에 할당된 IP 주소를 확인하는 것이다.
• ip addr add 명령은 인터페이스에 IP 주소를 설정하는 데 사용된다. 이러한 명령을 사용하여 변경한 내용은 다시 시작할 때까지만 유효하다. 이러한 변경 사항을 유지하려면 /etc/network/interfaces 파일에서 설정해야 한다.
• ip route 명령은 라우팅 테이블을 보는 데 사용됩니다.
• ip route add 명령은 라우팅 테이블에 항목을 추가하는 데 사용됩니다.
• 마지막으로, 라우터로 구성된 호스트로 작업하는 경우 호스트에서 IP forward이 활성화되어 있는지 확인하는 명령을 기억해야 한다.

---

선수 지식 - DNS

• 두 대의 컴퓨터 A와 B가 모두 동일한 네트워크에 속해 있으며 IP 주소 192.168.1.10과 1.11이 할당되었습니다. 다른 컴퓨터의 IP 주소를 사용하여 한 컴퓨터에서 다른 컴퓨터로 ping을 보낼 수 있습니다.
• 시스템 B에 데이터베이스 서비스가 있다는 것을 알고 있습니다. 따라서 시스템 B의 IP 주소를 기억할 필요 없이 이름을 db로 지정하기로 결정했습니다. 앞으로는 IP 주소 대신 db라는 이름을 사용하여 시스템 B를 ping하려고 합니다.
• 지금 db에 ping을 시도하면 호스트 A가 db라는 호스트를 인식하지 못하는 것을 볼 수 있습니다. 그럼 어떻게 고치나요? 기본적으로 IP 주소 192.168.1.11의 시스템 B에 이름이 db라는 것을 시스템 A에 알리고 싶습니다. 내가 db라고 말할 때 IP 192.168.1.11을 의미한다고 시스템 A에 말하고 싶습니다.

• 시스템 A의 /etc/hosts 파일에 항목을 추가하여 이를 수행할 수 있습니다. 호스트가 시스템 B에서 볼 수 있도록 할 IP 주소와 이름을 언급하십시오. 우리는 시스템 A에 192.168.1.11의 IP가 db라는 호스트임을 알렸습니다. 이제 DB에 대한 핑이 올바른 IP로 전송되어 성공합니다.
• 이제 여기서 주목해야 할 중요한 점이 있습니다. 우리는 시스템 A에 192.168.1.11의 IP가 db라는 호스트임을 알렸습니다. 호스트 A는 이를 당연하게 여깁니다. /etc/hosts 파일에 넣은 내용은 tr의 소스입니다.

• 그래서 우리는 같은 시스템을 가리키는 두 개의 이름을 가지고 있습니다. 하나는 db이고 다른 하나는 Google입니다. 그리고 우리는 두 개의 이름을 사용하여 시스템 B에 도달할 수 있습니다.
• /etc/hosts 파일에서 원하는 만큼 많은 서버의 이름을 가질 수 있습니다. ping 명령이나 SSH 명령을 통해 또는 이 시스템 내의 응용 프로그램이나 도구를 통해 호스트 A에서 이름으로 다른 호스트를 참조할 때마다 해당 호스트의 /etc/hosts 파일을 검색하여 해당 호스트의 IP 주소를 찾습니다.

• 이런 식으로 호스트 이름을 IP 주소로 변환하는 것을 name resolution이라고 합니다. 소수의 시스템으로 구성된 소규모 네트워크 내에서 /etc/hosts 파일의 항목을 쉽게 처리할 수 있습니다. 각 시스템에서 나는 환경에 있는 다른 시스템이 무엇인지 지정하고, 과거에 그렇게 했습니다. 환경이 확장되고 이 파일들이 너무 많은 항목으로 채워지고 관리가 너무 어려워지기 전까지는 말입니다.

• 서버의 IP 중 하나가 변경된 경우 모든 호스트의 항목을 수정해야 하며, 여기서 모든 항목을 중앙에서 관리할 단일 서버로 이동하기로 결정했습니다. 우리는 이를 DNS 서버라고 부릅니다. 그런 다음 호스트 이름을 자체 /etc/hosts 파일 대신 IP 주소로 확인해야 하는 경우 모든 호스트가 해당 서버를 찾도록 지시합니다.
• 그럼 어떻게 해야 할까요? 호스트가 DNS 서버를 가리키도록 하려면 어떻게 해야 합니까? 우리 DNS 서버의 IP는 192.168.1.100입니다. 모든 호스트에는 /etc/resolv.conf에 DNS 확인 구성 파일이 있습니다. DNS 서버의 주소를 지정하는 항목을 추가합니다. 우리는 네임서버라고 말하고 192.168.1.100을 가리키면 그게 되어야 합니다.
• 모든 호스트에 이것이 구성되면 호스트가 알지 못하는 호스트 이름을 발견할 때마다 DNS 서버에서 이를 조회합니다. 호스트 중 하나의 IP가 변경되는 경우 DNS 서버를 업데이트하면 모든 호스트가 앞으로 새 IP 주소를 확인해야 합니다.
• 더 이상 호스트의 /etc/hosts 파일에 항목이 필요하지 않지만 이것이 호스트 파일에 항목을 가질 수 없다는 의미는 아닙니다. 예를 들어, 자신의 필요에 따라 테스트 서버를 프로비저닝한다고 말할 수 있습니다. 다른 사람이 서버 이름으로 서버를 확인할 필요는 없을 것이라고 생각하므로 DNS 서버에 추가되지 않을 수도 있습니다. 이 경우 호스트 /etc/hosts 파일에 항목을 추가하여 이 서버를 확인할 수 있습니다. 이제 서버를 확인할 수 있습니다. 그러나 다른 어떤 시스템도 그렇게 할 수 없습니다.
• 따라서 시스템은 원격 DNS 서버뿐만 아니라 로컬로 /etc/hosts 파일의 호스트 이름-IP 매핑을 사용할 수 있습니다. /etc/hosts 파일에 하나, DNS에 하나, 두 위치 모두에 항목이 있으면 어떻게 됩니까? 내 로컬 파일에 192.168.1.115로 설정된 항목이 있고 누군가 서버의 192.168.1.116에 동일한 호스트에 대한 항목을 추가했습니다. 이 경우 호스트는 먼저 로컬 /etc/hosts 파일을 살펴본 다음 이름 서버를 찾습니다. 따라서 로컬 /etc/hosts 파일에서 항목을 찾으면 해당 항목을 사용합니다. 그렇지 않은 경우 DNS 서버에서 해당 호스트를 찾습니다.

• 하지만 그 순서는 바뀔 수 있습니다. 순서는 /etc/nsswitch.conf 파일의 항목으로 정의됩니다. 보시다시피 호스트 항목이 있는 줄의 순서는 파일이 먼저이고 그 다음이 DNS입니다. 파일은 /etc/hosts 파일을 참조하고 dns는 DNS 서버를 참조합니다. 따라서 모든 호스트 이름에 대해 호스트는 먼저 /etc/hosts 파일을 조사하고, 거기에서 파일을 찾을 수 없으면 DNS 서버를 조사합니다. 이 순서는 파일에서 이 항목을 편집하여 수정할 수 있습니다. 이 순서에 따라 호스트는 테스트 서버를 192.168.1.115로 확인합니다.

• 지금까지 우리는 web, db, nfs 등과 같은 이름을 가진 시스템에 접근하려고 시도했습니다. 그러나 우리는 http://www.facebook.com에서 Facebook에 ping을 시도했습니다. 이 이름은 무엇입니까? 끝에 "www"와 ".com"이 붙으면 도메인 이름이라고 합니다. 이는 IP가 호스트에 대해 했던 것과 유사하게 공용 인터넷에서 기억할 수 있는 이름으로 변환되는 방식입니다.
• 점으로 구분된 이 형식의 이유는 유사한 항목을 함께 그룹화하기 위한 것입니다. 도메인 이름의 마지막 부분인 ".coms", ".nets", ".edu", ".org" 등은 최상위 도메인입니다. 이는 웹사이트의 의도를 나타냅니다(상업적 또는 일반 목적의 경우 .com, 네트워크의 경우 .net, 교육 기관의 경우 .edu, 비영리 조직의 경우 .org).
• 특히 한 가지를 살펴보겠습니다. Google의 경우 "." 모든 것이 시작되는 뿌리이다. ".com"은 최상위 도메인이고 "google"은 Google에 할당된 도메인 이름이며 "www"는 하위 도메인입니다. 하위 도메인은 Google에서 항목을 추가로 그룹화하는 데 도움이 됩니다. 예를 들어, Google의 지도 서비스는 "maps"가 하위 도메인인maps.google.com에서 사용할 수 있습니다. 마찬가지로 Google의 저장 서비스는drive.google.com에서, 모바일 앱은 apps.google.com에서, 이메일 서비스는 mail.google.com에서 사용할 수 있습니다. 필요에 따라 이들 각각을 원하는 만큼의 하위 도메인으로 나눌 수 있습니다.
• 그러면 트리 구조가 형성되는 것을 볼 수 있습니다. 조직 내에서 apps.google.com과 같은 도메인 이름에 접근하려고 하면 요청이 먼저 조직의 내부 DNS 서버에 도달합니다. "apps" 또는 "google"이 누구인지 모르는 경우 요청을 인터넷으로 전달합니다. 인터넷에서 apps.google.com을 제공하는 서버의 IP 주소는 여러 DNS 서버의 도움으로 확인할 수 있습니다. 루트 DNS 서버는 귀하의 요청을 살펴보고 ".coms"를 제공하는 DNS 서버를 알려줍니다. ".com" DNS 서버는 귀하의 요청을 살펴보고 귀하를 Google로 전달합니다. Google의 DNS 서버는 앱 애플리케이션을 제공하는 서버의 IP를 제공합니다. 향후 결과의 속도를 높이기 위해 조직의 DNS 서버는 일반적으로 몇 초에서 몇 분 동안 일정 기간 동안 이 IP를 캐시하도록 선택할 수 있습니다. 이렇게 하면 매번 전체 과정을 다시 거칠 필요가 없습니다.

 

• 이러한 구성은 모두 조직의 내부 DNS 서버에 설정됩니다. 우리는 호스트에 사용될 DNS 서버를 구성하는 /etc/resolv.conf 파일의 또 다른 항목을 이해하기 위해 이에 대해 논의했습니다. 이를 통해 "web"과 같은 이름만으로 조직의 서버를 확인할 수 있었습니다. 이제 "web.mycompany.com" 또는 "db.mycompany.com" 등과 같은 더 많은 표준 도메인 이름을 도입했습니다.
• "web.mycompany.com"으로 확인되도록 "web"을 구성하려면 호스트의 /etc/resolv.conf 파일에 "search"라는 항목을 만들고 추가할 도메인 이름을 지정합니다. 다음에 "web"을 ping하려고 하면 실제로 "web.mycompany.com"을 시도하는 것을 볼 수 있습니다. 호스트는 쿼리에 도메인을 지정한 경우 검색 도메인을 제외할 만큼 지능적입니다.
• 이와 같은 추가 검색 도메인을 제공할 수도 있습니다. 즉, "웹"이라고 하면 "web.mycompany.com" 또는 "web.prod.mycompany.com"을 의미합니다. 귀하의 호스트는 귀하가 호스트 이름을 찾을 때 이러한 도메인 이름을 모두 검색하려고 시도합니다.

• 이제 ping이 항상 DNS 확인을 테스트하는 데 적합한 도구는 아닐 수도 있습니다. nslookup과 같은 몇 가지 다른 도구도 있습니다. nslookup을 사용하여 DNS 서버에서 호스트 이름을 쿼리할 수 있습니다. 그러나 nslookup은 로컬 /etc/hosts 파일의 항목을 고려하지 않는다는 점을 기억하십시오. 웹 응용 프로그램의 로컬 /etc/hosts 파일에 항목을 추가하고 nslookup을 시도하면 해당 항목을 찾을 수 없습니다. 웹 애플리케이션에 대한 항목이 DNS 서버에 있어야 합니다. nslookup은 DNS 서버에만 쿼리합니다. DNS 이름 확인을 테스트하는 또 다른 유용한 도구인 dig도 마찬가지입니다. 서버에 저장된 것과 유사한 형식으로 자세한 내용을 반환합니다.

---

선수 지식 - CoreDNS

• 이전 강의에서는 DNS 서버가 필요한 이유와 호스트 이름과 Ips가 많은 대규모 환경에서 이름 확인을 관리하는 데 도움이 되는 방법, 호스트가 DNS 서버를 가리키도록 호스트를 구성하는 방법을 살펴보았습니다. 이 글에서는 호스트를 DNS 서버로 구성하는 방법을 살펴보겠습니다.
• DNS 서버로 전용 서버와 서버에 항목으로 구성할 Ips 세트가 제공됩니다. 시중에는 많은 DNS 서버 솔루션이 있지만, 이 강의에서는 특정 솔루션인 CoreDNS에 초점을 맞출 것입니다.
• 그렇다면 CoreDNS는 어떻게 얻을 수 있을까요? CoreDNS 바이너리는 Github 릴리스 페이지에서 다운로드하거나 도커 이미지로 다운로드할 수 있습니다. 전통적인 방법을 사용하겠습니다. curl 또는 wget을 사용하여 바이너리를 다운로드합니다. 그리고 압축을 풉니다. CoreDNS 실행 파일을 얻게 됩니다.

• 실행 파일을 실행하여 DNS 서버를 시작합니다. 기본적으로 DNS 서버의 기본 포트인 포트 53에서 수신 대기합니다.
• 이제 IP와 호스트 이름 매핑을 지정하지 않았습니다. 이를 위해서는 몇 가지 구성을 제공해야 합니다. 이를 수행하는 방법에는 여러 가지가 있습니다. 한 가지 방법을 살펴보겠습니다. 먼저 모든 항목을 DNS 서버 /etc/hosts 파일에 넣습니다.
• 그런 다음 해당 파일을 사용하도록 CoreDNS를 구성합니다. CoreDNS는 Corefile이라는 파일에서 구성을 로드합니다. 다음은 CoreDNS가 /etc/hosts 파일에서 호스트 이름 매핑에 대한 IP를 가져오도록 지시하는 간단한 구성입니다. 이제 DNS 서버가 실행되면 서버의 /etc/hosts 파일에서 Ips와 이름을 선택합니다.

• CoreDNS는 플러그인을 통해 DNS 항목을 구성하는 다른 방법도 지원한다. 이후 섹션에서 쿠버네티스에서 사용하는 플러그인에 대해 살펴보겠습니다.

---

선수 지식 - Network Namespaces

네트워크 네임스페이스는 도커와 같은 컨테이너에서 네트워크 격리를 구현하는 데 사용됩니다. 간단한 호스트로 시작하겠습니다. 이미 알고 있듯이 컨테이너는 네임스페이스를 사용하여 기본 호스트에서 분리됩니다. 그렇다면 네임스페이스란 무엇인가요? 만약 호스트가 여러분의 집이라면 네임스페이스는 각각의 자녀에게 할당된 집 안의 방입니다. 방은 각 자녀에게 개인 정보를 제공하는 데 도움이 됩니다. 각 자녀는 자신의 방 안에서만 볼 수 있으며 자신의 방 밖에서 무슨 일이 일어나는지 볼 수 없습니다. 그들에게 있어서는 그들이 집에 혼자 살고 있는 것처럼 보입니다. 그러나 부모로서 여러분은 집 안의 모든 방과 집의 다른 부분에 대한 가시성이 있습니다. 원한다면 집 안의 두 방 사이에 연결성을 확립할 수 있습니다. 컨테이너를 만들 때 격리되어 다른 프로세스나 다른 컨테이너를 볼 수 없도록 하려면 해당 컨테이너를 위해 호스트에 특별한 방을 만들어야 합니다. 컨테이너가 보는 한, 컨테이너에서 실행되는 프로세스만 보이며 자신만의 호스트에 있다고 생각합니다. 그러나 기본 호스트에서는 컨테이너 안에서 실행되는 프로세스를 포함한 모든 프로세스를 볼 수 있습니다. 컨테이너 안에서 프로세스를 나열할 때는 프로세스 ID가 1인 단일 프로세스가 표시됩니다. 기본 호스트에서 루트 사용자로 동일한 프로세스를 나열하면 컨테이너 안과 밖에서 다른 프로세스 ID로 실행되는 동일한 프로세스가 표시됩니다. 이것이 네임스페이스가 작동하는 방식입니다. 네트워킹에 관련된 경우 기본 호스트에는 지역 네트워크에 연결되는 자체 인터페이스가 있습니다. 호스트에는 자체 라우팅 및 ARP 테이블이 있으며 네트워크의 나머지에 대한 정보가 있습니다. 우리는 이러한 세부 정보를 컨테이너에서 차단하고 싶습니다. 컨테이너가 생성될 때 컨테이너에 대한 네트워크 네임스페이스를 만듭니다. 이렇게 하면 컨테이너가 호스트에서 어떤 네트워크 관련 정보도 볼 수 없습니다. 해당 네임스페이스 내에서 컨테이너는 자체 가상 인터페이스, 라우팅 및 ARP 테이블을 가질 수 있습니다. 컨테이너에는 자체 인터페이스가 있습니다. 리눅스 호스트에서 새로운 네트워크 네임스페이스를 만들려면 ip netns add 명령을 실행합니다. 이 경우에는 두 개의 네트워크 네임스페이스를 생성합니다. 네트워크 네임스페이스를 나열하려면 ip netns 명령을 실행합니다. 호스트의 인터페이스를 나열하려면 ip link 명령을 실행합니다. 내 호스트에는 루프백 인터페이스와 80 인터페이스가 있음을 알 수 있습니다. 그러면 만든 네트워크 네임스페이스 내에서는 어떻게 볼까요? 빨간색이나 파란색 네임스페이스 내에서 동일한 명령을 실행하는 방법은 무엇일까요? 명령 앞에 ip netns exec 명령을 추가한 다음 네임스페이스 이름(red)을 입력하면 됩니다. 이제 ip link 명령이 빨간색 네임스페이스 내에서 실행됩니다. 다른 방법은 원래의 ip link 명령에 -n 옵션을 추가하는 것입니다.

이 두 가지 방법은 동일합니다. 두 번째 방법은 더 간단하지만 이 방법은 ip 명령을 네임스페이스 내에서 실행할 의도가 있을 때만 작동합니다. 볼 수 있는 것처럼 루프백 인터페이스만 나열되며 호스트에서는 80 인터페이스를 볼 수 없습니다. 따라서 네임스페이스를 사용하면 컨테이너가 호스트 인터페이스를 볼 수 없게 성공적으로 방지했습니다. ARP 테이블도 마찬가지입니다. 호스트에서 ARP 명령을 실행하면 항목 목록이 표시되지만 컨테이너 내에서 실행하면 항목이 표시되지 않습니다. 라우팅 테이블도 마찬가지입니다. 현재 이 네트워크 네임스페이스에는 네트워크 연결이 없으며 자체 인터페이스가 없으며 기본 호스트 네트워크를 볼 수 없습니다.

이제 네임스페이스 간에 연결을 설정해 보겠습니다. 두 물리적인 기계를 각각 인터넷 인터페이스에 케이블로 연결하는 것처럼 두 네임스페이스를 가상 이더넷 페어 또는 가상 케이블을 사용하여 연결할 수 있습니다. 이것은 종종 파이프로 참조되지만 가상 이더넷 페어 또는 가상 케이블이라고 부르는 것이 좋습니다. 케이블을 만들려면 ip link set 명령을 사용하고 종류는 veth로 설정하고 두 끝을 veth red 및 veth blue로 지정합니다. 다음 단계는 각 인터페이스를 해당 네임스페이스에 연결하는 것입니다. 이를 위해 ip link set veth red netns red 명령을 사용하십시오. 마찬가지로 파란색 인터페이스를 파란색 네임스페이스에 연결하십시오. 그런 다음 각 네임스페이스 내에서 ip 주소를 할당하려면 평소처럼 ip addr 명령을 사용합니다. 우리는 빨간색 네임스페이스에 IP 192.168.15.1을 할당하고, 파란색 네임스페이스에 IP 192.168.15.2을 할당합니다. 그런 다음 각 장치 내에서 ip link set up 명령을 사용하여 인터페이스를 사용 가능하게 합니다. 링크는 활성화되었으며 네임스페이스는 이제 서로에게 도달할 수 있습니다. 빨간색 네임스페이스에서 블루의 IP에 도달하려면 red 네임스페이스에서 ping을 시도해 보세요. 빨간색 네임스페이스의 ARP 테이블을 보면 192.168.15.2의 블루 이웃이 식별되었습니다. 마찬가지로 블루 네임스페이스의 ARP 테이블을 나열하면 빨간색 이웃이 식별됩니다. 이를 호스트의 ARP 테이블과 비교하면 호스트 ARP 테이블이 만들어진 새로운 네임스페이스와 해당 네임스페이스에 생성된 인터페이스에 대해 알지 못한다는 것을 알 수 있습니다.

이것은 두 개의 네임스페이스만 있는 경우에 작동하지만 여러 개의 네임스페이스가 있는 경우에는 어떻게 해야 할까요? 모든 네임스페이스가 서로 통신할 수 있도록하려면 어떻게 해야 할까요? 물리적인 세계와 마찬가지로 호스트 내에서 가상 네트워크를 생성합니다. 네트워크를 만들려면 스위치가 필요하므로 가상 네트워크를 만들려면 가상 스위치가 필요합니다. 그래서 우리는 호스트 내에서 가상 스위치를 만들고 네임스페이스를 연결합니다. 그러나 호스트 내에서 가상 스위치를 어떻게 만들 수 있을까요? 리눅스 브리지라는 네이티브 솔루션 및 오픈 V 스위치와 같은 여러 솔루션이 있습니다. 이 예에서는 리눅스 브리지 옵션을 사용합니다. 내부 브리지 네트워크를 만들려면 ip link add 명령을 사용하고 종류를 브리지로 설정한 다음 Vnet0으로 이름을 지정합니다.


우리 호스트 입장에서는 그저 다른 인터페이스일 뿐입니다. 80 인터페이스와 마찬가지로 ip link 명령의 출력에 다른 인터페이스들과 함께 나타납니다. 현재 꺼져 있으므로 켜야 합니다. 켜려면 ip link set 명령을 사용하여 인터페이스를 활성화하십시오. 이 인터페이스는 네임스페이스에 대해 연결할 수 있는 스위치처럼 작동합니다. 따라서 호스트에는 인터페이스이면서 네임스페이스에 대한 스위치인 것처럼 생각하십시오. 다음 단계는 이 새로운 가상 네트워크 스위치에 네임스페이스를 연결하는 것입니다. 이전에는 veth 케이블 또는 eth 페어를 veth red 인터페이스와 다른쪽에 blue 인터페이스로 만들었습니다. 왜냐하면 두 네임스페이스를 직접 연결하려 했기 때문입니다. 이제 모든 네임스페이스를 브리지 네트워크에 연결하려고 합니다. 따라서 이 목적을 위해 더 이상이 케이블은 의미가 없습니다. 이 케이블을 제거하려면 ip link delete 명령을 사용하십시오. 한쪽 끝을 삭제하면 다른쪽 끝도 쌍이기 때문에 자동으로 삭제됩니다. 이제 브리지에 네임스페이스를 연결하는 새로운 케이블을 만들어 봅시다. ip link add 명령을 실행하고 veth red와 같은 끝으로 페어를 만들지만 이번에는 다른쪽은 V8 red VR로 이름을 지정합니다. 이 네이밍 규칙은 빨간색 네임스페이스와 연결된 인터페이스를 쉽게 식별하는 데 도움이 될 것입니다. 마찬가지로 파란색 네임스페이스를 브리지 네트워크에 연결하기 위한 케이블을 만듭니다. 이제 준비가 된 것이니 이들을 네임스페이스에 연결합시다. 인터페이스의 한쪽 끝을 빨간색 네임스페이스에 연결하려면 ip link set veth red netns red 명령을 실행하십시오. 다른쪽 끝을 브리지 네트워크에 연결하려면 v8 red VR 끝에 ip link set 명령을 실행하고 마스터를 VNET zero 네트워크로 지정하십시오. 블루 네임스페이스와 브리지 네트워크에 블루 케이블을 연결하는 것과 같은 절차를 따릅니다. 이제 이 링크에 IP 주소를 할당하고 활성화하려면 같은 IP 주소를 사용합니다. 192.168.15.1 및 192.168.15.2. 마지막으로 디바이스를 켜십시오. 컨테이너는 이제 네트워크를 통해 서로 통신할 수 있습니다. 나머지 두 네임스페이스를 동일한 네트워크에 연결하려면 동일한 절차를 따릅니다. 우리는 이제 모든 네임스페이스가 내부 브리지 네트워크에 연결되어 서로 통신할 수 있게 되었습니다. 모든 IP 주소를 가지고 있습니다. 192.168.15.1, 2, 3 및 4. 그리고 기억하세요, 호스트에는 192.168.1.2의 IP를 할당했습니다. 이러한 네임스페이스의 인터페이스 중 하나에 도달하려고 시도하면 어떻게 될까요? 작동하지 않을 것입니다. 제 호스트는 한 네트워크에 있고 네임스페이스는 다른 네트워크에 있습니다. 그렇지만 내 호스트와 이 네임스페이스 간에 연결성을 확립하려면 어떻게 해야 할까요? 가상 스위치가 실제로 호스트의 네트워크 인터페이스이기 때문에 호스트에는 192.168.15 네트워크에 대한 인터페이스가 이미 있습니다. 이것이 다른 인터페이스일 뿐이므로 그냥 IP 주소를 할당하여 네임스페이스를 통해 도달할 수 있습니다.

ip addr 명령을 실행하여 이 인터페이스에 IP 주소 192.168.15.5를 할당합니다. 이제 로컬 호스트에서 빨간색 네임스페이스에 핑을 보낼 수 있습니다. 이제 이 전체 네트워크는 여전히 호스트 내에서 비공개이며 제한되어 있습니다. 네임스페이스 내부에서는 외부 세계에 도달할 수 없으며 외부에서도 네임스페이스 내에 호스팅된 서비스나 응용 프로그램에 도달할 수 없습니다. 외부 세계로 나가는 유일한 문은 호스트의 이더넷 포트입니다. 그렇다면 이 브리지를 이더넷 포트를 통해 외부 네트워크에 도달하도록 구성하는 방법은 무엇일까요? 예를 들어 라인 네트워크에 연결된 또 다른 호스트가 있고 해당 호스트의 주소가 192.168.1.3이라고 가정해 보겠습니다. 내 네임스페이스에서 이 호스트에 도달하려면 어떻게 해야 할까요? 내 네임스페이스에서 이 호스트를 핑하려고 하면 어떤 일이 발생할까요? 파란색 네임스페이스는 나의 현재 네트워크인 192.168.15의 네트워크와 다른 네트워크인 192.168.1을 찾고 있습니다. 따라서 해당 네트워크를 찾는 방법을 확인하기 위해 라우팅 테이블을 살펴봅니다. 라우팅 테이블에는 다른 네트워크에 대한 정보가 없습니다. 그러므로 네트워크에 도달할 수 없다는 메시지가 반환됩니다. 따라서 외부 세계와의 문을 제공하려면 라우팅 테이블에 항목을 추가해야 합니다. 그렇다면 게이트웨이를 어떻게 찾을 수 있을까요? 이더넷 포트에 연결된 192.168.15 네트워크에서 로컬로써의 인터페이스를 가진 시스템이 게이트웨이입니다. 여기에 논리적인 관점을 제시합니다. 이 네임스페이스가 있는 로컬 호스트입니다. 따라서 네임스페이스에 핑을 보낼 수 있습니다. 로컬 호스트는 개인 네트워크에 연결하기 위한 인터페이스가 있습니다. 이제 블루 네임스페이스에게 192.168.1 네트워크의 모든 트래픽을 게이트웨이인 192.168.15.5를 통해 라우팅할 수 있는 행 열을 추가할 수 있습니다. 그러나 기억하세요. 호스트에는 192.168.15.5의 브리지 네트워크와 192.168.1.2의 외부 네트워크에 두 개의 IP 주소가 있습니다. 경로에 어느 것을 사용할 수 있을까요? 블루 네임스페이스는 192.168.15.5의 로컬 네트워크에서만 게이트웨이에 도달할 수 있습니다. 라우팅에 추가할 때 기본 게이트웨이는 네임스페이스에서 접근 가능해야 합니다. 이제 핑을 시도하면 더 이상 네트워크에 도달할 수 없다는 메시지를 받지 않지만 핑에 대한 응답도 여전히 없습니다. 어떤 문제가 있을까요? 우리는 이전 강의 중 하나에서 이와 유사한 상황에 대해 이야기했습니다. 우리의 홈 네트워크에서 라우터를 통해 외부 인터넷에 도달하려고 시도한 경우입니다. 우리의 홈 네트워크에는 대상 네트워크에서 모르는 내부 개인 IP 주소가 있으므로 다시 도달할 수 없습니다. 따라서 여기에서는 호스트로 동작하는 게이트웨이에 NAT 기능을 추가해야 합니다. 그래야만 게이트웨이가 패킷을 자체 주소로 외부 네트워크로 전송할 수 있습니다. 그렇게 하려면 IP 테이블을 사용해야 합니다. 포스트 라우팅 체인에서 NAT IP 테이블에 새로운 룰을 추가하여 소스 네트워크에서 오는 모든 패킷의 출발지 주소를 192.168.15.0으로 대체하면 됩니다. 이렇게 하면 네임스페이스 내부에서 패킷을 받는 외부 네트워크의 수신자는 이 패킷이 네임스페이스 내부에서 오는 것이 아니라 호스트에서 오는 것으로 생각할 것입니다.

이제 핑을 시도하면 외부 세계에 도달할 수 있음을 확인할 수 있습니다. 마지막으로 로컬 에어리어 네트워크(LAN)이 인터넷에 연결되어 있다고 가정해 봅시다. 네임스페이스가 인터넷에 도달하길 원합니다. 따라서 블루 네임스페이스에서 인터넷의 서버인 8.8.8.8을 핑해 보려고 합니다. 우리는 네트워크가 도달할 수 없다는 비슷한 메시지를 받습니다. 이제 왜 그런지 알고 있습니다. 라우팅 테이블을 살펴보면 192.168.1 네트워크로의 경로는 있지만 다른 것은 없습니다. 이 네임스페이스가 호스트가 도달할 수 있는 모든 네트워크에 도달할 수 있으므로 간단히 말해서, 모든 외부 네트워크에 도달하려면 호스트에게 이야기하라고 할 수 있습니다. 따라서 우리는 호스트를 지정하여 기본 게이트웨이를 추가합니다. 이제 이 네임스페이스에서 외부 세계에 도달할 수 있어야 합니다. 이제 외부 세계에서 네임스페이스 내부로의 연결성은 어떻게 될까요? 예를 들어 블루 네임스페이스에 웹 응용 프로그램이 Port 80에서 호스팅되어 있다고 가정해 봅시다. 현재 네임스페이스는 내부 비공개 네트워크에 있으며 외부 세계에서는 이에 대해 알지 못합니다. 이에 접근할 수 있는 유일한 방법은 호스트 자체에서입니다. 다른 네트워크의 다른 호스트에서 네임스페이스의 사설 IP를 핑하려고 하면 당연히 도달할 수 없습니다. 이 통신을 가능하게 하려면 두 가지 옵션이 있습니다. 이전 강의에서 본 두 가지 옵션입니다. 첫 번째는 두 번째 호스트에게 사설 네트워크의 식별 정보를 공개하는 것입니다. 기본적으로 192.168.1.2 호스트를 통해 192.168.15 네트워크에 도달할 수 있다고 두 번째 호스트에게 알려주는 IP 라우트 항목을 추가하는 것입니다. 그러나 우리는 그렇게 하고 싶지 않습니다. 또 다른 옵션은 IP 테이블을 사용하여 포트 포워딩 규칙을 추가하여 로컬 호스트의 포트 80으로 오는 모든 트래픽을 블루 네임스페이스에 할당된 IP의 포트 80으로 전달하는 것입니다. 이제 이 비디오는 여기까지입니다.

(중요하지 않아서 나중에 정리)

---

선수 지식 - Docker Networking

• 쿠버네티스의 네트워크를 살펴보기 전에 기본적인 Docker 네트워크 옵션부터 살펴보자
• 먼저 단일 Docker 호스트, Docker가 설치된 서버를 생각해보자.
• 호스트에는 eht0 인터넷 인터페이스가 있으며, IP 주소 192.168.1.10으로 로컬 네트워크에 연결되어 있다.
• 컨테이너를 실행할 때 여러 네트워킹 옵션을 선택할 수 있는데, 먼저 none 네트워크를 살펴보자

• none 네트워크를 사용하면 Docker 컨테이너는 어떤 네트워크에도 연결되지 않는다. 컨테이너는 외부에 도달할 수 없으며, 외부에서도 컨테이너에 도달할 수 없다.
• 여러 컨테이너로 구성되어 있다고 하더라도 외부나 서로 통신할수 없게끔 생성이 된다. 
• 다음은 호스트 네트워크이다.

• 호스트 네트워크는 컨테이너가 호스트 네트워크에 연결된다.
• 호스트와 컨테이너 간에 네트워크 격리가 없다. 컨테이너에서 포트 80에서 수신 대기 중인 웹 애플리케이션을 배포하면 별도의 포트 매핑을 하지 않고도 호스트의 포트 80에서 해당 웹 애플리케이션에 액세스할 수 있다.
• 만약 동일한 포트에서 수신 대기 중인 동일한 컨테이너를 실행하려고 하면 호스트 네트워크를 공유하기 때문에 동시에 두 프로세스가 동일한 포트에서 수신 대기할 수 없다.
• 다음은 브릿지 네트워크이다.

• 이 경우 Docker 호스트와 컨테이너가 연결된 내부 프라이빗 네트워크가 생성된다. 이 네트워크는 기본적으로 주소가 172.17.0.0이며, 이 네트워크에 연결되는 각 장치는 이 네트워크의 자체 내부 프라이빗 네트워크 주소를 받는다.

• Docker가 호스트에 설치되면 기본적으로 Bridge라는 내부 프라이빗 네트워크를 생성한다.
• docker network ls 명령어를 사용해서 확인할 수 있다.
• 이제 Docker는 네트워크를 Bridge라고 부르지만 호스트에서는 네트워크를 Docker0라는 이름으로 생성한다.
• 이는 ip link로 확인 가능하다.
• 기억해야할 것은 브릿지 네트워크는 호스트에 대한 인터페이스이지만 호스트 내에서는 네임스페이스나 컨테이너에 대한 스위치이다.
• 따라서 호스트의 인터페이스 Docker0는 172.17.0.1이 할당된다.

• ip addr 을 이용해서 확인하면 호스트의 인터페이스 docker0에 할당 된 ip를 확인 가능하다.
• ip netns를 통해 네임스페이스를 확인할수 있다.
• 각 컨테이너에 대한 네임스페이스는 docker inspect 명령어를 이용해서 확인 가능하다.
• Docker는 컨테이너 또는 해당 네트워크 네임스페이스를 브릿지 네트워크에 어떻게 연결하는가?
• 컨테이너와 네트워크 네임스페이스는 사실 동일한 의미이다.

• 만약 컨테이너가 추가되게 되면 이와 같은 방식으로 가상의 link로 컨테이너 네임스페이스와 브릿지에 있는 가상 인터페이스를 통해서 통신하게된다.

• 컨테이너와 컨테이너를 구분 짓는 것은 네임스페이스가 하는 것이고, ip link 명령어를 이용해서 컨테이너에 있는 인터페이스와 브릿지의 veth와 연결시킨 것 뿐이다.
• 이는 ip -n <네임스페이스> link 명령어를 이용해서 수행한다.

• 또한 컨테이너를 실행할 때 docekr run -p 8080:80 과 같은 옵션을 이용해서 외부 사용자가 컨테이너에 호스팅된 애플리케이션에 8080으로 액세스하고 80의 애플리케이션을 사용하게끔 할 수도 있다.
• 또한 iptables의 NAT 테이블 규칙을 추가해 prerouting 체인에 규칙을 추가하고 대상에 컨테이너의 ip를 포함해 대상을 설정할 수 있다.
• 이를 통해서 한 포트로 들어오는 트래픽을 다른 포트로 전달할 수도 있다.

---

선수 지식 - CNI

• Docker 뿐만 아니라 다른 컨테이너 솔루션도 네트워킹 관련된 방식이 있을 것이다.
• 이러한 솔루션들은 각각 다른 특성을 가지고 있으면 여러번 같은 기술을 다른 코드로 개발되기 때문에 미들웨어나 그런 차이를 없애는 매개체가 필요했다.
• 그래서 다양한 솔루션에서 아이디어를 가져와 네트워킹 부분을 모두 하나의 프로그램 또는 코드로 구성했다.

• 이를 처음에는 브릿지라고 정의하고 컨테이너를 브릿지 네트워크에 연결하는 데 필요한 모든 작업을 수행하는 프로그램 또는 스크립트를 만들었다.
• 브릿지를 이용하면 각기 다른 컨테이너 런타임 환경이어도 네트워크 네임스페이스를 구성하고자 할때 브릿지를 이용해서 처리하게 되면 환경이 다르더라도 문제가 없다.
• 그런데 우리가 새로운 네트워킹 유형을 위해 브릿지와 같은 프로그램을 만들고 싶다면 어떨까?
• 그래서 프로그램이 어떻게 구성될 지, 컨테이너 런타임이 어덯게 호출할 지 정의하는 표준이 필요하므로 모든 사람이 단일 표준 세트를 따르고 모든 런타임 간에 작동하는 솔루션을 개발할 지를 정해야했다.
• 이것이 컨테이너 네트워크 인터페이스(CNI)가 필요한 상황이었다.

• CNI는 컨테이너 런타임 환경에서 네트워킹 문제를 해결하기 위해 프로그램이 개발되어야 하는 방법을 정의하는 표준 세트이다. 이 프로그램들은 플러그인이라고 불린다.
• 이 경우에 Bridge는 CNI의 플러그인이다.
• CNI는 컨테이너 런타임 및 플러그인에 대한 위와 같은 일련의 책임을 정의한다.
• 또한 CNI는 Bridge, VLAN, IPVLAN, MACVLAN, WINDOWS와 HOSTLOCAL 및 DHCP와 같은 IPAM 플러그인과 같은 지원되는 플러그인 세트가 포함되어 있다.

• 컨테이너 런타임과 플러그인이 이러한 표준을 준수한다면 모두가 조화롭게 공존해야한다.
• 주의해야할 점은 Docker는 CNM이라는 특유의 표준을 가지고 있어 CNI를 구현하지 않는다.