개요

- Kubernetes 클러스터제어 플레인작업자 노드로 구성된다.

- Control Plane Components는 클러스터의 상태를 관리하고, Node Components는 Pod와 컨테이너의 실행을 유지 관리한다.

- 애드온은 Kubernetes의 기능을 확장하며, 다양한 클러스터 관리와 모니터링 기능을 제공한다.

- Kubernetes는 다양한 환경에 맞게 아키텍처를 유연하게 조정할 수 있다.

 

1. 🗂️ Kubernetes의 핵심 구성 요소

  • Kubernetes 클러스터제어 플레인과 하나 이상의 작업자 노드(worker nodes)로 구성된다.
  • 제어 플레인(control plane)은 클러스터의 전반적인 상태를 관리하고 조정하는 역할을 한다.
  • 워커 노드Pod를 실행하고, 컨테이너의 실제 작업을 수행한다.
  • Pod는 Kubernetes에서 실행되는 기본적인 배포 단위이며, 하나 이상의 컨테이너를 포함할 수 있다.
  • 클러스터의 각 구성 요소는 서로 상호작용하며, 이를 통해 클라우드 환경에서의 컨테이너 오케스트레이션을 가능하게 한다.

-> 컨트롤 플레인은 노드들을 관리하고 실제로 파드가 작동 되는 곳은 노드(워커 노드) 이다.

2. 🗝️ Kubernetes의 Control Plane과 Node 구성 요소

  • Control Plane Components는 클러스터 전체 상태를 관리한다. 그래서 Kubernetes HTTP API를 제공하는 핵심 서버가 포함된다.
  • 모든 API 서버 데이터를 위한 일관적이고, 고가용성의 키-값 저장소(ETCD <- 매우 중요!!!)를 가진다.
  • 아직 노드에 할당되지 않은 Pod를 찾아 적합한 노드에 할당한다. 그래서 Kubernetes API 동작을 구현한다.
  • Node Components는 모든 노드에서 실행되며, 실행 중인 Pod와 Kubernetes 런타임 환경을 유지관리한다.
  • Pod가 실행 중인지 확인하고, 그들의 컨테이너도 포함된다.
  • 네트워크 규칙을 노드에서 유지하여 Kubernetes 동작을 구현한다.
  • 컨테이너 실행을 책임지는 소프트웨어가 필요하다. 그래서 추가 소프트웨어가 각 노드에 필요할 수 있다. 예를 들어, 로컬 구성 요소를 감독하기 위해 Linux 노드에서도 실행될 수 있다.

-> 위 내용과 반복되는 내용

3. 🌟 Kubernetes의 기능을 확장하는 애드온

  • 애드온(Addons)은 Kubernetes의 기능을 확장한다.
  • 클러스터 전반의 DNS 이름풀이를 제공한다.
  • 웹 인터페이스를 통한 클러스터 관리가 가능하다.
  • 컨테이너 메트릭스 수집 및 저장을 지원한다.
  • 컨테이너 로그를 중앙 로그 저장소에 저장한다.
  • 🔧 유연한 아키텍처
    • Kubernetes는 구성 요소를 배포하고 관리하는 방식에서 유연성을 제공한다.
    • 소규모 개발 환경부터 대규모 프로덕션 배포까지 다양한 요구에 맞게 아키텍처를 조정할 수 있다.
    • 각 구성 요소에 대한 자세한 정보와 다양한 구성 방법은 추가 학습이 필요하다.

-> 쿠버네티스는 addon들을 통해서 기능을 확장할 수 있고, 확장에 용이하다. 

 

 

ref

Kubernetes Components | Kubernetes

 


216. IP Address Management - Weave

브릿지 네트워크가 ip를 어떻게 할당하는지?

 

CNI 규칙에 파드는 ip 를 무조건 할당되어야한다.

명령어에 ip를 할당하는 내용이 들어있다. 

