쿠버네티스에서 우리가 실행하는 애플리케이션은 Pod 단위로 수행되며 Pod는 내부에 하나 이상의 컨테이너를 가지고 있습니다.
이 말은 결국 쿠버네티스에 배포한, 그리고 구성된 시스템은 컨테이너 통신을 기초로 하는 것을 알 수 있습니다.
그렇다면 이 기초적인 컨테이너는 어떻게 네트워크 통신을 수행하는지 도커를 이용하여 컨테이너의 통신을 알아봅시다.

  • 이번 주제인 "컨테이너 간 통신"은 최대 세 개의 글로 작성될 예정입니다.

이전 글 목차
https://dev-whoan.xyz/111, 네트워크로 시작하는 쿠버네티스 — 내가 데이터를 보낸다면


사전 준비물
오늘 사전 준비물은 Ubuntu 22.04 시스템 하나만 있으면 됩니다. 컨테이너 네트워크를 시작하기 전 Network Namespace를 이용하여 실제로 어떻게 네트워크를 격리하는지 확인해 볼 예정입니다.

컨테이너와 Network Namespace

컨테이너는 Union Filesystem(overlayfs), Control Group, 그리고 Namespace를 이용하여 가상화된 환경을 제공합니다.

  1. Union Filesystem을 통해 low layer, upper layer, merged view를 통해 레이어화 된 애플리케이션 실행에 필요한 파일시스템을 제공하고
  2. Namespace를 통해 애플리케이션의 실행 환경을 분리하며
  3. Control Group을 통해 애플리케이션 실행에 필요한 하드웨어 자원을 격리, 제한하여 독립된 환경에서 안정적으로 실행될 수 있도록 하는 가상화 기술입니다.

Namespace에는 Mount Namespace, Control Group Namespace, Network Namespac  Inter Process Communication Namespace, Process ID Namespace, UTS Namespace, ... 등이 존재합니다.

각각의 이름에서 알 수 있듯이 파일 시스템, 컨트롤 그룹, 네트워크 ... 등을 격리하여 컨테이너를 실행했을 때 Host OS와 격리되어 운영할 수 있도록  합니다. 다만, 컨테이너 가상화는 Virtual Machine과는 다르게 그 특성상 Host OS로부터 완전히 독립적일 수는 없습니다.


우리가 흔히 도커, cri-o 등 컨테이너 런타임 플랫폼을 설치하면 네트워크가 새롭게 할당되는 것을 볼 수 있습니다.

일반적으로 우분투 등 운영체제의 설치를 막 마친 뒤 시스템을 켜면 다음과 같은 네트워크 시스템을 확인할 수 있습니다. (NIC의 이름은 다를 수 있습니다.)

docker@docker:~$ ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 4a:9e:7e:55:59:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.3/24 metric 100 brd 192.168.64.255 scope global dynamic enp0s1
       valid_lft 1959sec preferred_lft 1959sec
    inet6 fd9e:d858:c06b:b3ed:489e:7eff:fe55:59ee/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591937sec preferred_lft 604737sec
    inet6 fe80::489e:7eff:fe55:59ee/64 scope link
       valid_lft forever preferred_lft forever
       
docker@docker:~$ ip netns list # 아무것도 출력되지 않음
docker@docker:~$

1번 lo 인터페이스는 loopback 인터페이스입니다. 127.0.0.1을 가리키는 인터페이스로 자기 자신으로의 통신에 사용됩니다.

우리가 애플리케이션을 띄운 뒤 127.0.0.1, 혹은 alias localhost로 요청을 보낼 때 해당 인터페이스가 처리하게 됩니다.

2번 enp0s1 인터페이스는 시스템이 가지고 있는 물리 인터페이스로 (우리는 가상 머신을 이용 중이기 때문에, 이 또한 가상 인터페이스입니다.) 실제 네트워크 연결이 발생하는 인터페이스입니다. 아이피를 할당받아 실질적인 통신을 담당하는 인터페이스입니다.

이 상태에서 nginx를 설치하고 배포하는 작업을 해 보겠습니다.

docker@docker:~$ sudo apt-get update && sudo apt-get install nginx -y
docker@docker:~$ curl localhost

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.

Thank you for using nginx.

Network Namespace 추가하기

Host Namespace에서 nginx의 동작을 확인했으니, 이제 A Namespace를 생성하고 해당 위치로 nginx를 옮겨 확인을 해 봅시다. Ubuntu를 기준으로 ip 패키지를 통해 네임스페이스를 생성할 수 있습니다.

### A라는 이름의 network namespace 추가
docker@docker:~$ sudo ip netns add A
docker@docker:~$ ip netns list
A

A Network namespace에서 실질적인 통신을 담당하는 네트워크 인터페이스를 추가하여야 하는데, 일반적으로 다음의 모드를 이용합니다.

격리 모드:
    네트워크 네임스페이스는 아예 독립된 네트워크를 갖습니다.

Host Only 모드:
    네트워크 네임스페이스가 Host와만 통신 가능하도록 설정합니다.

Bridged 모드:
    Host Network Namespace에 브리지 네트워크를 생성하고, 컨테이너는 브리지 네트워크 대역에서 IP 주소를 할당받아 사용됩니다. 외부 네트워크와 통신은 호스트 네트워크를 경유(NAT 등)하여 통신합니다.

격리 모드

Dummy Type을 활용하여 Network Interface Card 생성하기


Dummy Type의 네트워크 인터페이스는 로컬에서 loopback 인터페이스 처럼 동작하는 인터페이스입니다. 즉 로컬에서의 테스트를 하거나, 격리된 환경에서 동작하는 기능을 제공합니다. 생성은 다음과 같이 수행할 수 있습니다.

docker@docker:~$ sudo ip link add dummy0 type dummy

# dummy0의 network namespace를 A로 설정합니다.
docker@docker:~$ sudo ip link set dummy0 netns A

# A 네임스페이스의 ip 링크, 주소를 확인합니다.
docker@docker:~$ sudo ip netns exec A ip link show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 7e:8e:29:d3:31:94 brd ff:ff:ff:ff:ff:ff
    
docker@docker:~$ sudo ip netns exec A ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noqueue state DOWN 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
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 7e:8e:29:d3:31:94 brd ff:ff:ff:ff:ff:ff
    
# Host Network Namespace에서는 찾을 수 없는 것을 확인할 수 있습니다.
docker@docker:~$ ip link show dummy0
Device "dummy0" does not exist.

위에서 출력해 봤을 때 dummy0은 아직 아이피 주소를 가지고 있지 않기 때문에, 실질적인 통신은 불가능한 상태입니다. 이를 위해 IP를 할당하고, dummy0을 시작해 보겠습니다.

docker@docker:~$ sudo ip netns exec A ip addr add 192.168.222.10/24 dev dummy0
docker@docker:~$ sudo ip netns exec A ip link set dummy0 up
docker@docker:~$ sudo ip netns exec A ip link set lo up
docker@docker:~$ sudo ip netns exec A ip addr show
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 7e:8e:29:d3:31:94 brd ff:ff:ff:ff:ff:ff
    inet 192.168.222.10/24 scope global dummy0
       valid_lft forever preferred_lft forever
    inet6 fe80::7c8e:29ff:fed3:3194/64 scope link
       valid_lft forever preferred_lft forever

 

docker@docker:~$ sudo apt-get update && sudo apt-get install nginx -y
docker@docker:~$ curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
docker@docker:~$ sudo ip netns exec A curl 192.168.64.3
curl: (7) Couldn't connect to server

Host Network Namespace에서 요청을 보낼 경우 nginx와 통신이 가능하지만, A 네임스페이스에서 요청을 보내면 통신이 불가능한 상태임을 확인할 수 있습니다.
마찬가지로 A Namespace에 nginx를 배포하고 Host Network Namespace에서 시도해 보아도 접근이 불가능한 것을 확인할 수 있습니다.

docker@docker:~$ sudo ip netns exec A nginx
docker@docker:~$ curl 192.168.222.10
curl: (7) Failed to connect to 192.168.222.10 port 80 after 0 ms: Connection refused

Hosted Only 네트워크

보통 Ubuntu에서 Hosted Only 네트워크 네임스페이스의 통신을 위한 경우 veth pair를 이용합니다. veth pair의 경우 설정이 간단하며, Pair (veth0, veth1의 쌍)으로 존재하여 연결하고자 하는 네임스페이스에 각각 할당하여 통신이 가능하게 바로 설정되기 때문입니다.

### veth pair를 생성합니다. 각각의 이름은 veth0, veth1 입니다.
docker@docker:~$ sudo ip link add veth0 type veth peer name veth1

## veth1의 네트워크 네임스페이스를 A로 설정합니다.
docker@docker:~$ sudo ip link set veth1 netns A

## veth0에 ip를 할당합니다.
docker@docker:~$ sudo ip addr add 192.168.202.1/24 dev veth0
docker@docker:~$ sudo ip link set veth0 up
docker@docker:~$ ip addr
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 4a:9e:7e:55:59:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.3/24 metric 100 brd 192.168.64.255 scope global dynamic enp0s1
       valid_lft 1835sec preferred_lft 1835sec
    inet6 fd9e:d858:c06b:b3ed:489e:7eff:fe55:59ee/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591955sec preferred_lft 604755sec
    inet6 fe80::489e:7eff:fe55:59ee/64 scope link
       valid_lft forever preferred_lft forever
7: veth0@if6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether ea:08:dd:65:53:66 brd ff:ff:ff:ff:ff:ff link-netns A
    inet 192.168.202.1/24 scope global veth0
       valid_lft forever preferred_lft forever
## veth1에 ip를 할당합니다. 
docker@docker:~$ sudo ip netns exec A ip addr add 192.168.202.11/24 dev veth1
docker@docker:~$ sudo ip netns exec A ip link set veth1 up
docker@docker:~$ sudo ip netns exec A ip addr show
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
6: veth1@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fe:1c:38:ae:01:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.202.11/24 scope global veth1
       valid_lft forever preferred_lft forever
    inet6 fe80::fc1c:38ff:feae:107/64 scope link
       valid_lft forever preferred_lft forever
      
