Kubernetes 네트워킹: 네트워크 모델을 이해하기 위한 완전한 가이드
게시 됨: 2020-02-18컨테이너 관리는 네트워킹의 중요한 측면입니다. 오늘날의 변화하는 트래픽 요구 사항으로 인해 Kubernetes의 중요성이 10배 증가했습니다. 네트워킹에 대해 배우고 싶다면 먼저 Kubernetes에 익숙해져야 합니다. Kubernetes에 대해 배우면 컨테이너 관리를 효과적으로 처리하는 데 도움이 됩니다. Kubernetes는 또한 2020년 시장에서 최고의 DevOps 도구 중 하나입니다.
그러나 이 자세한 가이드에서 동일한 내용에 대해 논의할 것이기 때문에 걱정하지 마십시오. Kubernetes는 컨테이너 관리 도구이며 이 기사에서는 사용 이유, 네트워크 구성 요소 및 트래픽 라우팅 방법에 대해 알아봅니다.
세계 최고의 대학에서 온라인으로 소프트웨어 엔지니어링 을 배우십시오 . 이그 제 큐 티브 PG 프로그램, 고급 인증 프로그램 또는 석사 프로그램을 획득하여 경력을 빠르게 추적하십시오.
뛰어들어봅시다.
목차
쿠버네티스란?
Kubernetes에서 네트워킹에 대해 논의하기 전에 이 도구의 기본 개념을 고려해야 합니다. 이렇게 하면 기사의 뒷부분에서 혼란에 직면하지 않고 여기에 언급된 모든 것에 대한 기본적인 이해를 갖게 됩니다.
Kubernetes는 오픈 소스 컨테이너 오케스트레이션 도구입니다. 요즘 네트워킹의 가장 중요한 측면이 된 컨테이너 관리에 도움이 됩니다. Kubernetes에는 컨테이너 확장, 컨테이너 배포, 컨테이너 축소 등 많은 기능이 있습니다.

