[가시다님] PKOS (AWS kOps) - 2주차 (네트워크, 스토리지)

가시다님이 진행하시는 PKOS (Production Kubernetes Online Study) 2주차!

 

본 실습은 <24단계 실습으로 정복하는 쿠버네티스>를 기반으로 진행합니다.

 

이번에는 좀 이론적인 내용을 잡고 가려구 한다..

 

 

두드러지는게, 노드의 네트워크 대역과 파드의 네트워크 대역이 같은 것이다.

네트워크 통신의 최적화(성능, 지연)를 위해서 그렇다는데...!

 

Q) 그럼 온프렘에서는 왜 다르게 해둔거지? (향후 보완 필요)

가 아니라, 원래는 다른데 AWS에서는 뭔가 같게할 수 있는 방법이 있나본데?

-> 아, 이거 Azure에서도 비슷했는데......

 

Q) Azure CNI처럼 AWS도 그 단점을 그대로 가져가나?

-> AWS에는 kubenet은 없는 것 같다.

Azure CNI의 단점

: IP가 상당히 많이 필요하다. IP를 미리 만들어서 pre-allocate하는 구조로 되어 있기 때문에, 

엔터프라이즈를 운영하거나 서비스를 운영할 때 IP 대역대의 여유가 많지 않으면 kubenet을 사용하는게 훨씬 좋을 수 있다.

Azure CNI는 IP가 여유로울 때 사용하는 것이 좋다.

 

라우팅 관점에서 참고

https://coffeewhale.com/k8s/network/2019/04/19/k8s-network-01/

[번역] 쿠버네티스 네트워킹 이해하기#1: Pods

 

Calico CNI에서는 오버레이 통신 (VXLAN, IP-IP)로 통신을 하고, AWS VPC CNI는 동일 대역으로 직접 통신한다.

중간에 한번 라우팅(?)을 하지 않으니 속도나 지연 시간이 더 낫겠군.

 

1주차 숙제(?)

-> 워커 노드에 생성 가능한 최대 파드 갯수를 늘릴 수 있을까?

https://trans.yonghochoi.com/translations/aws_vpc_cni_increase_pods_per_node_limits.ko

Amazon VPC CNI 플러그인으로 노드당 파드수 제한 늘리기

답)

IPv4가 아니라, IPv4 Prefix 기능을 사용한다.

 

Secondary IPv4 addresses : 인스턴스 유형에 최대 ENI 갯수와 할당 가능한 IP 수를 조합해서 만듦

IPv4 Prefix Delegation : IPv4 28bit 서브넷(prefix)을 위임하여 할당 가능한 IP 수와 인스턴스 유형에 권장하는 최대 갯수로 선정

 

아예 Prefix로 해버리니까, 할당 가능한 IP 갯수가 훨씬 늘어난다.

Q) 그런데 할당 가능한 IP 수는 128개인데, 최대 파드는 110개네?

뭐지... 보완 필요.

 

워커노드 1의 기본적인 네트워크 구성은 위 그림과 같다.

 

• Network 네임스페이스는 호스트(Root)와 파드 별(Per Pod)로 구분된다
• 특정한 파드(kube-proxy, aws-node)는 호스트(Root)의 IP를 그대로 사용한다
• t3.medium 의 경우 ENI 마다 최대 6개의 IP를 가질 수 있다
• ENI0, ENI1 으로 2개의 ENI는 자신의 IP 이외에 추가적으로 5개의 보조 프라이빗 IP를 가질수 있다
• coredns 파드는 veth 으로 호스트에는 eniY@ifN 인터페이스와 파드에 eth0 과 연결되어 있다

파드간 통신 흐름

AWS VPC CNI의 경우 별도의 오버레이 통신 기술 없이, VPC Native하게 파드간 직접 통신이 가능하다.

어.. 잠깐, AKS도 위와 비슷하게 바로 통신이 가능했던 것 같다.

Azure의 경우 kubenet은 안되고, Azure CNI를 사용할 때만 가능했다.

https://blog.hojaelee.com/207

오개념) AKS 실전 - AKS Network 심화 (+internal LB 만드는 법) / aks 내부 접속시 ip와 외부 접속시 ip는 다

헐 나 천잰가봄...ㅎ

 

파드간 통신 과정

파드에서 외부 통신 흐름 : iptable에 SNAT를 통해서 노드의 eth0 IP로 변경 되어서 외부와 통신됨

K8S Service는 총 3개가 존재한다.

Cluster IP, NodePort, LoadBalancer

 

 

 

Q) 그냥 LoadBalancer 타입과 Service (LoadBalancer Controller)의 차이를 모르겠다..?

(이 부분 보완 필요)

아, 그냥 진짜 NLB LoadBalancer를 이용하는거랑 K8S 내에서 서비스 형태로 LoadBalancer 쓰는거 말하는듯?

 

(일단 넘어가는데, NLB 모드 부분 시간 더 들여서 이해 필요)

 

K8s Ingress : 클러스터 내부의 서비스(ClusterIP, NodePort, LoadBalancer)를 외부로 노출(HTTP/HTTPS) - Web Proxy 역할

 

 

스토리지

 

기본적으로 파드 내부의 데이터는 파드가 정지되면 모두 삭제된다.

즉 Stateless한 상태다.

여기서 뭔가 운영하려면 당연히 Stateful하게 만들어줘야 하는데, 그래서 나온게...

Persistent Volume(PV) 예시) NFS, AWS EBS, Ceph(?)

 

동적 프로비저닝 : 파드가 생성될 때 자동으로 볼륨을 마운트해서 파드에 연결하는 기능

Reclaim Policy : Persistent Volume의 사용이 끝났을 때, 해당 볼륨을 어떻게 초기화할 것인지 별도로 설정하는 것

Retain(보존), Delete(삭제, EBS 볼륨 삭제), Recycle 방식이 있다.

 

https://kubetm.github.io/k8s/03-beginner-basic-resource/volume/

 

쿠버네티스 Volume의 경우 다음과 같이 3가지 종류가 존재한다.

 

emptyDir : 임시로 만듦

hostPath :마운트된 디스크에 연결

PVC/PV : AWS 클라우드 상에 있는 file이나 disk에 해당하는 부분이 있을 수 있고 이걸 맵핑해서 사용하는게 PV다.

PVC는 Pod의 Volume과 AWS의 PV를 연결해주는 것.

 

https://blog.hojaelee.com/232

AKS 실전 - AKS Volume 심화

이전에 작성한 Azure 내용을 참고해도 좋겠다.

 

스토리지가 연결되는 흐름도는 다음과 같다.

 

잠깐)

 

PV와 PVC란?

PV는 볼륨 자체를 뜻한다. 클러스터 안에서 자원으로 다루고, 파드와는 별개로 관리되며 별도의 생명 주기 존재

PVC는 사용자가 PV에 하는 요청이다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청

 

https://kimjingo.tistory.com/153

[k8s] Volume - PV/PVC(퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임)

ㄴ 보다 자세한 내용