## 통신이 원활히 되는 것을 확인할 수 있습니다.
docker@docker:~$ ping 192.168.202.11
PING 192.168.202.11 (192.168.202.11) 56(84) bytes of data.
64 bytes from 192.168.202.11: icmp_seq=1 ttl=64 time=0.056 ms
64 bytes from 192.168.202.11: icmp_seq=2 ttl=64 time=0.191 ms
^C
--- 192.168.202.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1013ms
rtt min/avg/max/mdev = 0.056/0.123/0.191/0.067 ms
docker@docker:~$ sudo ip netns exec A ping 192.168.202.1
PING 192.168.202.1 (192.168.202.1) 56(84) bytes of data.
64 bytes from 192.168.202.1: icmp_seq=1 ttl=64 time=0.027 ms
64 bytes from 192.168.202.1: icmp_seq=2 ttl=64 time=0.137 ms
^C
--- 192.168.202.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.027/0.082/0.137/0.055 ms

 

그렇다면 A 네임스페이스의 veth1에서 인터넷으로 요청을 보낼 수 있을까요? 잠시 멈추시고, 아래의 이유를 생각해 보시길 바랍니다.

### Host Naemspace에서 google로 요청을 보낼 수 있지만
docker@docker:~$ curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
### A Namespace에서 외부로 요청을 보낼 수 없습니다.
docker@docker:~$ sudo ip netns exec A ping -c 4 8.8.8.8
ping: connect: Network is unreachable

### 마찬가지로 google로 요청을 보낼 수 없습니다.
docker@docker:~$ sudo ip netns exec A curl google.com
curl: (6) Could not resolve host: google.com

veth pair는 namespace간 연결을 자동으로 수행해 주기 때문에, 우리는 곧바로 host os에 배포된 nginx에 요청을 보낼 수 있습니다.

### A Namespace -> veth0 OK
docker@docker:~$ sudo ip netns exec A curl 192.168.202.1
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
### Host OS 테스트
docker@docker:~$ curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

아래의 경우에 대해 이유를 생각해 보시면 좋을 것 같습니다.

docker@docker:~$ sudo ip netns exec A curl 192.168.64.3
curl: (7) Couldn't connect to server

Bridged 모드

Hosted Only 모드가 호스트와 가상 네임스페이스간의 통신만을 허용했다면, Bridged 모드는 Host에 배포된 NIC에 탑승하여 인터넷 통신이 가능하도록 합니다.
이를 위해 마찬가지로 veth pair를 생성하고, Host에 존재하는 네트워크에 탑승하도록 설정하겠습니다.

## Host OS에서 IP Forwarding이 가능하도록 설정합니다.
docker@docker:~$ sudo sysctl -w net.ipv4.ip_forward=1

## Bridge 타입의 인터페이스를 생성하고, 아이피를 할당합니다.
docker@docker:~$ sudo ip link add br0 type bridge
docker@docker:~$ sudo ip addr add 192.168.64.100/24 dev br0
docker@docker:~$ sudo ip link set br0 up

## enp0s1의 주 네트워크 장치는 br0임을 설정합니다.
docker@docker:~$ sudo ip link set enp0s1 master br0
docker@docker:~$ sudo ip link set enp0s1 up

docker@docker:~$ sudo ip link add veth0 type veth peer name veth1

docker@docker:~$ sudo ip link set veth1 netns A

## veth0의 주 네트워크 장치는 br0임을 설정합니다.
## 이를 통해 veth0이 br0을 통해 다른 네트워크 인터페이스와 통신할 수 있습니다.
## 바꿔 말하면, veth0의 쌍인 veth1이 br0을 통해 외부와 통신할 수 있음을 의미합니다.
docker@docker:~$ sudo ip link set veth0 master br0
docker@docker:~$ sudo ip link set veth0 up

## veth1에 아이피를 할당하고, 시작합니다.
docker@docker:~$ sudo ip netns exec A ip addr add 192.168.64.50/24 dev veth1
docker@docker:~$ sudo ip netns exec A ip link set veth1 up
docker@docker:~$ sudo ip netns exec A ip link set lo up

## veth1이 default 라우팅 (0.0.0.0/0)에 대한 next hop으로 192.168.64.100을 지정합니다.
docker@docker:~$ sudo ip netns exec A ip route add default via 192.168.64.100

docker@docker:~$ sudo ip netns exec A ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=42.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=41.0 ms
...

끝으로 ip link set enp0s1 master br0에 대한 명령어에 대한 이해를 해 보시기 바랍니다.


마치며

오늘의 “컨테이너 통신, Network Namespace” 글은 컨테이너 네트워크를 이해하기 위한 네트워크 격리를 어떻게 수행해야 하는지 기본적인 부분을 다루었습니다. 우리가 Dockerfile을 작성하는 등 network를 정의할 때, 각 모드가 어떻게 동작되고 네트워크를 정의할 경우 다른 컨테이너와의 통신을 어떻게 구성해야 하는지 조금이나마 이해에 도움이 되었으면 합니다.


그렇다면 이것도…

  • Hosted Only 모드에서 A Namespace에 존재하는 네트워크는 왜 외부로 요청을 보낼 수 없나요?
  • Bridged 모드에서 Host 외부의 시스템과 telent을 이용해 메시지를 주고받으려면 어떻게 해야 하나요?
  • Hosted Only와 Bridged 모드는 어떤 때 구분해서 사용해야 할까요?
  • 네트워크 격리는 어떤 때 수행해야 할까요?
  • 아래로 진행될 수록 코드가 많아졌는데, 설명할 수 있나요?

시작하기에 앞서

네트워크는 현대 사회에서 빼놓고 살아갈 수 없는 매우 중요한 인프라이자 시스템입니다. 통신이라는 이름으로 네트워크를 바라본다면 인터넷 통신 뿐만 아니라 음성 통신도 포함됩니다. 음성 통신이라는 단어가 나와서 당황하셨을 수도 있겠습니다만, 한 명의 개발자로서 혹은 관련된 직무에서 일을 하고 있는 프로로서 음성 통신을 처음 들어보셨다면 네트워크의 역사에 대해 알아보시는 것도 좋을것 같습니다.

우리가 전화기를 이용하여 상대방과 음성 통신을 하는 것을 떠올려 보면 다음과 같은 구조가 될것입니다.

우측 전화국 사진 출처: https://ko.wikipedia.org/wiki/전화교환원

이 때의 방식을 회선 교환(Circuit Switching) 방식이라 부르는데, 이미 지정된 경로를 통해 통신을 수행하게 됩니다.


송신자의 종단 즈음에서 아날로그 → 디지털로 전환된 “음성 데이터”가 기지국을 거쳐 수신자의 종단 즈음에서 디지털 → 아날로그로 전환되어 목소리를 들을 수 있게 되는거죠.


어릴 적 부모님께 전화를 걸 때, 부모님께서 이미 통화중이라면 “뚜.. 뚜.. 뚜..” 혹은 이미 통화중이라는 기계 음성을 들으신 적 있으실겁니다. (지금도 VoIP를 사용하지 않는 환경에서는 회선 교환 방식으로 통신하는 것으로 알고 있습니다.)
회선 교환 방식은 다음과 같은 특징을 가지고 있기 때문에 목표하는 회선이 이미 점유되어 있기 때문입니다.

  • 통신을 시작하기 전 두 기기간 물리적 회선을 할당합니다.
  • 한번 회선이 할당되면, 보낼 수 있는 최고 속도를 이용합니다.
  • 물리적으로 할당된 회선을 이용하기 때문에 데이터 로스 등이 발생할 확률이 적습니다.
  • 할당된 회선만을 이용하기 때문에 비교적 보안성이 높습니다.

현대 사회에는 회선 교환 방식은 패킷 교환 방식으로 대체되었습니다. 그 이유는 회선 교환 방식의 특징이자 한계점으로 인해서인데, 다음과 같습니다.

  • 모든 회선이 사용중이라면 통신이 불가능합니다.
  • 전체 회선의 성능을 나누어 사용합니다.
    • 할당만 되어 있더라도 마찬가지입니다.
  • 물리적 회선에 대한 비용이 비쌉니다.
  • 데이터 전송에 필요한 연결 수립이 필요합니다.

패킷 교환 방식은 다음의 특징을 가지고 있습니다.

  • 논리적 회선을 이용하기 때문에 망의 경로에 대해 생각할 필요 없습니다.
  • 모든 회선이 사용중이어도 통신이 가능합니다.
  • 데이터를 패킷(Packet)이라 불리는 작은 조각의 열로 전송합니다.
  • 각 패킷은 목적지 까지 어떤 경로(somehow)를 따라 hop by hop으로 이동합니다.
  • 패킷을 받은 중간 지점은 패킷이 모두 도착하기를 기다렸다가 전송하며, Fire and Forget 방식을 이용합니다.

이 외의 회선 교환, 패킷 교환 방식은 본 시리즈의 목적이 아니기 때문에 여기까지만 서술하겠습니다.


본 시리즈는 최종적으로 “쿠버네티스에서 네트워크 통신이 어떻게 이루어지는가에 대해 자세히 설명할 수 있다.” 목적을 가지고 있습니다. 이에 대해 다음의 주제로 나누어 글을 작성하려 합니다. 만약 아래 항목에 대해 이미 충분히 잘 알고 계시다면, 이 시리즈를 읽지 않으셔도 됩니다.

  • 내가 데이터를 보낸다면 어떻게 수신자에게 전달될까?
    • 네트워크 경로가 설정되고, 약속된 프로토콜을 통해 통신할 수 있다.
  • 컨테이너 간 통신은 어떻게 이루어질까?
    • Pod와 Localhost 통신으로 해결한다. 이는 Docker Network의 예시와 같다.
  • Pod와 서비스 간 통신은 어떻게 이루어질까?
    • Service Object를 이용하여 해결한다. 이는 kube-proxy를 통해 달성한다.
  • 서비스와 클러스터 외부 간 통신은 어떻게 이루어질까?
    • Service Object와 로드밸런서 등을 이용하여 해결한다.
  • Pod 간 통신은 어떻게 이루어질까?
    • Network Addons을 이용해 해결한다. 이는 우리가 흔히 알고 있는 Calico, Flannel, Cilium 등 CNI가 있다.

내가 데이터를 보낸다면

사전 준비물
두 대의 시스템간 통신을 바탕으로 데이터 송/수신을 해보겠습니다. 오늘 통신에 필요한 사전 준비물은 다음과 같습니다.
3 * Ubuntu 22.04 시스템

  • 라우터 역할 시스템
    • 종단 역할간 통신을 할 수 있도록 라우터 역할을 합니다.
    • 라우터는 초기 네트워크가 구축되지 않았다는 가정으로, 네트워크를 할당하지 않습니다.
  • 종단 역할 시스템 * 2
    • 실제 통신을 수행하는 시스템을 가정합니다.
    • 각 시스템은 서로 다른 네트워크 대역에 존재해야 하며, Hosted Only 네트워크를 할당받아야 합니다.
  • 저의 경우 각 시스템에 vCPU 1개, 2GB Ram을 할당했으며, 각 시스템은 오직 Host OS와 통신이 가능한 상태입니다.