Docker는 전문가가 컨테이너를 생성하는 데 도움이 되지만 Kubernetes는 전문가가 컨테이너를 관리하는 데 도움이 됩니다. 그렇기 때문에 둘 다 중요합니다. Kubernetes는 클러스터를 통해 분산 시스템을 실행합니다. 구조와 네트워킹을 이해하면 실수를 피하고 오류 없이 컨테이너를 관리할 수 있습니다.
Kubernetes를 사용하는 이유는 무엇입니까?
기업의 컨테이너 요구 사항은 지난 몇 년 동안 크게 증가했습니다. 너무 작지 않으면 한두 개의 컨테이너에 의존할 수 없습니다. 로드 밸런싱을 위해 많은 양의 컨테이너가 필요합니다. 요구 사항은 고가용성을 유지하고 트래픽 균형을 유지하기 위해 수백 개가 될 수 있습니다.
트래픽이 증가하면 요청을 처리하기 위해 더 많은 컨테이너가 필요합니다. 마찬가지로 트래픽이 줄어들면 컨테이너를 축소해야 합니다. 수요에 따라 컨테이너를 관리하는 것은 특히 수동으로 수행하는 경우 어려울 수 있습니다.
컨테이너를 수동으로 오케스트레이션하려면 많은 시간과 리소스가 소요될 수 있으며, 이는 다른 곳에서 쉽게 사용할 수 있습니다. 이 작업을 자동화하면 작업이 훨씬 간단해집니다. 그러면 컨테이너의 스케일링 및 스케일 제거에 대해 걱정할 필요가 없습니다. 그것이 Kubernetes가 하는 일입니다. 초보자를 위한 최고의 DevOps 프로젝트 기사에서 Kubernetes의 도움으로 초보자를 위한 DevOps 프로젝트를 만드는 방법을 읽어보세요.
컨테이너의 오케스트레이션 및 관리를 자동화합니다. 기능으로 인해 많은 사랑을 받고 있습니다. Google 제품이며 그 성능은 조직이 컨테이너 확장을 자동화하는 데 상당한 도움이 됩니다.
Kubernetes의 구성요소
Kubernetes가 무엇이고 기능이 무엇인지 알았으므로 이제 여러 구성 요소에 대해 논의할 수 있습니다. 이 도구의 다른 부분에 익숙해진 후에야 이 도구의 네트워킹을 이해할 수 있습니다. 그러나 걱정할 것은 별로 없습니다. 저희가 도와드리기 위해서입니다. 다음은 다양한 구성 요소에 대한 간략한 설명입니다. 설명이 간결하지만 일반적인 아이디어를 제공하기에 충분해야 합니다.
포드
화학에서 물질의 가장 작은 독립적인 대상인 원자를 기억하십니까? Pod는 Kubernetes의 원자입니다. 하나의 Pod는 클러스터의 워크로드입니다. 저장소가 있는 하나 또는 여러 개의 컨테이너를 포함할 수 있습니다. 모든 포드에는 Kubernetes의 다른 구성 요소와 상호 작용할 때 ID 역할을 하는 고유한 IP 주소가 있습니다. 포드의 모든 컨테이너는 예약되고 동일한 시스템 내에 위치합니다.
컨트롤러
컨트롤러는 Kubernetes를 빌드합니다. 컨트롤러는 현재 상태가 지정한 상태와 일치하는지 확인하기 위해 API 서버의 상태를 감시합니다. 어떤 이유로 API 서버의 상태가 변경되면 그에 따라 반응합니다. 컨트롤러는 클러스터의 상태를 확인하고 필요한 상태와 비교하기 위해 루프를 사용합니다. 또한 현재 상태를 필요한 상태로 변경하는 작업을 수행할 수도 있습니다.
노드
Pod가 원자라면 노드는 Kubernetes의 기어입니다. 그들은 클러스터를 실행합니다. 가상 머신은 Kubernetes 클러스터에서 액세스 가능한 노드입니다. 많은 사람들이 '노드' 대신 '호스트'라는 단어를 사용하는 경향이 있습니다. 우리는 이 기사에서 일관되게 노드라는 용어를 사용하려고 노력했습니다.
API 서버
API 서버는 Kubernetes의 데이터 저장소에 대한 게이트웨이입니다. 클러스터에 대해 원하는 상태를 지정할 수 있습니다. Kubernetes 클러스터의 상태를 변경하고 필요한 상태를 설명하려면 API를 호출해야 합니다.
Kubernetes 네트워킹의 구성 요소에 익숙하므로 네트워킹 모델과 작동 방식부터 시작할 수 있습니다.
Kubernetes 네트워킹 설명
Kubernetes 네트워킹은 다음과 같은 제약 조건이 있는 특정 모델을 따릅니다.
- Pod는 네트워크 주소 변환 없이 다른 모든 Pod와 통신합니다.
- 노드는 네트워크 주소 변환 없이 파드와 통신할 수 있습니다.
- 다른 Pod가 보는 Pod의 IP는 자신이 보는 것과 동일한 IP입니다.
이러한 제약으로 인해 Kubernetes에는 몇 개의 네트워킹 섹션만 있습니다. 그들은:
- 컨테이너 간 전송
- 포드에서 포드로 전송
- 포드에서 서비스로 전송
- 인터넷에서 서비스로 전송
컨테이너 대 컨테이너
네트워킹에서 가상 머신이 이더넷 장치와 직접 상호 작용한다고 생각할 수 있지만 그 이상의 것이 있습니다.
Linux를 사용하는 경우 네트워크 네임스페이스는 네트워크 장치, 경로 및 방화벽 규칙이 포함된 네트워킹 스택을 제공합니다. Linux에서 실행 중인 모든 프로세스는 이 네트워크 네임스페이스와 통신합니다.