쿠버네티스는 ip를 어떻게 할당하는지 관심 없다. 그저 ip 가 겹치지 않으면 된다. 

ip를 파일로 관리한다. 

당연히 수동으로 하는 대신 cni 플러그인을 사용하면 된다.

이건 로컬 플러그인 방식이다. 

cat /etc/cni/net.d/net-script.conf 

파일에 어느 ipam 플러그인을 사용할지 정의한다. 

 

weaveworks 인 경우

수 많은 ip를 할당해서 이용할 수 있다. 공평하게 세개씩 분배한다? 

 


217. Practice Test - Networking Weave

1. How many Nodes are part of this cluster?

Including master and worker nodes

2개

 

2. What is the Networking Solution used by this cluster?

weave

 

3. How many weave agents/peers are deployed in this cluster?

2개

 

4. On which nodes are the weave peers present?

k ged pod -o wide 옵션으로 node 여부도 확인가능

a모든 노드마다 하나.

 

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

 

weave

 

6. What is the POD IP address range configured by weave?

ipalloc 부분

7. What is the default gateway configured on the PODs scheduled on node01?

What is the default gateway configured on the PODs scheduled on node01

 

weave 는 10.244.0.0/16


219. Service Networking

 

노드와 여러 파드들이 있다고 가정

주황 파드에서 파랑 파드 접속 가능하도록 서비스를 생성했다.

orange-service 10.99.13.178

파랑 파드는 서비스 이름이나 ip를 이용해서 주황 파드에 접속할 수 있다.

서비스를 생성하면 클러스터에 걸쳐서 생성된다.

클러스터 내에서만 사용 가능하다. 

Cluster IP

클러스터 안에서만 사용할 수 있는 서비스가 cluster ip 이다. 

NodePort

보라 파드에서 서비스를 만들자. 클러스터 ip 처럼 모든 클러스터에 걸쳐 생성되면 사용 가능하다.

대신 외부 포트에서 접근 가능하다. 

외부 유저는 어플리케이션에 접속 가능하다.

 

서비스 원리를 이해하기 위해 처음부터 시작해보자

모든 노드는 kubelet 을 갖는다. (파드 생성과 연관 )

kubelet은 kubeapiserver 와 통신하며

그리고 파드를 생성한다. 

그리고 cni 플러그인을 통해 네트워크 환경 구성을 한다. 

kubelet 과 같이 kube-proxy 도 노드마다 존재한다.

kubeapiserver 와 통신하면서 변경 사항을 체크한다.

서비스가 생성되는 경우

파드와 다르게 서비스는 모든 노드에 생성되지 않는다.

서비스는 클러스터 와이드 컨셉이다.

모든 노드에 걸쳐서 존재한다.

실제로 서비스는 존재하지 않는다.

서버도, 서비스도 없다. 

서비스는 ip나 인터페이스 할당이 없다. 네임스페이스도 없다. 

 

가상의 객체이다. 

그럼 어떻게 ip를 얻고 서비스에 접근할 수 있는 걸까?

 

서비스를 생성하면 쿠버네티스에서 미리 정해 놓은 ip 범위에서 할당 받는다.

kube-proxy가 선점된 ip를 받은 후 포워딩 규칙을 생성한다.

서비스 ip 10.99.13.178 로 갈려면 파드 ip 10.244.1.2 로 향한다.

실제로는 ip와 포트 조합으로 한다. 

서비스가 생성되면 kube-proxy 가 해당 규칙을 추가한다. 

 

이런 규칙은 어떻게 생성될까?

kube-proxy는 여러 옵션이 있다. 

pod 가 있고 서비스를 확인  10.244.1.2

10.103.132.104

서비스 ip 범위는 미리 정해져있다. 

ps aux | grep kube-api-server 로 확인

10.96.0.0/12 

ip 범위는 겹치면 안된다. 파드 범위는 10.244.0.0/16 이므로 10.244.255.255 까지 