Router

router@router:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)

router@router:~$ ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
       
router@router:~$ ping 192.168.100.2
ping: connect: Network is unreachable

router@router:~$ ping 192.168.150.2
ping: connect: Network is unreachable

Network 01

network@network01:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)

network@network01:~$ ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 5a:e9:ac:ac:e1:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.2/24 metric 100 brd 192.168.150.255 scope global dynamic enp0s1
       valid_lft 3099sec preferred_lft 3099sec
    inet6 fe80::58e9:acff:feac:e1ef/64 scope link
       valid_lft forever preferred_lft forever
       
network@network01:~$ ping 192.168.100.2
ping: connect: Network is unreachable

Network 02

network@network02:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)

network@network02:~$ ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 4e:4d:cb:7a:01:74 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 metric 100 brd 192.168.100.255 scope global dynamic enp0s1
       valid_lft 3096sec preferred_lft 3096sec
    inet6 fe80::4c4d:cbff:fe7a:174/64 scope link
       valid_lft forever preferred_lft forever
       
network@network02:~$ ping 192.168.150.2
ping: connect: Network is unreachable

지금의 상태를 토폴로지로 나타내면 다음과 같습니다.

  • 위 토폴로지의 세계상 아직 네트워크 구축이 되지 않았기 때문에, 라우터는 존재조차 하지 않는 가정으로 시작합니다.
  • Network 01과 Network 02는 지역적으로 떨어져 있는 곳에 존재함을 가정합니다.

위 토폴로지를 바탕으로 한 오늘의 목표는 다음과 같습니다.

  • Network 01 — 네트워크 — Network 02 상호간 ping 을 보낼 수 있다.
  • Network 01 — 네트워크 — Network 02 상호간 임의의 포트를 통해 메시지를 주고 받을 수 있다.
  • 클라우드 환경에서 VPC 내부의 서브넷간 통신 장애가 발생할 때 기본적인 네트워크 검사를 수행할 수 있다.
  • 클라우드 환경에서 라우팅 기반의 서브넷 통신을 정의할 수 있다.
  • 클라우드 환경에서 보안 그룹을 통해 허가된 통신만 수행할 수 있다.

왜 최초에는 Ping이 안될까?

최초 Router, Network 01, Network 02의 시스템 상에서 서로 Ping을 보내보면 Network not reachable 에러가 발생하는 것을 볼 수 있습니다. 이를 비유하기 위해 우리집 근처에 식당 A가 다음과 같이 위치한다고 가정합시다.

우리는 우리 집이 어디있는지 알고, 식당 A에 가기 위해서는 위로 도로를 건넌 뒤, 우측으로 도로를 두 번 건너면 된다는 것을 알고 있습니다.

이게 가능한 이유는 도로의 건널목을 “지표” 삼아서 식당 A로 가기 위해 건너야 하는 횡단 보도를 이미 알고 있기 때문입니다. 마찬가지로 다음과 같이 우측으로 한번 건넌 뒤, 위로 한 번 건너도 됩니다.

즉, 우리는 식당 A에 가기 위한 경로를 충분히 알고 있고, 도로를 건너는 행위를 기준으로 다음 목적지는 어디인지 알고 있는 상태입니다. 우리는 건널목 신호등의 상태 등을 감안하여 경로를 선택하면 되는겁니다. 감이 오셨을까요?
여기서 도로는 라우터이고, 다음 목적지는 어디로 가야하는지 알고 있는 행위가 바로 경로 설정입니다. 즉 라우터를 기준으로 라우팅 테이블은 작성되어 있어야 하며 이를 바탕으로 방향을 알고 길을 건널 수 있게 됩니다.

  • 도로 건널목은 네트워크 경로 상에서 “hop”으로 표현되기도 하며, 목적지에 도달하기 위해 이러한 건널목을 지나는 행위는 hop by hop으로 표현되기도 합니다.
  • 목적지 까지 여러 경로가 존재하기 때문에, 결국 어떤 방법을 통해 도달할 수 있게 됩니다. 영어로는 eventually, somehow, data will reach to the destination. 이라고도 표현합니다.

우리의 시스템으로 돌아오면, 아직 그 어느 경로도 설정되어 있지 않은것을 볼 수 있습니다.

도로는 Network 01 과 Network 02 사이에 바로 연결될 수도 있고, Network 01 — Router — Network 02 사이에 연결될 수 있습니다.
그러나 우리는 가정상, 그리고 실제 네트워크 상에서 종단간 시스템이 직접 연결되는 사례는 극히 드물기에, 이 경우는 제외하겠습니다.

경로 설정

이제 경로 설정을 수행해 보겠습니다. 우리는 현재 서로 분리되어 있는 두 시스템을 연결하는 도로를 설치해야 하는 상태입니다.
잠시 여기서 멈추시어 실생활에서 여러분은 이러한 도로의 역할로 어떤 매개체를 이용하고 있는지 한번 생각해 보시길 바랍니다.
보통 우리는 스마트폰, 노트북 등을 네트워크에 연결하기 위해 무선 매개체인 와이파이를 흔히 이용하고, 집 혹은 회사에 있는 데스크톱을 네트워크에 연결하기 위해 유선 매개체인 LAN 선을 이용하곤 합니다.

  • 와이파이 등 무선 인프라의 경우에도 언젠가는 Access Point를 통해 유선 장비에 연결되어 데이터 통신을 수행합니다.

자, 드디어 경로 설정을 수행할 차례입니다. 우리는 Router와 Network 01을 연결하는 도로가 필요하며, Router에서 Network 02를 연결하는 도로가 필요합니다.

router@router:~$ ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 3a:9e:6f:dc:26:7b brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.3/24 metric 100 brd 192.168.150.255 scope global dynamic enp0s1
       valid_lft 3587sec preferred_lft 3587sec
    inet6 fe80::389e:6fff:fedc:267b/64 scope link
       valid_lft forever preferred_lft forever
3: enp0s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ca:76:d5:f7:6a:85 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 metric 100 brd 192.168.100.255 scope global dynamic enp0s2
       valid_lft 3587sec preferred_lft 3587sec
    inet6 fe80::c876:d5ff:fef7:6a85/64 scope link
       valid_lft forever preferred_lft forever

도로가 정상적으로 연결되어 있는지 Router ←→ Network 01, 02를 수행해 보겠습니다.
Router ←→ Network 01

# Router -> Network 01 OK       
router@router:~$ ping 192.168.150.2 -c 1
PING 192.168.150.2 (192.168.150.2) 56(84) bytes of data.
64 bytes from 192.168.150.2: icmp_seq=1 ttl=64 time=0.787 ms

--- 192.168.150.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.787/0.787/0.787/0.000 ms

# Network 01 -> Router OK
network@network01:~$ ping 192.168.150.3 -c 1
PING 192.168.150.3 (192.168.150.3) 56(84) bytes of data.
64 bytes from 192.168.150.3: icmp_seq=1 ttl=64 time=1.54 ms

--- 192.168.150.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.541/1.541/1.541/0.000 ms

Router ←→ Network 02

# Router -> Network 02 OK
router@router:~$ ping 192.168.100.2 -c 1
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.
64 bytes from 192.168.100.2: icmp_seq=1 ttl=64 time=2.86 ms

--- 192.168.100.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.861/2.861/2.861/0.000 ms

# Network 02 -> Router OK
network@network02:~$ ping 192.168.100.3 -c 1
PING 192.168.100.3 (192.168.100.3) 56(84) bytes of data.
64 bytes from 192.168.100.3: icmp_seq=1 ttl=64 time=18.7 ms

--- 192.168.100.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 18.722/18.722/18.722/0.000 ms

생긴것만 보아하면, Network 01과 Network 02는 통신이 가능할 것 같습니다. 그러나 실질적으로 통신은 수행되지 않습니다.

# Network 01 -> Network 02 Fail
network@network01:~$ ping 192.168.100.2
ping: connect: Network is unreachable

# Network 02 -> Network 01 Fail
network@network02:~$ ping 192.168.150.2
ping: connect: Network is unreachable

그 이유는 Network 01은 Router 까지 가는 방법만 알고, Network 02 또한 Router 까지 가는 방법만 알고 있기 때문입니다. 예상하신바와 같이 Network 01 → Router → Network 02를 수행하고, 마찬가지로 Network 02 → Router → Network 01을 수행하면 됩니다.
하지만 상대는 컴퓨터기 때문에, 이러한 경로를 직접 알려줘야 합니다. 이러한 경로 설정은 ubuntu 22.04 기준 ip 패키지를 이용할 수 있는데, 명령어는 다음과 같습니다.

# route 확인
$ ip route

## Network 01의 기존 Route
network@network01:~$ ip route
192.168.150.0/24 dev enp0s1 proto kernel scope link src 192.168.150.2 metric 100

## Network 02의 기존 Route 
network@network02:~$ ip route
192.168.100.0/24 dev enp0s1 proto kernel scope link src 192.168.100.2 metric 100

# route 추가
$ sudo ip route add DESTINATION via HOP

# route 제거
$ sudo ip route del DESTINATION
  • Destination은 Subnet으로 설정하는 것이 좋습니다.

한번 Network 01에서 Network 02로 가기 위한 Hop을 Router로 설정해 보고 테스트 해보겠습니다. 그러나 예상과는 다르게 아직 Network 01에서 Network 02로 Ping을 보내는 것이 불가능한 상태입니다.

# sudo ip route add Network 02 대역 via Router
$ sudo ip route add 192.168.100.0/24 via 192.168.150.3

$ ping 192.168.100.2 -c 10
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.

--- 192.168.100.2 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9203m

