Django가 고장날때까지

네트워크 스터디 4주차 본문

Docker 및 k8s

네트워크 스터디 4주차

Django가 고장날때까지 2024. 9. 29. 00:17
반응형



 


0. <지식의 흐름 >

 

지난주 calico cni 에 이어서, cluster ip, service, nodeport를 통해서 조금 더 구체적으로 쿠버네티스 pod간의 네트워크 통신에 대해서 살펴봤고, 별도로 설치한 cni가 해주는 역할이 아닌 kube-proxy(구성요소)가 실제적으로 iptable읕 통해서 커널단에서 해주는 역할에 대해서 구체적으로 살펴보게 되었다. 



 

1. 4주차 수업 듣기 전에 알아두면 좋은 개념

- 리눅스 커널

- iptable

- conntrack

- SNAT, DNAT

- L4 스위치

- /32 라우팅 /128 라우팅  # 3주차 개념 중복

 



- 리눅스 커널

 

리눅스 커널(Linux Kernel)은 리눅스 운영체제의 핵심 부분으로, 하드웨어와 소프트웨어를 연결하는 중요한 역할을 합니다. 



리눅스 커널의 개념을 알고 있어야지 이 내용이 다시 이해가 됨. 커널영역의 넷필터의 iptable이 네트워크를 통제함

 

 

iptables와 커널의 상호작용: iptables는 리눅스 커널의 네트워크 스택에서 동작하며, 패킷을 처리하기 위한 규칙과 테이블을 조작합니다. 즉, iptables커널 레벨에서 동작하므로, kube-proxy가 iptables 모드에서 네트워크 트래픽 라우팅을 수행할 때, 이는 커널 수준에서 패킷 처리 규칙을 설정하는 것입니다.

커널 수준 소프트웨어: 장치 드라이버와 운영체제의 특정 코드들이 모두 커널 소프트웨어의 일부라는 설명은 iptables와도 관련이 있습니다. iptables는 리눅스 환경에서 커널 소프트웨어의 일부로 동작하며, 네트워킹 규칙을 커널 레벨에서 변경함으로써 네트워크 트래픽을 처리하게 됩니다. 따라서 Kubernetes에서 kube-proxy가 iptables 모드를 사용할 때는 커널 코드를 통해 네트워크 패킷을 처리하는 것입니다.




- iptable 

 

각각의 노드 내에서 iptable 분산룰에 따라서 네트워크 패킷이 어디로 이동할지 결정되기 때문에 사전에 iptable에 대해 알고 있으면, 이해하기가 쉬움

 

iptabls -t nat -S

L3 네트워크 레이어 3계층 

 

L2도 존재

 

 

chatgpt 도움 받아서 제대로 해석해봄

 

 

 

 

 

 

 

 

 


(출처)

https://www.youtube.com/watch?v=5PnRdSO3CVo&t=629s



- NAT의 개념

 



 

SNAT, DNAT 확실하게 이해하고있어야됨. 정확하게 k8s랑 매핑되진 않지만, 이 개념이 활용됨


(출처)

https://www.youtube.com/watch?v=5PnRdSO3CVo&t=629s

 

 

src와 dst의 ip 정보가 nat에 의해서 변경됨
cluster-ip 통신흐름

 

 

 

https://hayz.tistory.com/entry/%EB%B2%88%EC%97%AD-Iptables-%EB%B0%8F-Netfilter-%EA%B5%AC%EC%A1%B0%EC%97%90-%EB%8C%80%ED%95%9C-%EC%8B%AC%EC%B8%B5%EB%B6%84%EC%84%9D


- L4 스위치

 

쿠버네티스에서 서비스를 만들면 기본적으로 endpoint가 만들어짐

 

 

cf) endpoints가 L4에 묶인 대상 포인트들을 관리해주는거임

 

마치 L4 서비스 가지고 있는 virtual IP처럼 동작함

 

 


- 10256 포트 in k8s

 

 

출처: https://kubernetes.io/docs/reference/networking/ports-and-protocols/