서비스용 ip 범위는 10.96.0.0~10.111.255.255 다행히 안 겹친다. 

iptables -L -t nat 명령어로 규칙 확인 가능

db-service 의 iptables를 보면 10.103.132.104:3306 으로 들어오는 트래픽을 10.244.1.2:3306  으로 보낸다. 

 

kube-proxy-log 로 확인 가능 

 


220. Practice Test - Service Networking

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

k get nodes -0 wide 로 internal ip 확인 192.4.125.9 

ip link 로 확인 192.4.125.9 인터페이스 eth0 확인

192.4.125.0/24

 

2. what is the range of IP addresses configured for PODs on this cluster?

모든 파드 확인 후 

weave-net 로그를 이용해서 찾자

ipalloc-range: 10.244.0.0/16

 

3. what is the IP Range configured for the services within the cluster

kube-api-server에 나와있다.

servicecluster ip range 10.96.0.0/12

 

4.  How many kube-proxy pods are deployed in this cluster

 

2개

 

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

k logs -n kube-system kube-proxy-59qn5  로그에 유형이 있다. 

iptables

 

6. How does this kubernets cluster ensure that a kube-proxy pod runs on all nodes in the cluster ?

 

inspect the kube-proxy pods and try to identify how they are deployed.

 

데몬셋이 돌고 있다.

using daemonset 


196. Networking - Section Introduction

이번 챕터는 배워야하는 선수 지식이 좀 많다.

 

 

198. Prerequisite - Switching Routing

네트워킹 파트를 공부하는데 있어 필요한 선수지식

Switcing, routing, dns, network namespace, docker networking 

 

Switching

두개의 호스트를 연결할려면 무엇이 필요할까? 

스위치에 연결해야한다. 스위치에 연결하기 위해선 각 호스트 인터페이스가 필요하다. 

ip link 명령어로 인터페이스를 확인할 수 있다.

eth0 라는 인터페이스를 사용한다.

스위치의 ip 주소가 192.168.1.0 이라고 가정하고 

ip addr add 로 호스트에 ip를 할당해보자

호스트 a 가 b로 ping 을 날리면 통신이 된다. 

Routing

비슷한 다른 네트워크 통신할려면 어떻해야할까?

192.168.1.11 에서 192.168.2.10 으로 통신할려면?

두 네트워크를 잇기 위해서 라우터를 사용한다. 

라우터도 마찬가지로 두 네트워크에 ip를 할당한다.

192.168.1.1과 192.168.2.1

b에서 c 로 패킷을 보내려고 할때 라우터의 위치는 어떻게 알까?

라우터는 네트워크에 있는 또 다른 디바이스로 인식된다. 어떻게 구분하는가

 

Gateway

 

게이트웨이가 있어야 외부 네트워크로 나갈 수 있다. 

 

호스트 b 에서 routes 명령을 해도 아무런 정보가 없다.

게이트웨이가 구성 안된 상태라서 외부에 접속 할 수 없다.

route 를 추가해줘야한다.  

2번 네트워크 스위치 ip 192.168.2.0 을   네트워크  1 라우터 ip 192.168.1.1 을 통해

(라우터를 등록하는 과정)

 

라우터가 등록되었다.

 

네트워크 2 에서 네트워크 1에 접속하고 싶으면 마찬가지로 라우터를 등록해야한다.

다른 네트워크로 가고 싶을때마다 라우터에 등록해야한다면 엄청나게 복잡할 것이다.

그대신

라우터가 인터넷 게이트웨이를 가졌다고 생각하고 default 라우터로 지정한다. 

default 대신에 0.0.0.0 로 표기해도 된다.

모든 네트워크를 의미

만약 네트워크 2에서 네트워크1 로 가는 라우터, 외부 인터넷 접속을 하는 라우터를 분리하고 싶다면

 

192.168.1.0 으로 가능 라우터 하나

0.0.0.0 외부로 가능 라우터 하나 

두개를 등록한다.