흔히 네트워크를 공부할때 프로토콜(규약)은 사람의 인사로 비유 되곤 합니다. 사람간 대화를 시작하기 위해서, 혹은 인사를 할 때 누군가 말을 건네면 응답해 주는것이 일반적인 상황입니다. 그러나 우측과 같이 인사를 무시하는 경우도 발생할 수 있습니다. 영희가 바빠서 듣지 못했든, 이어폰을 끼고 있든, 의도적으로 무시했든, 철수는 상대방이 대화할 수 없는, 인사를 받을 수 없는 상황으로 인지할것입니다. 이 경우 철수는 다시 인사를 시도하거나, 영희에게 더 이상 말을 걸지 않을것입니다.

 
현재 우리 시스템에서 Network 01 → Network 02로 Ping을 보낼 때, 아래와 같이 영희가 응답하지 않는 상황입니다. 확인을 위해 Shell을 두 개 켠 뒤 tcpdump를 통해 확인해보면, 다음과 같이 모두 Network 02의 아이피로 request만 전달되고, reply가 오지 않는 것을 확인할 수 있습니다.

### Network 01 Shell 1
network@network01:~$ ping 192.168.100.2 -c 10
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.

--- 192.168.100.2 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9217ms

### Network 01 Shell 2
network@network01:~$ sudo tcpdump -e -i enp0s1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
02:14:07.734171 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 1, length 64
02:14:08.761944 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 2, length 64
02:14:09.786101 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 3, length 64
02:14:10.810160 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 4, length 64
02:14:11.833783 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 5, length 64
02:14:12.858743 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 6, length 64
02:14:13.882743 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 7, length 64
02:14:14.905286 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 8, length 64
02:14:15.931328 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 9, length 64
02:14:16.951320 5a:e9:ac:ac:e1:ef (oui Unknown) > 3a:9e:6f:dc:26:7b (oui Unknown), ethertype IPv4 (0x0800), length 98: network01 > 192.168.100.2: ICMP echo request, id 3, seq 10, length 64

이는 Network 02에서 확인해 볼 때도 마찬가지 입니다. 들어오는 request는 보이지만, reply는 보이지 않습니다.

network@network02:~$ sudo tcpdump -e -i enp0s1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
02:22:25.253982 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 1, length 64
02:22:26.257601 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 2, length 64
02:22:27.284460 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 3, length 64
02:22:28.307913 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 4, length 64
02:22:29.330388 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 5, length 64
02:22:30.356599 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 6, length 64
02:22:31.378002 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 7, length 64
02:22:32.403816 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 8, length 64
02:22:33.426113 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 9, length 64
02:22:34.455507 ca:76:d5:f7:6a:85 (oui Unknown) > 4e:4d:cb:7a:01:74 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.150.2 > network02: ICMP echo request, id 11, seq 10, length 64

10 packets captured
10 packets received by filter
0 packets dropped by kernel

한번 직접 Router와 통신해 보시고 결과가 어떤지, 그리고 그 이유가 무엇인지 생각해 보시면 좋을것 같습니다.
Network간 통신이 불가능했던 이유는 우여곡절 끝에 192.168.100.0/24 의 이름을 가진 도로명을 알아냈지만, 다시 집으로 돌아가는 길을 잊었기 때문입니다.

  • 혹은 192.168.100.0/24 도로를 알아낸 뒤, 식당에 도착했지만 알고보니 국경선을 무단으로 넘은 상태여서 집으로 돌아오지 못하는 상태일수도 있겠습니다.

즉 우리는 이를 위해 Network 01에서 한 바와 같이 Network 02 → Network 01의 경로를 설정해야 합니다. 이제 Network 01로 돌아가서 Network 02로 정상적으로 ping이 보내지는 것을 확인할 수 있습니다.

network@network02:~$ sudo ip route add 192.168.150.0/24 via 192.168.100.3
network@network02:~$ ip route
192.168.100.0/24 dev enp0s1 proto kernel scope link src 192.168.100.2 metric 100
192.168.150.0/24 via 192.168.100.3 dev enp0s1

# Network 01 -> Network 02 OK
network@network01:~$ ping 192.168.100.2 -c 4
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.
64 bytes from 192.168.100.2: icmp_seq=1 ttl=63 time=10.0 ms
64 bytes from 192.168.100.2: icmp_seq=2 ttl=63 time=7.68 ms
64 bytes from 192.168.100.2: icmp_seq=3 ttl=63 time=2.61 ms
64 bytes from 192.168.100.2: icmp_seq=4 ttl=63 time=5.04 ms

--- 192.168.100.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 2.612/6.344/10.047/2.788 ms

# Network 02 -> Network 01 OK
network@network02:~$ ping 192.168.150.2 -c 4
PING 192.168.150.2 (192.168.150.2) 56(84) bytes of data.
64 bytes from 192.168.150.2: icmp_seq=1 ttl=63 time=1.45 ms
64 bytes from 192.168.150.2: icmp_seq=2 ttl=63 time=5.22 ms
64 bytes from 192.168.150.2: icmp_seq=3 ttl=63 time=2.65 ms
64 bytes from 192.168.150.2: icmp_seq=4 ttl=63 time=3.90 ms

--- 192.168.150.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3014ms
rtt min/avg/max/mdev = 1.454/3.305/5.219/1.403 ms

경로 설정을 위해 만든 Router가 정상적으로 동작하는지 확인하고 싶으시다면 tcpdump를 이용하여 확인 가능합니다.

## enp0s1은 Router의 192.168.150.3/24를 가지는 NIC 입니다.
## enp0s2를 확인해 보아도 이와 비슷한 결과가 나옵니다.
router@router:~$ sudo tcpdump -i enp0s1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s1, link-type EN10MB (Ethernet), snapshot length 262144 bytes

# Network 01 -> Network 02
14:52:46.193749 IP 192.168.150.2 > 192.168.100.2: ICMP echo request, id 41, seq 1, length 64
14:52:46.194851 IP 192.168.100.2 > 192.168.150.2: ICMP echo reply, id 41, seq 1, length 64
14:52:47.195687 IP 192.168.150.2 > 192.168.100.2: ICMP echo request, id 41, seq 2, length 64
14:52:47.198908 IP 192.168.100.2 > 192.168.150.2: ICMP echo reply, id 41, seq 2, length 64
14:52:48.200837 IP 192.168.150.2 > 192.168.100.2: ICMP echo request, id 41, seq 3, length 64
14:52:48.202546 IP 192.168.100.2 > 192.168.150.2: ICMP echo reply, id 41, seq 3, length 64
14:52:49.203013 IP 192.168.150.2 > 192.168.100.2: ICMP echo request, id 41, seq 4, length 64
14:52:49.204313 IP 192.168.100.2 > 192.168.150.2: ICMP echo reply, id 41, seq 4, length 64

# Network 02 -> Network 01
14:53:03.654250 IP 192.168.100.2 > 192.168.150.2: ICMP echo request, id 5, seq 1, length 64
14:53:03.655086 IP 192.168.150.2 > 192.168.100.2: ICMP echo reply, id 5, seq 1, length 64
14:53:04.639904 IP 192.168.100.2 > 192.168.150.2: ICMP echo request, id 5, seq 2, length 64
14:53:04.641619 IP 192.168.150.2 > 192.168.100.2: ICMP echo reply, id 5, seq 2, length 64
14:53:05.644196 IP 192.168.100.2 > 192.168.150.2: ICMP echo request, id 5, seq 3, length 64
14:53:05.645515 IP 192.168.150.2 > 192.168.100.2: ICMP echo reply, id 5, seq 3, length 64
14:53:06.648683 IP 192.168.100.2 > 192.168.150.2: ICMP echo request, id 5, seq 4, length 64
14:53:06.652468 IP 192.168.150.2 > 192.168.100.2: ICMP echo reply, id 5, seq 4, length 64

허가된 통신

우리는 이제 VIP만 들어갈 수 있는 식당을 가보고자 합니다. VIP 식당은 보디가드를 통해서 선별된 인원만 접근이 가능하도록 하고 있습니다. 네트워크 통신에서는 방화벽을 통해 이 보디가드의 역할을 수행할 수 있습니다.
우리는 메시지 송수신을 위해 telnet(telecommunications network)과 nc(netcat) 를 이용할 예정입니다. nc를 이용하여 네트워크에 들어오는 메시지를 읽고, telnet을 이용하여 메시지를 보낼 예정입니다.
Router는 라우터 역할을 위해 Network 01 ←→ Network 02간 패킷을 모두 Forwarding 하는 것을 전제로 합니다.

## FORWARD 룰을 추가합니다.
## enp0s1으로 들어오는 192.168.150.0/24 대역의 송신지를 enp0s2의 192.168.100.0/24로 전달합니다.
router@router:~$ sudo iptables -A FORWARD -i enp0s1 -o enp0s2 -s 192.168.150.0/24 -d 192.168.100.0/24 -j ACCEPT
router@router:~$ sudo iptables -A FORWARD -i enp0s2 -o enp0s1 -s 192.168.100.0/24 -d 192.168.150.0/24 -j ACCEPT

최초 특별한 설정 없이 nc와 telnet을 이용하여 연결을 시도해보면, 통신이 불가능한 것을 볼 수 있습니다.

## 수신자, Network 02
network@network02:~$ nc --listen 12345
# 메시지 대기중

## 송신자, Network 01
network@network01:~$ telnet 192.168.100.2 12345
Trying 192.168.100.2...
# 연결 대기중...

이는 Network 02의 방화벽은 12345 포트를 통한 데이터 통신이 허용되지 않았기 때문입니다. 방화벽에 추가하고 다시 한번 통신을 시도하면 정상적으로 메시지 송/수신이 가능한 것을 확인할 수 있습니다.

network@network02:~$ sudo ufw allow 12345/tcp
Rule added
Rule added (v6)
network@network02:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
12345/tcp                  ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
12345/tcp (v6)             ALLOW       Anywhere (v6)

network@network02:~$ nc -l 12345

---
network@network01:~$ telnet 192.168.100.2 12345
Trying 192.168.100.2...
Connected to 192.168.100.2.
Escape character is '^]'.

마지막으로 메시지를 주고 받고, 오늘의 글을 마무리 하겠습니다.


마치며

오늘의 “내가 데이터를 보낸다면 어떻게 수신자에게 전달될까?” 글은 정말 기본적이면서도 필수로 알아야 하는 사항만을 다루었습니다. 시작할 때 짧게 서술한 음성 통신과 데이터 통신의 관계부터 하나의 라우터로 알아보는 시스템 통신에 필요한 경로설정, 그리고 방화벽을 통한 최소한의 보안 설정까지.


여기 까지 처음 보는 내용이나 몰랐던 부분이 있으셨다면, 해당 부분을 바탕으로 꼭 정리를 하셨으면 합니다. 오늘 본 부분은 기초이자 꼭 알아야 하는 부분이며, 앞으로 이어나갈 쿠버네티스의 네트워크에 있어서 굉장히 중요한 부분이기 때문입니다.