Pod는 네트워크 네임스페이스 내에 컨테이너 그룹을 보유합니다. 이러한 컨테이너는 동일한 포트 공간과 IP 주소를 가지며 네트워크 네임스페이스를 통해 할당됩니다. 이러한 컨테이너는 동일한 네임스페이스에 있기 때문에 localhost를 통해 서로를 찾습니다. 애플리케이션이 포드 내에 있는 경우 공유 볼륨에도 액세스할 수 있습니다.
포드 대 포드
Pod는 IP 주소를 통해 서로 통신합니다. 모든 Pod에는 Kubernetes의 실제 고유 IP 주소가 있습니다. Pod가 무엇인지 이미 알고 있으므로 해당 주제를 만질 필요가 없습니다. Kubernetes는 IP를 사용하여 포드 간의 통신을 용이하게 한다는 것을 알고 있습니다. 어떻게 하는지 논의해 봅시다.
Pod는 노드를 통해 통신합니다. 그렇기 때문에 Pod 간 통신을 이해하고 노드 간의 상호 작용을 이해해야 합니다.
- 노드간 통신
- 노드 내 통신
각각에 대해 자세히 설명합니다.
노드간 통신
노드가 다른 포드에 있는 경우 이 방법을 통해 통신합니다. 우리는 쉬운 예를 통해 이러한 의사 소통 방식을 이해할 수 있습니다. 4개의 다양한 포드 네트워크(포드 1, 포드 2, 포드 3 등)가 있다고 가정합니다. Pod 1과 2는 노드 1 루트 네트워크에 있고 Pod 3과 4는 두 번째 네트워크에 있습니다.
Pod 1에서 Pod 4로 패킷을 전송해야 합니다.
패킷은 먼저 포드 1 네트워크를 떠나 veth0을 통해 루트 네트워크로 이동해야 합니다. 목적지를 찾는 데 도움이 되는 Linux 브리지를 통과합니다. 노드는 Pod 내에 목표가 없으므로 인터페이스 eth0으로 다시 전송됩니다. 이제 라우팅 테이블의 첫 번째 노드를 떠납니다. 경로 테이블은 pod4에 있는 필수 노드로 패킷을 라우팅합니다. 패킷은 먼저 노드 2에 도달한 다음 브리지에 도달하여 목적지로 보냅니다.
노드 내 통신
Intra Node 통신은 노드가 동일한 Pod에 있을 때 발생합니다. 노드간 통신을 설명한 것과 같은 방식으로 노드 내 통신을 설명할 수 있습니다. 이러한 경우 패킷은 eth0의 첫 번째 파드에서 이동합니다. veth0을 통해 루트 네트워크로 이동합니다. 그런 다음 브리지를 통과해야 하며 이후 지정된 IP로 이동합니다.
이것이 Kubernetes에서 포드가 서로 통신하는 방식입니다. 다음 섹션으로 넘어 갑시다.
서비스를 위한 포드
이전 섹션에서 포드의 IP 주소 간에 트래픽이 라우팅되는 방식을 이미 보았습니다. 그러나 IP 주소에 문제가 있습니다. Pod의 IP는 컨테이너의 크기 조정에 따라 사라졌다가 다시 나타날 수 있습니다. 따라서 컨테이너가 확장되면 포드 IP의 수가 증가하게 되며 그 반대의 경우도 마찬가지입니다.
서비스는 이러한 상황을 관리하는 데 도움이 됩니다. 다음은 Kubernetes에 어떤 서비스가 있는지에 대한 간략한 설명이므로 혼동하지 마십시오.
Kubernetes의 서비스란 무엇입니까?
Kubernetes의 서비스는 요청을 포드 그룹으로 전송해야 하는 프록시를 구성합니다. 이러한 포드는 트래픽을 받고 선택기가 이 작업을 처리합니다. 서비스 생성 후 요청을 처리하는 IP 주소를 받습니다. 서비스에는 여러 유형이 있으며 서비스 통신을 위해 Pod로 이동하기 전에 먼저 논의해야 합니다.
Kubernetes에는 총 4가지 종류의 서비스가 있습니다. 그들은:
- 클러스터IP
- 노드포트
- 로드밸런서
- 외부 이름
ClusterIP는 기본 서비스 유형입니다. 이 유형에서는 클러스터에서만 서비스에 액세스할 수 있습니다. NodePort에서 서비스는 모든 노드의 IP에 노출됩니다. NodePort는 시스템이 미리 생성할 때 ClusterIP 서비스로 라우팅됩니다. ClusterIP와 달리 클러스터 외부에서 이 서비스에 연결할 수 있습니다.
LoadBalancer는 클라우드의 로드 밸런서를 사용하여 서비스를 외부 네트워크에 노출합니다. 이로 인해 NodePort와 ClusterIP가 자동으로 생성되며, ExternalName 서비스는 CNAME 레코드를 반영하여 이를 전달한다.
이제 서비스가 무엇이고 서비스 유형이 몇 가지인지 알았으므로 Pod에서 서비스로 통신하는 방법에 대해 논의해 보겠습니다.
작동 원리
이 시나리오에서 패킷은 eth0을 통해 파드를 떠납니다. eth0의 기본 경로로 전송되는 이더넷 장치를 통해 브리지로 이동합니다. 그러나 eth0에서 승인되기 전에 iptables를 거쳐야 합니다. iptables는 지정된 규칙을 사용하여 패킷의 대상을 결정하고 패킷을 필요한 Pod로 보냅니다. 일단 완료되면 패킷은 서비스의 가상 IP 대신 포드의 실제 IP로 이동합니다.
서비스 외부
이전의 세 가지 트래픽 라우팅 방법은 Kubernetes에만 관련되었습니다. 그러나 실제로는 트래픽 라우팅을 위해 Kubernetes 네트워크를 타사 네트워크에 연결해야 할 가능성이 있습니다. 그리고 이 부분은 거의 동일합니다.
외부 네트워크와 연결되면 Kubernetes는 두 가지 기능을 수행할 수 있습니다.
- 인터넷에서 네트워크로 트래픽 라우팅
- 네트워크에서 인터넷으로 트래픽 라우팅
전자는 수신 네트워크가 필요하고 후자는 송신 네트워크가 필요합니다. 살펴보겠습니다.
입구
공용 네트워크에서 Kubernetes 시스템으로 트래픽을 라우팅하는 것은 매우 까다롭습니다. 패킷을 처리하려면 LoadBalancer와 컨트롤러가 필요합니다. 다음은 작동 방식의 예입니다.
먼저 서비스를 배포하고 클라우드 공급자가 새 로드 밸런서를 생성합니다. 로드 밸런서는 서비스의 지정된 포트를 사용하여 클러스터 내의 가상 머신 전체에 트래픽을 분산합니다. 여기에서 iptables는 로드 밸런서에서 필요한 포드로 트래픽을 전송합니다. Pod는 IP로 클라이언트에 응답하고 conntrack은 올바른 방식으로 IP를 다시 작성하는 데 도움이 됩니다.
네트워크에 있는 레이어 7 로드 밸런서는 URL과 경로에 따라 들어오는 트래픽을 분할할 수 있습니다. 이는 Ingress 네트워크로 작업할 때 매우 유용합니다.
출구
Kubernetes 네트워크의 노드에서 인터넷으로 트래픽을 라우팅할 때 모든 것이 작동하는 방식은 네트워크 구성에 따라 크게 달라집니다. 여기서는 주제를 다루기 위해 일반적인 예를 논의할 것입니다.
패킷은 Pod의 네임스페이스에서 시작하여 veth를 통해 루트 네임스페이스로 이동합니다. 그런 다음 이동해야 하는 IP가 브리지와 연결되어 있지 않기 때문에 기본 서비스로 이동하는 브리지로 이동합니다. 루트 네임스페이스로 이동하는 동안 iptables를 거칩니다.