a,b,c 호스트가 있고 

a,b 같은 스위치 b,c 같은 스위치에 있다.

스위치로부터 ip를 부여받고 

b는 두개의 ip를 배정받는다. 

a가 c 와 통신하고 싶다면 어떻해야하는가?

 

호스트a 192.168.1.5 에서 ping 을 날려보자 

192.168.2.5 로 보내면 접속불가이다.

라우터가 없기 때문에 어떻게 가는지 모른다. 

먼저 호스트 a에서 route를 추가한다.

 192.168.2.0 스위치로 가는 라우터는 192.168.1.6 

a에서 c로 패킷을 보내고 c 가 응답을 하기 위해 

마찬가지로 192.168.1.0 네트워크로 가기 위해 192.168.2.6 네트워크에 연결한다. 

이제 호스트 a에서 ping은 보내지지만 응답이 없다? 

 

By default, in Linux, packets are not forwarded from one interface to the next.

 

다른 인터페이스끼리 한번에 패킷이 전달 되지 않는다고 한다. ( 리눅스 보안 때문?)

호스트 b 는 eth0, eth1 두개의 인터페이스를 가지고 있다. 

cat /proc/sys/net/ipv4/ip_forward 를 실행하면 0 의 값을 가진다.

해당 값을 1로 바꾼다. 

이제 다른 인터페이스라도 패킷 전달이 가능해진다.

ping 응답 가능

리부트하면 초기화 되기 때문에 /etc/sysctl.conf 로 가서 값을 변경하면 값이 유지된다.

 

명령어 정리

 

ip link - 인터페이스 확인

ip addr add - ip 할당하기

ip route - 라우터 확인하기

ip route add - 라우터 추가하기

cat /proc/sys/net/ipv4/ip_forward - 다른 인터페이스끼리 패킷 전달 허용 

 


199. Prerequisite - DNS

호스트 a와 호스트 b 가 있다. 

a에서 ping 날리면 응답이 오지만 호스트 네임 db 로 지정하고 보내면 모른다.

etc/hosts 파일에 192.168.1.11 은 db 라고 등록하고 ping db를 날리면 응답이 온다.

문제는 여기서 정한 이름이 호스트 a에서만 정해진 약속이라는 점

b의 호스트 네임을 변경해도 여전히 db 에 접속하능하고 

google.com 이름으로 정해도 핑이 보내진다.

 

Name Resolution

이름을 함부로 정한 것을 name Resolution 이라고 한다. 

호스트 c 가 추가된다면 etc/hosts 파일을 세번 수정해야한다. 

호스트가 많이 추가되면 지옥이다.

하나의 ip가 변경되면 변경을 수도 없이 해야한다.

모든 호스트의 etc/hosts 를 수정하는 것이 아닌 해당 역할을 중앙에서 처리하는 하나의 서버에 위임한다.

DNS

이제 모든 호스트이 dns 서버에 접속한다!

대신 모든 호스트의 /etc/resolv.cof 파일에 nameserver 정보가 담긴다.

pind db로 핑을 날릴 수도 있다. 

 

이제 /etc/hosts 파일을 일일히 수정할 필요없다. 

test 용 서버를 두고 싶을때 하나의 호스트의 etc/hosts 파일만 수정하고 해당 호스트에서만 접속하게 한다. 

이런 용도도 있다.

 

이름이 중첩됬을때는?

호스트 a 에 192.168.1.115 를 test로 

dns 서버에 192.168.1.116 이 test로 

같은 이름인 경우에는...

먼저 local  을 선택하고 접속이 불가하면 dns의 경로로 간다. 

우선 순위를 바꾸고 싶다면

/etc/nsswithc.conf 를 수정한다.

files 는 로컬 dns

순서를 바꾸면 dns 먼저 탐색하게 할 수 있다. 

etc/hosts, nameserver 둘 다 없는 도메인을 입력하면 접속 실패가 뜬다. 