그렇다면 이것도…

  • 클라우드 환경에서 네트워크 통신을 수행하기 위해 Virtual Private Cloud를 만들고, 필요한 만큼의 인스턴스를 할당할 수 있는 네트워크를 할당할 수 있으신가요?
  • VPC와 External, VPC와 Internal, 그리고 External ←→ Internal 통신을 수행할 때 필요한 경로만을 설정했고, 보안 그룹은 어떻게 설정하셨나요?
  • 보안 그룹은 어떻게 구성하는게 좋을까요?
  • 오늘 한 시스템에서 Router가 여러개 존재한다면 어떻게 통신이 일어날까요?
  • Router에서 어떻게 경로 설정을 수행하나요?
  • Packet Loss는 어떤 환경에서 일어나는지 알고 계신가요?
  • 네트워크 통신 중 장애가 발생했다면, 원인 분석을 할 수 있으신가요?

컨테이너에 대해 공부를 해야겠다는 생각, 그리고 숙제로 미루어 왔던 Control Group에 대해 공부하자는 계획을 세운 뒤 꽤나 오랜 시간이 흘렀습니다. 링크드인의 글을 눈팅하던 중 우연히 “쿠버네티스가 쉬워지는 컨테이너이야기 시리즈” 게시글을 보게 되었고, 해당 글을 바탕으로 공부를 시작했습니다.

앞으로 작성할 cgroup 관련 게시글은 해당 글을 바탕으로 컨테이너에 대한 이해도를 높이고자 작성한 글 입니다.

원글의 출처는 아래와 같습니다.