읽기: DevOps의 전제 조건: 생각하는 것과 다릅니다.
이제 인터넷 게이트웨이는 가상 머신과 연결된 IP 주소만 허용합니다. 그리고 우리 주머니의 소스 포드는 VM과 연결되어 있지 않습니다. 따라서 iptables는 소스 NAT를 수행하고 패킷의 소스를 변경합니다. 이제 다른 NAT를 통과한 다음 공용 인터넷(대상)으로 들어가는 인터넷 게이트웨이에 도달합니다.
그리고 이것이다. 이제 Kubernetes 네트워킹과 다양한 구성 요소에 대해 모두 알게 되었습니다.
결론
Kubernetes는 네트워킹에 관심이 있는 경우 반드시 배워야 하는 필수 도구 중 하나입니다. 이 분야에 익숙하지 않은 사람들은 그것이 얼마나 중요한지 모를 것입니다. 이러한 트래픽 요구 사항에 따라 컨테이너를 관리하고 트래픽을 라우팅하면 상당한 도움이 될 수 있습니다. 모든 내용을 이해하는 데 도움이 되도록 이 가이드를 최대한 명확하게 유지하려고 노력했습니다.
Kubernetes, DevOps 등을 배우고 마스터하려면 IIIT-B & upGrad의 Executive PG Program in Software Development - Specialization in Full Stack Development를 확인하십시오.