Content Comparison

minLevel	1
maxLevel	7

...

1. 서비스

1.1 클러스터 외부 트래픽 받는 방법

Nodeport
Load Balancer
Ingress

1.2 서비스 개념

파드를 통해 사용자에게 서비스를 제공을 할 수 있으나, 파드에 장애가 발생했을 경우 서비스에 가용성을 보장할 수가 없기 때문에, Service를 통해 가용성을 보장합니다

...

이 서비스는 my-database라는 이름으로 정의되며, 실제로는 db.example.com에 대한 DNS 쿼리로 변환됩니다.
클러스터 내부의 애플리케이션에서 my-database라는 이름을 사용하여 외부의 db.example.com에 접근할 수 있습니다.

1.3 MetalLB 설치(Private 환경에서의 로드 밸런서)

(1) metallb 네임스페이스 생성

코드 블럭
[root@m-k8s vagrant]# kubectl create ns metallb-system

...

정보
Loadbalancer 타입으로 서비스를 생성해보고, External IP가 할당되었는지 확인해봅니다.

...

2. Ingress

2.1 Ingress Controller

인그레스 리소스를 해석하고, 이를 실제 네트워크 트래픽 관리로 변환하는 쿠버네티스 구성 요소입니다.
다양한 종류의 인그레스 컨트롤러가 존재하며, 각 컨트롤러는 특정 구현 및 기능을 제공합니다.

2.2 Ingress

클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리합니다.
인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출시킵니다.
인그레스 컨트롤러가 있어야 인그레스를 충족할 수 있으며, 인그레스 리소스만 생성한다면 효과가 없습니다.
- 대표적인 인그레스 컨트롤러: ingress-nginx

...

정보
ingress의 기능은 msa아키텍처에 많은 도움을 줄 수 있으며, 웹서버에 페이지 별로 다른 deploy나 pod그룹을 이용하여 효율적으로 자원을 분배하고 서비스를 배치 하여 관리 할 수 있습니다.

...

3. 파드 네트워크

참고) 문서 상 노드 이름 및 역할

sung-ubuntu01 - Control Plane #1

sung-ubuntu02 - Control Plane #2

sung-ubuntu03 - Control Plane #3

sung-ubuntu04 - Worker Node #1

sung-ubuntu05 - Worker Node #2

3.1 파드 네크워크

...

도커에서 POD 네트워크 설명할 경우와 인터페이스 이름이 다릅니다.
도커의 역할

참고1) https://www.docker.com/products/container-runtime/

3.2 단일 컨테이너 파드

Pod (Single Container)의 네트워크 설정을 확인합니다.

코드 블럭

root@sung-ubuntu01:~/tmp# cat ubuntu.yaml
apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-test
spec:
  containers:
  - name: ubuntu
    image: ubuntu:20.04
    command: ["/bin/sleep", "3650d"]
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}
  restartPolicy: Always
  dnsConfig:
    nameservers:
      - 8.8.8.8


root@sung-ubuntu01:~/tmp# kubectl get pod -o wide
NAME          READY   STATUS    RESTARTS   AGE     IP            NODE            NOMINATED NODE   READINESS GATES
ubuntu-test   1/1     Running   0          6m20s   10.233.99.1   sung-ubuntu04   <none>           <none>


###POD 접속
root@sung-ubuntu01:~/tmp# kubectl exec -it ubuntu-test -- bash
root@ubuntu-test:/#


root@ubuntu-test:/# 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=54 time=39.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=38.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=38.8 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=39.3 ms


# apt update
# apt install -y net-tools iputils-ping


**# 컨테이너의 네트워크 인터페이스 확인**
# root@ubuntu-test:/# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1480
        inet 10.233.99.1  netmask 255.255.255.255  broadcast 0.0.0.0
        ether 06:55:84:5a:ac:6b  txqueuelen 0  (Ethernet)
        RX packets 5718  bytes 24026416 (24.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3690  bytes 250168 (250.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



#설명추가
tunl0: flags=128<NOARP>  mtu 1480
        tunnel   txqueuelen 1000  (IPIP Tunnel)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


* loopback ip : host 자신을 가리키는 논리적인 인터페이스


**#노드 네트워크 확인**
root@sung-ubuntu04:~# ifconfig -a
...
tunl0: flags=193<UP,RUNNING,NOARP>  mtu 1480
        inet 10.233.99.0  netmask 255.255.255.255
        tunnel   txqueuelen 1000  (IPIP Tunnel)
        RX packets 60  bytes 8528 (8.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 66  bytes 4476 (4.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


*mtu 1480인 이유?
IPIP 터널을 사용하고 있기 때문에, 캡슐화된 패킷의 크기는 원래 패킷보다 더 크기 때문에 MTU 조절이 필요하다
1480인 이유는 캡슐화된 패킷이 Ethernet 패킷에 포함될 때 전체 크기가 1500을 초과하지 않도록 하기 위해서이다.

3.3 멀티 컨테이너 파드

Pod (Multi Container)의 네트워크 설정 확인을 확인합니다.

...

정보

리눅스 namespace

리눅스 커널에서 제공 기능으로 Container의 기반이 되는 기술. 하나의 시스템에서 프로세스를 격리시킬 수 있는 가상화 기술입니다.

3.4 파드 간 통신

Pod 간 route 경로 확인