쿠버네티스가 쉬워지는 컨테이너 이야기 — cgroup, cpu편 (https://medium.com/@7424069/쿠버네티스가-쉬워지는-컨테이너-이야기-cgroup-cpu편-c8f1e2208168), 천강진 님


이 글이 도움 될 사람

  1. 쿠버네티스가 쉬워지는 컨테이너 이야기 시리즈를 읽었지만 이해가 안되는 부분이 있는 사람
  2. 컨테이너가 리눅스의 union filesystem, cgroup, namespace를 이용해 만들어지는 것을 알고 있는 사람
  3. cgroup이 단순히 자원을 격리한다는 것만 알고 있는 사람

 

본 글의 마지막 부분에는 천강진 님의 이번 글의 대상이 아닌 독자에 대한 개인적인 견해를 작성해 놓았습니다.


컨테이너

컨테이너는 리눅스의 union fs (overlayfs), cgroup, namespace를 이용하여 host os의 메인 워크로드와 격리된 워크로드를 제공하는 가상화 솔루션입니다.

union filesystem을 이용하여 애플리케이션을 실행하기 위한 운영체제 환경부터 시작하여 서비스 바이너리까지 레이어로 나뉘어진 하나의 통합된 파일 시스템을 제공하여 언제 어디서든 동일한 환경을 제공하고 namespace를 이용하여 애플리케이션 프로세스를 격리하여 독립된 환경을 제공할 수 있다면,

control group은 이렇게 격리된 환경, 그리고 언제나 동일한 애플리케이션을 실행하기 위한 리눅스 프로세스 그룹에 시스템 자원을 격리, 할당하여 제어할 수 있도록 해 줍니다.

정리하자면,

  1. Union Filesystem을 통해 low layer, upper layer, merged view를 통해 레이어화 된 애플리케이션 실행에 필요한 파일시스템을 제공하고
  2. Namespace를 통해 애플리케이션의 실행 환경을 분리하며
  3. Control Group을 통해 애플리케이션 실행에 필요한 하드웨어 자원을 격리, 제한하여 독립된 환경에서 안정적으로 실행될 수 있도록 하는 가상화 기술입니다.

“천강진”님의 시리즈를 읽으면서 Control Group을 이해한다면 컨테이너 환경에서의 안정적으로 하드웨어 자원을 제공할 수 있을 뿐 아니라, 애플리케이션에 어떤 현상 혹은 문제가 발생했을 때 조금 더 넓은 각도에서 원인을 분석하고 문제를 해결할 수 있을 것이라 느꼈습니다.

Control Group은 /sys/fs/cgroup 아래에 논리 제어 그룹을 확인할 수 있으며 루트 제어 그룹 아래에 자식 제어 그룹이 존재하는 형태입니다. 새로운 논리 그룹을 생성하려면 대상의 루트, 혹은 자식 제어 그룹에 폴더를 생성하면 됩니다.

출처: 쿠버네티스가 쉬워지는 컨테이너 이야기 — cgroup, cpu편, 천강진님

A라는 논리 그룹을 새롭게 만들 경우, 리눅스 시스템에 의해 해당 디렉토리 아래에 자동으로 다음과 같은 구조가 추가됩니다.

단순히 논리 그룹을 만듦으로써 프로세스 격리된 제어 그룹 공간을 활용하는 것은 아닙니다. 생성된 제어 그룹에 실행중인 프로세스의 ID를 할당함으로써 실질적인 제어 그룹을 이용하게 됩니다.

물론 아직 제어 그룹에 대해 자원에 대한 제한을 설정하지 않았기 때문에 아직은 루트 제어 그룹을 그대로 따르는 상태입니다.


Docker의 Control Group과 CPU

잠깐! macOS의 경우 /sys/fs/cgroup을 찾을 수 없습니다. 아래의 명령어를 통해 host의 /sys/fs/cgroup을 확인할 수 있는 컨테이너를 실행해 주세요.

docker run --rm -d -it \
  --privileged --pid=host \
  --name cgroup-host \
  justincormack/nsenter1

예제에서 사용된 컨테이너의 경우 아래 명령어로 생성할 수 있습니다.

docker run -d --rm --privileged --name cgroup docker:27.3.1-dind-alpine3.20

도커는 컨테이너를 생성할 때, 하나의 논리 제어 그룹을 생성합니다. 도커를 운영중인 환경에서 /sys/fs/cgroup을 확인해보면 아래와 같이 docker 디렉토리가 존재하는 것을 확인할 수 있습니다.

/sys/fs/cgroup # ls
cgroup.controllers               cpu.weight.nice                  memory.low
cgroup.events                    cpuset.cpus                      memory.max
cgroup.freeze                    cpuset.cpus.effective            memory.min
cgroup.kill                      cpuset.cpus.exclusive            memory.oom.group
cgroup.max.depth                 cpuset.cpus.exclusive.effective  memory.peak
cgroup.max.descendants           cpuset.cpus.partition            memory.reclaim
cgroup.procs                     cpuset.mems                      memory.stat
cgroup.stat                      cpuset.mems.effective            memory.swap.current
cgroup.subtree_control           **docker**                           memory.swap.events
cgroup.threads                   **init.scope**                       memory.swap.high
cgroup.type                      io.max                           memory.swap.max
cpu.idle                         io.stat                          memory.swap.peak
cpu.max                          **k3s**                              pids.current
cpu.max.burst                    memory.current                   pids.events
cpu.stat                         memory.events                    pids.events.local
cpu.stat.local                   memory.events.local              pids.max
cpu.weight                       memory.high                      pids.peak
/sys/fs/cgroup #

이후 docker 아래의 경로를 확인해보면, 실제로 실행중인 container id 이름으로 제어 그룹이 각각 생성되어 있는것 또한 확인할 수 있습니다.

/sys/fs/cgroup # cd docker
/sys/fs/cgroup/docker # ls
5d16df9b31de84920181fc18e72b4fb5725c9353b3b27f5a758e41cbb039eb54
b1a5dc151e15a4373d30adbc920e8e9ced70e1632d3027c2c4acc55efaeb2395
ba834863df92a0f9919c98e4829d6fb8a4dbdf66e81507f103e75dd710a4c566
cgroup.controllers
cgroup.events
cgroup.freeze
cgroup.kill
cgroup.max.depth
cgroup.max.descendants
cgroup.procs
cgroup.stat
cgroup.subtree_control
cgroup.threads
cgroup.type
cpu.idle
cpu.max
cpu.max.burst
cpu.stat
cpu.stat.local
cpu.weight
cpu.weight.nice
cpuset.cpus
cpuset.cpus.effective
cpuset.cpus.exclusive
cpuset.cpus.exclusive.effective
cpuset.cpus.partition
cpuset.mems
cpuset.mems.effective
e1277fe09be51e878f1b38bb4936982295c68f1f0b0429f9c4ab8319494cc6a5
io.max
io.stat
memory.current
memory.events
memory.events.local
memory.high
memory.low
memory.max
memory.min
memory.oom.group
memory.peak
memory.reclaim
memory.stat
memory.swap.current
memory.swap.events
memory.swap.high
memory.swap.max
memory.swap.peak
pids.current
pids.events
pids.events.local
pids.max
pids.peak
/sys/fs/cgroup/docker #

아래는 Host OS에서 docker ps 명령어를 입력했을 때 보이는 컨테이너 입니다.

$ docker ps
CONTAINER ID   IMAGE                           COMMAND                   CREATED         STATUS         PORTS                                                  NAMES
b1a5dc151e15   justincormack/nsenter1          "/usr/bin/nsenter1"       3 minutes ago   Up 3 minutes                                                          cgroup-host
e1277fe09be5   docker:27.3.1-dind-alpine3.20   "dockerd-entrypoint.…"    7 minutes ago   Up 7 minutes   2375-2376/tcp                                          cgroup
5d16df9b31de   mysql:8.0                       "docker-entrypoint.s…"    4 days ago      Up 7 minutes   0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060/tcp   mysql
ba834863df92   redis:7.4                       "docker-entrypoint.s…"    4 days ago      Up 7 minutes   0.0.0.0:6379->6379/tcp, :::6379->6379/tcp              redis

우리가 생성한 예제의 경우 e1277fe09be5로 실행되고 있는 것을 확인할 수 있으며, 현재 아무 자원 제한을 두지 않았기 때문에 cpu의 max, 가중치를 Host OS에서 확인해 봤을 때 모두 기본 값임을 확인할 수 있습니다.

/sys/fs/cgroup/docker # cat e1277fe*/cpu.weight
100
/sys/fs/cgroup/docker # cat e1277fe*/cpu.max
max 100000
/sys/fs/cgroup/docker # cat e1277fe*/cpu.stat
usage_usec 2073096
user_usec 1489344
system_usec 583751
nr_periods 0
nr_throttled 0
throttled_usec 0
nr_bursts 0
burst_usec 0

컨테이너를 실행할 때 cpu 할당량을 설정한다면 아래와 같은 변화를 확인할 수 있습니다.

$ docker stop cgroup
$ docker run -d --rm --privileged --cpus 0.5 --name cgroup docker:27.3.1-dind-alpine3.20
8292ce42483c59539655d0f727d771cadee933a91c74fe92b53feec96a0b31cd
  • 아래 코드는 Host OS에서 실행한 결과입니다.
/sys/fs/cgroup/docker # cat 8292ce*/cpu.weight
100
/sys/fs/cgroup/docker # cat 8292ce*/cpu.max
50000 100000
/sys/fs/cgroup/docker # cat 8292ce*/cpu.stat
usage_usec 1927030
user_usec 1741681
system_usec 185349
nr_periods 113
nr_throttled 35
throttled_usec 1735216
nr_bursts 0
burst_usec 0

control group에서, 다시 말해 컨테이너에서 cpu 자원을 제한한다는 의미는 CPU 스케줄링에 있어서 얼만큼 자원을 선점할 수 있느냐를 의미하는데, 다시 말해 --cpus 0.5를 설정하는 행위는 100ms 동안 50ms를 선점할 수 있다는 것을 의미하게 됩니다.

  • 해당 부분이 이해되지 않으신다면, 운영 체제의 CPU 스케줄링에 대해 찾아보시면 좋을것 같습니다.

만약 1개를 넘어가면 어떻게 될까요? 간단하게 하기 위해 cpu 개수를 2로 할당한다면, 다음과 같은 결과가 나오게 됩니다.

$ docker stop cgroup
$ docker run -d --rm --privileged --cpus 2 --name cgroup docker:27.3.1-dind-alpine3.20
68b5952c3487249c14eb48c9649d916475ae7d4593386c9e234d90ba0a92d9f1

---

/sys/fs/cgroup # cd docker
/sys/fs/cgroup/docker # cat 68b5952*/cpu.max
200000 100000
$ docker stop cgroup
$ docker run -d --rm --privileged --cpus 2 --name cgroup docker:27.3.1-dind-alpine3.20
68b5952c3487249c14eb48c9649d916475ae7d4593386c9e234d90ba0a92d9f1

---

/sys/fs/cgroup # cd docker
/sys/fs/cgroup/docker # cat 68b5952*/cpu.max
200000 100000

100ms 동안 200ms를 선점할 수 있다는 것이 이상하다 느껴질 수 있습니다.

실제 애플리케이션이 동작하는 환경은 다수의 CPU를 가지는 환경이기 때문에, 단일 CPU의 환경이 아닌 이상 여러 CPU를 통해 각각 100%를 선점하여 200ms를 달성하게 됩니다.

그렇기 때문에 컨테이너 플랫폼 혹은 오케스트레이션 환경에서 cpu 자원을 요청하거나 제한할 때 실제 cpu의 core 수를 넘어서 요청할 수 없게 됩니다.


쿠버네티스의 cpu.weight (cpu.shares)

cpu.weight은 control group을 통해 생성하는 프로세스의 cpu 가중치를 설정할 수 있습니다. 일반적으로 도커, crio 등 컨테이너 플랫폼 환경을 실행한다면 cpu.weight은 일반적으로 100으로 설정되는 것을 확인할 수 있습니다. 이 경우 “천강진”님의 예제를 통해 cpu.weight을 쉽게 이해하실 수 있습니다.

하지만 실제 컨테이너 오케스트레이션 환경(쿠버네티스 등)이나 SaaS, PaaS로 제공되는 환경의 경우 cpu.weight 값이 100으로 설정되어 있지 않는 경우도 있는데, 이 경우 실행하는 서비스 혹은 환경에 의해 cpu.weight 값이 계산되어 할당됩니다. 이는 실제 CPU 리소스를 할당할 때 상대적인 CPU 우선순위를 설정하는 cpu.weight의 특징이자 영향을 받았기 때문입니다.

아래는 온프레미스 환경에 쿠버네티스를 설치하고 제어 그룹 디렉토리로 이동했을 때의 상태입니다. 아직 아무 파드도 설치하지 않았으며, crio v1.31과 쿠버네티스 1.31.2를 설치한 직후의 상태입니다.

root@worker1:/sys/fs/cgroup # ls
A                       cgroup.procs            cpu.pressure           dev-hugepages.mount  io.cost.qos    kubepods.slice    misc.capacity                  sys-kernel-debug.mount
cgroup.controllers      cgroup.stat             cpu.stat               dev-mqueue.mount     io.pressure    memory.numa_stat  proc-sys-fs-binfmt_misc.mount  sys-kernel-tracing.mount
cgroup.max.depth        cgroup.subtree_control  cpuset.cpus.effective  init.scope           io.prio.class  memory.pressure   sys-fs-fuse-connections.mount  system.slice
cgroup.max.descendants  cgroup.threads          cpuset.mems.effective  io.cost.model        io.stat        memory.stat       sys-kernel-config.mount        user.slice
root@worker1:/sys/fs/cgroup # cat kubepods.slice/cpu.weight
79

쿠버네티스의 경우 cpu.weight의 값이 79인 이유는 Control Group V1에서 V2로 넘어오면서 cpu.shares를 cpu.weight로 변환하는 과정에서 스케일링이 발생했기 때문입니다.

  • cpu.shares는 실질적으로 가중치를 할당하여 사용한다기 보다 cpu.shares가 설정된 제어 그룹 간의 비율을 바탕으로 CPU 자원을 나눠 사용할 수 있게 됩니다. 즉 cpu.shares가 512, 1024, 2048로 설정되어 있다면, 1:2:4의 비율로 cpu 자원을 할당받아 사용할 수 있게 됩니다. cpu.shares의 최대 값은 2^18 - 2인 262142를 갖습니다.
    • control group v1 에서 cpu.shares는 최대 값은 이론상 2^32를 갖지만, 시스템의 안정성 등을 위해 최대 값을 2^18로 제한하고 있습니다.
    • 실제로 Ubuntu 등 Linux 계열의 cpu.shares의 옵션을 보면 [2, 262144] 값을 가지고 있습니다.
    • 2를 빼는 이유는 cpu.shares의 최소값인 2를 보장하기 위함입니다.
  • 이러한 cpu.shares를 [1, 10000]의 범위를 갖는 cpu.weight로 변환하기 위해서는 다음의 식이 사용됩니다.
    • 1 + ((cpu shares - 2) * [cpu.weight의 맥스 - 최소값] ) / [cpu.shares의 맥스 - 최소값]
    • 1 + ((cpu shares - 2) * 9999) / 262142
    • 이 때 1을 더해주는 이유는 int 값이기 때문에 버려지는 값을 보완하기 위함입니다.
  • cpu.weight 값을 새롭게 스케일링 한 것이 아니라, cpu.shares와 최대한 유사한 값을 제공하기 위한 식입니다.

이를 바탕으로 2 개의 vCPU (CPU 코어)를 갖는 쿠버네티스 환경에서는 1 + (( 2048 - 2 ) * 9999 ) / 262142 값인 79를 도출하게 됩니다.

자 그렇다면 이제 실질적으로 resources.requests.cpu를 설정하여 파드를 배포해서 확인해 봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: a
  namespace: default
spec:
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
    resources:
      requests:
        cpu: 250m
  restartPolicy: Always
  nodeSelector:
    kubernetes.io/hostname: worker1

위 yaml을 바탕으로 pod를 배포하게 되면 cpu.weight의 값은 얼마가 될지 한번 고민해 봅시다.

우리는 전체 CPU shares인 2048에 대해 250m을 요청했고, 2개의 코어를 갖는 노드에서 CPU Weight는 79를 갖고 있습니다. 즉 250 / 2048 만큼 요청했고, 79의 가중치를 갖기 때문에 다음과 같은 식을 갖는다고 예상할 수 있습니다.

1 + 250 / 2048 * 79 ~= 9.6 (10)

이를 직접 워커 노드의 /sys/fs/cgroup을 통해 확인해봅시다.

root@worker1:~# crictl ps
CONTAINER           IMAGE                                                                                                     CREATED             STATE               NAME                ATTEMPT             POD ID              POD
**8a6b6f7c79ece       27a71e19c95622dce4d60d4a3760707495c9875f5c5322c5bd535214799593ce                                          29 minutes ago      Running             busybox             0                   c063f7c199d23       a**
9f61aea39bdf1       registry.k8s.io/coredns/coredns@sha256:f0b8c589314ed010a0c326e987a52b50801f0145ac9b75423af1b5c66dbd6d50   13 hours ago        Running             coredns             0                   fb79be5137b43       coredns-7c65d6cfc9-k65k4
89986ea9962fa       registry.k8s.io/coredns/coredns@sha256:f0b8c589314ed010a0c326e987a52b50801f0145ac9b75423af1b5c66dbd6d50   13 hours ago        Running             coredns             0                   220bc9ce4e46f       coredns-7c65d6cfc9-hrx2k
f34df68b00d35       registry.k8s.io/kube-proxy@sha256:22535649599e9f22b1b857afcbd9a8b36be238b2b3ea68e47f60bedcea48cd3b        13 hours ago        Running             kube-proxy          0                   90179e9aaf2f6       kube-proxy-mb9f7

root@worker1:~# crictl inspect 8a6b6f7 | grep "pid"
    "pid": 16120,
    
root@worker1:~# find /sys/fs/cgroup -name cgroup.procs -exec grep -H 16120 {} \\;
/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod10e59c76_03e0_447b_bbc0_d66f7ffe0583.slice/crio-8a6b6f7c79ece337d02b1ebdf1fe7984d18c2bb829aa2c75cfed19e18e166fbc.scope/container/cgroup.procs:16120

root@worker1:~# cd /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod10e59c76_03e0_447b_bbc0_d66f7ffe0583.slice/crio-8a6b6f7c79ece337d02b1ebdf1fe7984d18c2bb829aa2c75cfed19e18e166fbc.scope
root@worker1:/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod10e59c76_03e0_447b_bbc0_d66f7ffe0583.slice/crio-8a6b6f7c79ece337d02b1ebdf1fe7984d18c2bb829aa2c75cfed19e18e166fbc.scope# cat cpu.weight
10

우리가 계산한 9.6 + 1 = 10.6에 대한 10의 값이 정상적으로 출력되는 것을 확인할 수 있습니다.

혹시 모르니 resources.requests.cpu를 500m으로 설정하고 다시 확인해 봅시다.

root@master1:~/k8s/pods# cat a.yaml
apiVersion: v1
kind: Pod
metadata:
  name: a
  namespace: default
spec:
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
    resources:
      requests:
        cpu: 500m
  restartPolicy: Always
  nodeSelector:
    kubernetes.io/hostname: worker1
root@master1:~/k8s/pods# kubectl apply -f a.yaml
pod/a created
---
root@worker1:~# crictl ps
CONTAINER           IMAGE                                                                                                     CREATED             STATE               NAME                ATTEMPT             POD ID              POD
**1618ac0f6157d       27a71e19c95622dce4d60d4a3760707495c9875f5c5322c5bd535214799593ce                                          18 seconds ago      Running             busybox             0                   cfbb9f68873cf       a**
9f61aea39bdf1       registry.k8s.io/coredns/coredns@sha256:f0b8c589314ed010a0c326e987a52b50801f0145ac9b75423af1b5c66dbd6d50   13 hours ago        Running             coredns             0                   fb79be5137b43       coredns-7c65d6cfc9-k65k4
89986ea9962fa       registry.k8s.io/coredns/coredns@sha256:f0b8c589314ed010a0c326e987a52b50801f0145ac9b75423af1b5c66dbd6d50   13 hours ago        Running             coredns             0                   220bc9ce4e46f       coredns-7c65d6cfc9-hrx2k
f34df68b00d35       registry.k8s.io/kube-proxy@sha256:22535649599e9f22b1b857afcbd9a8b36be238b2b3ea68e47f60bedcea48cd3b        13 hours ago        Running             kube-proxy          0                   90179e9aaf2f6       kube-proxy-mb9f7

root@worker1:~# crictl inspect 1618ac0f | grep "pid"
    "pid": 16906,
            "type": "pid"
          "pids": {

root@worker1:~# find /sys/fs/cgroup -name cgroup.procs -exec grep -H 16906 {} \\;
/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod089ebf2e_1909_430e_aad6_14f1ff19455b.slice/crio-1618ac0f6157df7b07558d8507856af3a5707cb941ef923786bd8d09ba259b4b.scope/container/cgroup.procs:16906

root@worker1:~# cd /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod089ebf2e_1909_430e_aad6_14f1ff19455b.slice/crio-1618ac0f6157df7b07558d8507856af3a5707cb941ef923786bd8d09ba259b4b.scope
root@worker1:/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod089ebf2e_1909_430e_aad6_14f1ff19455b.slice/crio-1618ac0f6157df7b07558d8507856af3a5707cb941ef923786bd8d09ba259b4b.scope# cat cpu.weight
20
  • 예상값: 1 + 500 / 2048 * 79 = 20.28 ( 20 )
  • 실제값: 20
  • 450m → 18 (17.35 + 1)

이번 글의 대상이 아닌 독자

  • k8s는 왜 CPU를 압축 가능한 자원으로 보는가?
    • CPU Core에 대한 실행시간, 즉 스케줄링에 대해 가중치를 바탕으로 할당하기 때문에 탄력적으로 조절 가능하기 때문.
  • 쿠버네티스에서 CPU requests/limits는 어떤 의미인가?
    • CPU requests는 cpu weight을 기반으로 “상대적으로” 컨테이너가 보장받을 수 있는 최소 CPU 자원을 설정한다.
      • 예를 들어, 전체 가중치가 100일 때 두 애플리케이션에 각각 50의 가중치가 설정되면, 각 애플리케이션은 최소 50%의 CPU 시간을 보장받는다.
        • 하나의 애플리케이션만 존재할 경우, 우리가 알고 있는 스케줄링 정책과 같이 자원을 더 많이 사용할 수 있다.
      • 만약 50의 가중치를 가진 애플리케이션이 세 개 존재한다면, 피크 타임에 모두 50%의 CPU를 요청하여 병목 현상이 발생할 수 있다.
        • 하지만 쿠버네티스는 스케줄링 정책에서 세 번째 Pod를 Pending 상태로 유지한다.
    • CPU limits는 컨테이너가 사용할 수 있는 최대 CPU 시간을 의미한다. CPU 사용량은 이 limits을 초과할 수 없다.
    • 그렇기 때문에 쿠버네티스 환경에서는 CPU requests만 설정해도 충분한 경우가 많다.
      • 이는 전체 가중치 중 각 애플리케이션의 requests 비율에 따라 CPU 시간이 할당되기 때문이다.
      • 따라서 limits을 불필요하게 설정하여 애플리케이션에 인위적인 병목 현상을 만들 필요는 없다.
        • 어차피 각 비율에 따라 가질수 있는 최대 CPU 타임은 정해져있다.
  • 컨테이너의 CPU 사용률은 어떻게 측정되는가? ( by 천강진 님 )
/sys/fs/cgroup/C # cat cpu.stat
usage_usec 0     # CPU 총 사용 시간(마이크로초 단위)
user_usec 0      # 사용자 모드에서 실행된 시간
system_usec 0    # 커널 모드에서 실행된 시간

### 아래 값은 cpu.max에 MAX(QUOTA)가 설정된 경우 증가
nr_periods 0     # 스케줄러에 의해 CPU가 할당된 횟수
nr_throttled 0   # 사용 가능한 CPU 시간을 초과 또는 남은 시간이 부족하여 쓰로틀링에 걸린 횟수
throttled_usec 0 # 쓰로틀링 걸린 시간

### 아래 값은 cpu.max.burst가 설정된 경우 증가
nr_bursts 0      # CPU 버스트 모드로 전환된 횟수
burst_usec 0     # 버스트 모드에서 사용한 시간
last_cpu_usage_us = [cpu.stat의 usage_usec]
last_time_us = [현재 시간 마이크로초]

N초 휴식

curr_cpu_usage_us = [cpu.stat의 usage_usec]
curr_time_us = [현재 시간 마이크로초]

delta_cpu_usage_us = curr_cpu_usage_us - last_cpu_usage_us
delta_time_us = curr_time_us - last_time_us

print(f"CPU 사용률: {delta_cpu_usage_us / delta_time_us * 100:.2f}%")
  • CPU 사용률이 100%가 아닌데 왜 throttled 상태가 되는가?
    • cpu.max에 설정된 CPU 시간을 초과할 수 있기 때문
  • 일정량의 RPS 또는 TPS가 목표일 때, 내 어플리케이션에 적용해야할 CPU 값은 어떻게 알 수 있는가?
    • 성능 테스트를 통해 CPU 자원 사용량을 계산해야 한 뒤, 목표 값에 도달하기 위해 얼마나 필요할지 예측할 수 있다.
    • 예를 들어 1350 RPS가 목표이고, 1000 RPS (TPS)를 처리할 때 0.5 vCPU가 사용되었다면 0.675 vCPU가 필요한 것을 알 수 있다. ( 1350 / 1000 ) * 0.5
    • 실제 vCPU를 할당할 때는 이보다 넉넉하게 할당하도록 하자.
  • k8s에서 CPU와 관련된 추가 기능은 무엇이 나올 수 있을까?
    • 자식 프로세스와 관련된 기능 ?
      • address space를 공유할 수 있을것 같고
      • CPU의 근본적인 것에 가까워지는 느낌이라, 부모 - 자식 process…….
  • 컨테이너 환경은 CPU 활용에 있어 어떤 문제가 있는가?
    • Host OS를 이용한다는 점
      • 가상 머신의 경우 일반적으로 하드웨어적으로 격리된 자원을 보장받지만
      • 컨테이너는 그렇지 않기 때문에 발생할 수 있는
      • 자원 이슈
  • 7번의 문제는 특정 애플리케이션을 컨테이너로 올리는데 문제가 되는가?
    • Host OS에 영향을 줄 수 있는 만큼의 연산을 필요로 하는 애플리케이션
      • 우리가 자원량을 설정하지 않는다면 문제가 되지 않을까?

참고

안녕하세요, 짧은머리 개발자입니다.

클라우드는 보안이 매우 중요한 환경인데요, 오늘은 Google Cloud Platform에서 관리중인 여러 프로젝트간 서비스 접근을 어떻게 구성하는지 공유하려 해요.

클라우드는 서비스로 제공하는 XaaS에 대한 접근을 제어할 수 있도록 IAM을 제공하는데 AWS, GCP와 같은 거대 클라우드는 IAM Role for Service Account(IRSA)라 불리는 메커니즘을 통해 더 세밀한 제어를 가능하게 해요.

이름에서 유추할 수 있듯이 서비스 계정을 위한 IAM 역할을 부여함으로써 그 메커니즘이 동작해요.

GCP의 서비스에 등록된 Service Account는 구글의 메타데이터 서버를 통해 자격 증명에 접근하고, 필요한 토큰을 관리해요.

  • 이전에 작성한 Github과 같이 GCP 외부에서 접근하는 경우에는 Security Token Services를 통해 단기 자격을 증명해주는 토큰을 발급받아야 하고, 이 때 roles/iam.serviceAccountTokenCreator과 같은 역할이 추가로 필요해요.

GCP는 구조를 계정 수준 리소스부터 서비스 수준 리소스로 나누어 관리할 수 있는데, 베스트 프랙티스로 GCP 내부에 생성할 그 구조를 회사의 조직 구조와 일치하게 만드는 것을 권장해요.

https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy?hl=ko

이는 곧 분리되어 있는 프로젝트 간 배포된 서비스간 접근을 허용해야 하는 경우가 발생할 수 있어요.

제가 수행했던 프로젝트의 경우에도 분리되어있는 프로젝트간 버킷에 접근해야 할 필요가 있었는데요, 이를 어떻게 구성했는지 공유하려 해요.

프로젝트 구성

프로젝트 구성은 위와 같은 형태로, Project A에서 동작중인 Application A는 Project B의 Bucket B의 오브젝트에 접근할 수 있어야 하며, Bucket B는 Private하며 IAM을 통해 접근을 제한하고 있어요.

이를 해결하기 위해 우리는 싱글 프로젝트와 같이 Project A의 Application A에 서비스 계정을 추가한 뒤, Project B의 IAM을 구성해줘야 해요.

이 때 Project B에서 bucket-sa@project-a.iam.gserviceaccount.com 서비스 계정이 가져야할 역할은 다음과 같아요.

  • Bucket B에서 행할 작업에 따른 Storage 접근 권한, roles/storage.objectViewer
💡 roles/iam.serviceAccountUser의 경우, 특정 사용자 혹은 서비스 계정이
bucket-sa와 같이 IAM 역할을 갖는 서비스 계정으로 가장(impersonate)해야 할 때 필요해요.
이 경우에는 Application에 부착된 서비스 계정이 직접적으로 사용하기 때문에 필요하지 않아요.

 

여기까지 수행하고 나면 RBAC이 구성되고, Application A에서 Bucket B에 정상적으로 접근할 수 있어요.

그런데 만약 Project B에 Bucket B 말고 여러 버킷이 존재한다며면, bucket-sa 서비스 계정을 이용해서 모든 버킷에 접근 가능하게 돼요. 이는 보안상 매우 취약한 설정이며, 따라서 Attribute Based Access Control(ABAC)을 구성해야 해요.


ABAC은 이름에서 유추할 수 있듯 속성 기반의 접근 제어 메커니즘이에요. 기존의 bucket-sa 서비스 계정은 역할을 기반으로 Bucket B에 접근 가능하도록 구성했다면, 여기에 속성을 추가하여 더 세밀한 제어를 할 수 있어요.

우리에게 필요한 세밀한 제어는 다음과 같아요.

  • Bucket B에 접근할 수 있어야 한다.
  • Bucket B 내부의 오브젝트를 볼 수 있어야 한다.
  • Bucket B 내부의 디렉토리 구조를 볼 수 있어야 한다.

이를 해결하기 위해 GCP는 IAM 역할에 조건을 설정할 수 있고, 역할의 조건에 필요한 리소스 유형과 리소스 이름은 다음 링크에서 확인할 수 있어요.

우리에게 필요한 속성을 정리하면 다음과 같아요.

# 허용할 서비스 계정
member = "bucket-sa@project-a.iam.gserviceaccount.com"

# 허용할 역할
roles = [
  "roles/storage.objectViewer",
]

# 역할 + 대상 = 서비스 계정이 접근할 수 있는 대상
target_resources = [
  # 버킷의 이름이 bucket-b와 같아야 한다.
  {
    type   = "storage.googleapis.com/Bucket",
    name   = "projects/_/buckets/bucket-b"
    option = "equal"
  },
  # 접근하고자 하는 오브젝트는 bucket-b의 objects여야 한다.
  {
    type = "storage.googleapis.com/Object",
    name   = "projects/_/buckets/bucket-b/objects/"
    option = "startsWith"
  },
  # 접근하고자 하는 폴더는 bucket-b의 관리형 폴더여야 한다.
  {
    type = "storage.googleapis.com/ManagedFolder",
    name   = "projects/_/buckets/bucket-b/managedFolders/"
    option = "startsWith"
  }
]

버킷 뿐만 아니라 다른 XaaS에 대한 접근이 필요할 때도 위와 같이 서비스 계정을 구성한다면 프로젝트간 IRSA를 구성할 수 있어요.

오늘도 읽어주셔서 감사합니다.

'DevOps > Cloud' 카테고리의 다른 글

GKE와 Cloud Load Balancing 연결하기  (1) 2024.07.15

안녕하세요, 짧은머리 개발자에요.

제가 근무하고 있는 회사는 Google Cloud Platform을 이용하여 서비스를 운영하고 있어요. 특히 컨테이너의 시대인 만큼 Google Kubernetes Engine을 이용하여 컨테이너를 관리하고 있는데요, 오늘은 처음 GKE를 도입하면서 GCP의 Cloud Load Balancer를 연동하며 했던 고민을 공유하려 해요.


먼저 GCP는 관리중인 서비스를 외부 혹은 내부에서 접근할 수 있도록 Cload Load Balancing이라는 명칭의 PaaS를 제공하고 있어요. CLB라고 불리는 이 서비스는 GCP에 배포된 서비스들에 고성능 부하 분산 기능을 제공하는 역할을 해요. AWS에는 ALB(NLB)라는 솔루션이 있어요.

우리 회사가 GKE에서 운영중인 서비스들에 대해 외부에서 접근할 수 있도록 하는것이 목표였는데요, GCP에서는 일반적으로 GKE의 외부 노출을 위해 다음의 솔루션을 제공해요.

  1. 쿠버네티스 게이트웨이 API를 이용한 외부 노출
  2. 쿠버네티스 인그레스를 이용한 외부 노출
  3. 서비스 + CLB 직접 관리를 통한 외부 노출

우리 회사가 선택한 방법은 3번인데, 그 이유는 다음과 같아요.

  1. Load Balancer의 직접 관리를 통해 보다 폭 넓은 제어가 필요하다.
  • 2번의 경우 CLB가 자동으로 생성, 관리되는데 이 경우 직접적인 제어가 까다로웠어요. 특히 인그레스 혹은 게이트웨이를 생성할 때 마다 CLB가 생성되는데, 이는 불필요한 CLB의 증가로 인해 관리가 복잡해지고 비용이 늘어나는 원인이 되기도 했어요.
  1. SSL에 대한 폭 넓은 제어가 필요하다.1, 2번의 경우 인그레스, 게이트웨이가 늘어날 때 마다 해당 요청을 처리하는 도메인에 대한 SSL을 명시해 주고 관리해야 하는데 이것은 불필요한 관리를 유발했어요.
  • 특히 초기의 경우 도메인에 대한 asterisk를 SSL에 등록하지 않고, 우리 회사에서 사용하는 도메인들에 대해 SSL을 발급, 관리했는데 이는 매우 까다로운 절차였어요.
  • 인증서를 관리하기 위해 Google Certificates Manager를 이용하고 있어요. 문제는 DevOps 관점에서 SSL의 변경 혹은 추가가 일어날 때, Terraform을 이용한 생성 및 CLB 할당에서 인증서 관리를 마무리 하고 싶었어요.
  1. L7 뿐만 아니라 L4에 대한 트래픽 제어도 필요하다.
  • 블록체인을 운영하는 회사로서 노드에 대한 RPC 통신을 지원해야 했기 때문에 CLB를 통한 직접적인 관리가 필요했어요.
  1. 회사의 규모가 크지 않은만큼 필요한 수의 CLB만 유지하고 싶었어요.
  • GCP의 CLB는 고가용성을 제공하는 만큼 증가하는 트래픽에 대한 CLB를 분리하여 운영할 필요가 없었기에, 필요한 CLB의 숫자만 유지하고 싶었어요.

GCP에서는 최종적으로 GKE의 서비스에 접근하기 위해 GCP Backend Service와 Network Endpoint Group을 이용해야 해요.

GCP는 이를 지원하기 위해 AutoNeg 쿠버네티스 오퍼레이터를 제공하고 있어요. 이를 통해 쿠버네티스에 배포된 서비스를 바탕으로 GCP Backend Service와 Network Endpoint Group을 생성해 줘요.

이를 위해 쿠버네티스 서비스를 생성할 때 다음의 예시처럼 Backend Service와 NEG에 필요한 정보를 어노테이션에 담아 생성해야 해요.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "nginx-neg-svc"}}}'
  name: nginx-neg-test
  namespace: devops
  labels:
    app: nginx-neg-test