conntrack

 

 

 

conntrack -L --src 10.10.0.6


 

위의 명령어 활용해서 이 예시의 정보들을 확인해볼수 있음

 

 

/32(ipv4), /128(ipv6) 라우팅


/128 IPv6에서 특정 호스트(장치)로 트래픽을 보내는 데 사용되는 서브넷 마스크로, IPv4의 /32와 같은 개념입니다. 이는 네트워크에서 하나의 장치를 고정된 경로로 지정하고 그 장치만을 대상으로 트래픽을 전달하도록 라우팅하는 방식입니다.



Local 모드에서 Kubernetes는 이 개념을 사용하여, 서비스에 연결된 Pod가 있는 노드만이 /32와 같은 구체적인 경로를 광고함. 즉, 트래픽이 모든 노드를 거치지 않고 해당 Pod가 있는 노드로 직접 전달되도록 함. 이 방식은 성능을 높이고 불필요한 네트워크 홉을 줄여주는 역할을 함

 

https://blog.ipspace.net/2021/06/unnumbered-ethernet-interfaces/

 

https://docs.tigera.io/calico/latest/networking/configuring/advertise-service-ips#advertising-service-ips-quick-glance




2. 핵심내용   

Kubernetes  ClusterIP란?

 

 

 

 

서비스의 등장 배경 그렇기 때문에 파드가 중단되더라도 동일한 진입점의 서비스를 이용해서 안정적인 서비스를 이용할수 있게 됨


서비스가 또한 부하분산 기능도 제공함
부하 분산이 된다는 실습 예시l

 

Kubernetes 서비스란?

Kubernetes 서비스는 여러 **파드(Pod)**에 대한 접근을 하나의 네트워크 서비스로 추상화하여 제공하는 기능. 서비스가 제공하는 네트워크 연결은 다음과 같은 특징을 가짐

1. 레이블 셀렉터 (Label Selector)

  • 서비스는 레이블 셀렉터를 통해 특정 파드 그룹을 식별하고 관리
  • 선택된 파드 그룹에 대해 일관된 네트워크 접근을 제공

2. 가상 IP (Virtual IP)

  • 클러스터 내에서 서비스는 고정된 가상 IP를 사용하여 접근가능
  • kube-proxy는 파드 수에 관계없이 가상 IP를 통해 로드 밸런싱을 처리
  • 파드가 추가되거나 삭제되어도 DNS 이름과 가상 IP는 서비스의 수명 동안 변경되지 않음

 

Kubernetes 서비스의 종류

1. Cluster-ip의 경우

  •  클러스터 내부에서만 접근 가능한 가상 IP를 할당하여 서비스 간 통신을 가능하게 하는 기본 서비스 유형
  • iptable분산룰을 만들면 모든 노드에 동일하게 iptable 분산룰을 적용한다. 

 

 

 

2. NodePort

  • 클러스터의 모든 **노드(Node)**에서 특정 포트를 통해 외부 접근을 허용.
  • 일반적으로 포트 범위는 30000-32767 사이.

 

 

3. LoadBalancer

  • 클라우드 환경에서 주로 사용되는 방식으로, 로드 밸런서가 외부에 가상 IP를 제공하여 서비스에 접근 가능.
  • 외부 IP를 통해 클러스터 외부에서 손쉽게 서비스에 연결 가능.

추가 기능: 서비스 IP 광고 (Service IP Advertisement)

  • Calico와 같은 네트워크 플러그인을 사용하면, NodePort나 LoadBalancer 없이도 서비스 IP를 외부로 광고하여, 쉽게 외부에서 서비스에 접근 가능.  /32 /128 라우팅

 



# 실습 구성도

 

핑크색 박스 - 이 부분에 해당하는 것이 172.20.0.0/16 부분



172.18 번 대역대가 아닌 172.20번 대역

 

실습 때 사용한 기본 모드, 사용자 영역까지 가지않고 커널영역에서 처리함

 

 

 

Port: service-clusterip에 열려있는 포트