.8nameserver 에 구글이 운영하는 공용 네임서버 8.8.8.8 에 등록하거나 

dns 서버에 forward all t0 8.8.8.8 을 입력하여 외부로 보낼 수 있다.

이제 외부로 갈 수 있다.

Domain Names

top level domain

맨 뒤에 오는 거 

 

google 앞에 오는 www, drive , email 이런 건 서브 도메인이라고 한다.

apps.google.com 을 접속한다고 가정하면

먼저 local dns는 google이 뭔지도 모른다. 

. root DNS 로 접근한다. 

.com 등의 탑 레벨 도메인으로 간후 

google dns 로 간다. 

google dns 에서 apps 가 누군지 확인하면 216.58.221.78 의 ip 주소가 나온다. 

해당 주소를 로컬 캐시에 저장하고  다음번 접속시 저장된 ip를 사용하여 빠르게 접속한다. 

 

 Record Types

 

nslookup

 

nslookup은 로컬 etcd/hosts 파일을 확인하지 않는다. dns서버만 쿼리한다. 

ping 대신 lookup, dig 으로 통신 상태 확인 가능하다. 

 

 

dig


201. Prerequisite - Network Namespaces

 

리눅스 네트워크 네임스페이스에 대해 배워볼거다. 

집을 방으로 분리하듯이 호스트는 네임스페이스를 이용하여 격리시킨다.

컨테이너를 네임스페이스로 감싼다.

컨테이너 안에서 ps aux 

호스트에서 ps aux 에서

프로세스 root 를 똑같이 감시할 수 있으나 다른 프로세스 id를 갖는다. 

(호스트 관리자는 네임스페이스안의 프로세스도 볼 수 있다.)

 

Network Namespace

호스트가 lan 과 연결될때 routing 테이블 과 arp 테이블을 갖는다.

네임스페이스 안에 컨테이너를 생성

컨테이너를 라우팅 테이블에 대한 정보를 어떻게 알고 통신할까?

컨테이너도 가상 인터페이스와 라우팅, arp 테이블을 갖는다!

Create Network NS

in netns add  명령어로 netns 를 추가한다.

Exec in network ns

ip link 로 인터페이스를 확인 할 수 있다. 

netns 로 들어가서 인터페이스를 확인 할려면?

ip netns exec red ip link

ip -n red link

 

exec 으로 접속해서 확인하거나 -n 옵션으로 확인하거나

호스트에서는 인터페이스 두개 다 확인가능하고 

netns 로 들어가서 확인하면 한개만 확인가능하다.

 

arp 테이블을 확인할때도 마찬가지 

호스트에서는 다 확인가능하지만

netns 에선 해당 arp 만 확인가능

라우팅 테이블도 똑같다. 

 

두개의 netns 링크

다른 두개의 netns 인터페이스를 연결하고 싶다면 ? 

먼저 호스트에서 가상 인터페이스를 두개 만든다. 

ip link add veth-red type veth peer name veth-blue

veth 하나를 netns 로 옮긴다.

ip link set veth-red netns red

나머지 veth를 netns로 옮긴다.

ip link set veth-red netns blue

네임스페이스 인터페이스에 ip를 부여한다.

ip -n red addr add 192.168.15.1 dev veth-red

마지막으로 link set up 명령을 통해 인터페이스를 사용 가능하게 만든다 .

ip -n red link set veth-red

핑을 날리거나 arp 테이블을 확인할 수 있다.

호스트에서 arp 를 날리면 netns 의 arp, 인터페이스를 확인할 수 없다.

 

netns 가 여러개라면?

netns 가 여러개라면 위의 작업을 수동으로 하기 힘들 것이다.

대신 가상 스위치를 구성하는 것이 효율적이다. 

Virtual Switch 만들기

리눅스 브릿지, 오픈 스위치 등을 사용할 수 있다.

 

Linux Bridge

호스트에서 bridge 타입 가상 인터페이스를 만든다. 