spec:
  ports:
    - port: 80
      protocol: TCP
  selector:
    app: nginx

이처럼 서비스에 AutoNeg를 통해 GKE와 CLB를 융합하며 운영했을 때 다음의 큰 문제가 발생했어요.

  • GKE 서비스를 배포할 때, Network Endpoint Group이 생성되는 Zone을 명시할 수 없다.
    • 특히 이는 AWS의 EKS의 경우 AWS Load Balancer Controller와 Target Group Binding 그리고 리스너를 통해 배포되어 있는 EKS Pod에 대한 외부 노출이 가능한데 이에 대해 한번에 지원되지 않는게 의아했어요.

이는 Pod의 Spec이 변경될 때 마다 NEG 위치가 변하는 이슈가 있었고, CLB에서는 변경된 NEG로 다시 설정해 줘야 트래픽의 정상적인 처리가 가능했어요. 즉 Downtime이 발생할 수 있는 위험성을 가지고 있어요.

NEG이 하나만 생성된 모습

이를 해결하기 위해 GCP의 GKE 외부 노출 방법중 Ingress를 이용하여 애플리케이션을 외부로 노출해 봤어요.

# nginx.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: devops
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-neg-test
  namespace: devops
  labels:
    app: nginx-neg-test
spec:
  ports:
    - port: 80
      protocol: TCP
  selector:
    app: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: devops