target Port: 서비스가 트래픽을 전달할 때 실제 Pod가 사용하는 포트. 이 포트는 서비스가 선택한 Pod에서 애플리케이션이 동작하는 포트(서비스에 연결된 대상 파드에 대한 포트)

 

port와 target port 다르다는 것 인지 필요

 

 

 

 



# kind 클러스터에서도 MulitCIDRServiceAllocator할 수 있게 설정해놓으셨다고, 테스트 해보라고 하셔서 테스트 해봄

- "MultiCIDRServiceAllocator": true

  • 설명: 이 기능 게이트는 서비스의 IP 주소 범위(CIDR)를 여러 개로 설정할 수 있는 기능을 활성화합니다. 기본적으로 Kubernetes는 하나의 CIDR 범위에서만 서비스 IP를 할당하지만, 이 기능을 활성화하면 여러 CIDR 범위에서 IP 주소를 할당할 수 있습니다. 이는 대규모 클러스터나 네트워크 구성이 복잡한 환경에서 유용함



https://kubernetes.io/docs/tasks/network/extend-service-ip-ranges/



 

MultiCIDRSrviceAllocator: true

mode: iptables

 

 

 

ClusterIP 타입의 경우 모든 노드에 동일한 iptable 룰이 적용되어 있고

Nodeport 타입의 경우 노드별로 port가 열려있기 때문에 어떤 노드로 접근해도됨

 

외부 클라이언트가 mypc를 가리킴

 

 

 

 

 

### topology aware hint 부분 <추가 실습> 

 

 

 

 

 

 

클라이언트 파드가 worker3 노드에 배포됨



# 디플로이먼트 파드가 배포된 노드 확인 : 각 노드는 AZ(zone) 별 배포되어 있음도 확인  

 

 

# 테스트 파드(netshoot-pod)에서 ClusterIP 접속 시 부하분산 확인  

 





 

  • 기존에 없던 hints 추가됨






3. 몰랐던 내용 정리  # 심화내용

1. iptable에 지정된 destination 포트가 시스템 소켓 내에서 열려잇는지 확인해보면, 예전 버전에서는 열려있었지만, 지금은(tcp 소켓) 열려 있지 않음  # cluster-ip는 원래 안나왔고, node-port는 나왔다가 안나옴

 

2. cluster-ip와 통신하다고 그게 라우팅 테이블에 추가되어 있는 것도 아님 -> 근데 어떻게 통신이 되냐 아까 위에서 살펴본것처럼 커널 단에서 netfilter framework 단에서 처리해버리니 조금더 상위단에서 처리를 해버린다고 생각하면 됨(라우팅 테이블에 없어서도 iptable에 존재하니까)

 

 

 

3. [Node-port]에서 접근 로그를 수집할때 SNAT이 되어 실제 접근한것은 172.20.0.100인데 -> 노드 ip가 기록에 남음

 

 

 

위에서 캡쳐한거는 강의에서 캡쳐한거랑서 대역대가 다름 172.20.0.3으로 이해하면됨

 

그렇기 때문에 정확한 client-ip 수집을 위해서 node port에서

 

이 개념이 나옴

 

 

4. [Node-port] 는 clusterip를 포함하기 때문에 clusterip와도 통신이 가능함

 

5. 백엔드 관점에서 인프라에서도 iptable 데이터에 일종의 정합성을 위해 이러한 작업이 이뤄진다는 점을 알게됨  # 스터디원 분 글 읽어보라고 하셔서

https://namejsjeongkr.tistory.com/6

 

KANS(Kubernetes Advanced Networking Study) - 4주차 정리

이번 주차는 Kuberentes 서비스 오브젝트에서 ClusterIP, NodePort라는 두 가지 유형에 대해 학습했습니다. (이 외에도 다양한 유형이 존재하는데, 해당 유형은 차주에 진행할 예정입니다.)   실습 환경

namejsjeongkr.tistory.com

 



4. 엔드포인트슬라이스 - 등장배경 및 개념

 

출처: https://montkim.com/kubernetes-network-development

반응형
Comments