ip link add v-net-0 type bridge

호스트에서 ip link 하면 인터페이스로 확인 가능하다. 

down 상태 

 

ip link set dev v-net-0 up 으로 인터페이스를 켠다. 

 

스위치에 모두 연결하기 전에 이전에 만든 link를 없애준다. 

ip -n red link del veth-red

인터페이스를 가상의 인터페이스와 링크한다.

ip link add veth-red type veth peer name veth-red-br

veth-red-br 은 이름만 존재

인터페이스를 netns 로 이동시키고

ip link set veth-red netns red

나머지 가상의 인터페이스를 가상 스위치에 설치한다.

ip link set veth-red-br master v-net-0

블루도 마찬가지

인터페이스에 ip를 부여한다.

ip -n red addr add 192.168.15.1 dev veth-red

마지막으로 인터페이스를 켠다

ip -n red link set veth-red up

 

4개의 host 다 연결되었다고 가정

호스트에서 netns red 의 ip 192.168.15.1 로 ping 때리면 안간다.

같은 네임스페이스가 아니기 때문

호스트에서 가상 스위치에 ip를 부여한다.

ip addr add 192.168.15.5/24 dev v-net-0

 

기존에 다른 netsns 에 ip를 부여했기 때문에 5번이 아닐까 싶네

스위치도 하나의 디바이스로 인식하기 때문에 ip를 가진다.

이제 호스트에서 red netns 로 ping 이 보내진다. 

가상 스위치로 라우팅 되서 가능한 것 같다.

해당 네트워크는 네임스페이스 안에 있기 때문에 외부로 접근할 수 없다.

외부로 나갈려면 호스트의 포트를 통해서 나가야한다.

외부의 192.168.1.3 으로 접속할려면 어떻게 해야 하는가

블루 netns 에서 192.168.1.3 에 접속해보자 

ip netns exec blue pin 192.168.1.3

라우트 명령으로 라우팅 확인해보자

ip netns exec blue route

가상 스위치로 가는 라우터만 가지고 있다.

네트워크 접속 불가라고 뜬다.

 

어떻게해야할까

가상 스위치에 연결된 가상 인터페이스가 호스트에 있는 또 다른 인터페이스라고 생각하면 된다. 

블루 netns 에서 192.168.1.3 으로 가능 라우터를 추가할려면 

ip netns exec blue ip route add 192.168.1.0/24 via 192.168.15.5 

라우터를 추가한다. 

스위치 192.168.1.0 으로 가는데 있어 가상 스위치 인터페이스의 ip는 게이트웨이가 되어준다. 

이제 블루 netns 에서 192.168.1.3 으로 ping 을 날리면 가지만 응답이 없다. 

(리눅스에선 다른 인터페이스끼리 한번에 패킷 전달이 안된다. ... 인 줄 알았으나...)

 

블루 netns 에선 192.168.1.3 까지 라우팅 경로를 알고 있으나 

192.168.1.3 입장에서는 어느 경로로 응답해야하는지 정보가 없다.

 

호스트에 

iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -j MASQUERADE 

를 추가한다.

해당 패킷을 받으면 호스트로부터 받은 패킷이라고 생각한다.(netns 로부터 온것이 아닌)

이제 응답을 받을 수 있다.

스위치가 인터넷과 연결되어있고

블루 netns 에서 8.8.8.8 로 접속할려고 하면 실패한다.

라우터 등록이 안되어있기 때문에

 

default 게이트웨이를 설정함으로써 해결할 수 있다.

외부 인터넷으로부터 응답을 받을 수 있다.

호스트에서 블루netns 로 핑을 보내면 가지만 외부 호스트 192.168.1.3 에서 보내면 접근 불가이다.

호스트에서 포트 포워딩 하는 방법이 있다.

ip tables -t nat -A PREROUTING --dport 80 --to-destination 192.168.15.2:80 -j DNAT 

+ Recent posts