spec:
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: nginx-neg-test
                port:
                  number: 80
가능한 모든 zone에 NEG이 생성된 모습

이 경우 AutoNeg과는 다르게 Ingress로 배포한 서비스는 자동으로 현재 GKE가 배포되어 있는 Region 내의 모든 Zone에 대해 Network Endpoint Groups를 배포하는 것을 확인했고, 머리속에서 이거다! 하는 생각이 떠올랐어요.

GCP의 AutoNeg의 경우 배포되는 Service가 사용할 Network Endpoint Groud에 대해 다음의 규칙을 지키면 이미 생성된 NEG을 활용해요.

💡 Note
Updating NEG description is impossible, so this only works if the NEG is used for populating endpoints from a specific set: [Cluster, service name, namespace, port] which does not change.


그래서 저는 AWS의 ALB Controller + Target Group Binding 노하우를 활용하여 다음과 같이 GKE 애플리케이션 외부 노출 정책을 결정했답니다.

  1. 인프라에 배포할 애플리케이션 요구사항에 맞춰 CLB, Backend Service, Network Endpoint Group을 먼저 생성한다.
  1. Backend Services를 생성하며 생성된 NEG을 연결한다.
  • AutoNeg를 이용하여 서비스를 배포할 때 Backend Service와 NEG의 이름을 명시적으로 사용할 수 있어요.
  • 이를 적용하기 위해 Backend Service를 생성할 때 쿠버네티스 서비스에 명시할 이름을 스펙으로 설정해야 해요.

3. 쿠버네티스 서비스 배포시 Backend Service를 생성한 스펙을 바탕으로 AutoNeg Annotation을 설정하여 배포한다.

이렇게 할 경우 Pod가 재배포 되면서 스펙에 변경사항이 발생되더라도 자동으로 AutoNeg이 서비스를 검사하여 GCP의 NEG과 Backend Service에 해당하는 서비스를 연결하는것을 확인했고 Downtime 없이 Application을 배포할 수 있었어요.

'DevOps > Cloud' 카테고리의 다른 글

GCP Multi Project에 대한 IRSA 구성하기  (0) 2024.09.03

+ Recent posts