PKOS Study #2-1에서 Kubernetes Network에 대한 기본적인 내용을 정리했다.
이번 2-2에서는 지난 문서에서 정리하지 못한 Loadbalancer에 대한 내용과 Storage 파트를 정리할 계획이다.
1. Pods 생성 수량 제한
Worker Node의 EC2 Instance Type 별로 Pods 생성 수량은 제한 된다. Pods 생성 수량 기준은 인스턴스에 연결 가능한 ENI 숫자와 할당 가능한 IP 수에 따라 결정되게 된다.
* aws-node, kube-proxy Pods는 Host의 IP을 같이 사용하기 때문에 배포 가능 최대 수량에서 제외 된다. (IP 조건에서 제외되기 때문에)
Pods 최대 생성 수량 계산 : {Instance에 연결 가능한 최대 ENI 수량 x (ENI에 할당 가능한 IP 수량 – 1)} + 2
위 식을 계산하기 위해서는 내가 사용하는 Node Instance Type의 ENI 및 IP 할당 제한을 확인할 필요가 있는데 그럴 때는 아래와 같이 확인 할 수 있다.
Values=t3.* 부분을 확인하고 싶은 Instance Type으로 변경하면 된다.
aws ec2 describe-instance-types --filters Name=instance-type,Values=t3.* \
--query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
--output table
내가 사용하는 Instance Type은 t3.medium이고 해당 Instance의 경우 연결 가능한 ENI는 3개이고 ENI당 할당 가능한 IP는 6개이다. 위 계산식에 대입하면 {3 x (6-1)} + 2가 되고 aws-node, kube-proxy 포함하여 총 17개의 Pods를 생성할 수 있게 된다.
Pods 생성 수량(Replicas)을 늘리면서 Worker Node의 ENI 정보와 IP 주소에 어떤 변화가 있는지 확인해보겠다.
우선 어떠한 Pods도 배포하지 않았을 때 Worker Node 1, 2의 ENI 상태 화면이다. (위가 1, 밑이 2)
Replicas 수량이 2개인 Deployment을 생성했을 때 ENI와 IP 모습이다.
Pods가 2개 생성되어 각각 IP을 할당 받은 것을 확인 할 수 있다. 각 Pods는 서로 다른 Node에 배포 되었다는 것을 IP을 통해 확인 할 수 있다.
이번엔 Replicas을 8로 증가하여 보았다.
Pods가 8개로 증가하며 ENI 정보와 IP가 각각 증가한 것을 알 수 있다. 현재 Worker Node는 t3.medium으로 앞서 계산한 공식에 따르면 Pods을 15개까지 생성할 수 있다. Worker Node가 2개이니 30개까지 생성이 가능한지 확인해봤다.
30개로 증가하는 명령어 이후 Running 중인 Pods 수량을 확인하면 21개만 생성 된 것을 알 수 있다. 왜 30개가 아닌 21개인지 궁금하여 현재 Node에서 실행 중인 Pods들을 모두 조회하고 해당 Pods들이 사용 중인 IP들을 확인해보았다.
kubectl get pod --all-namespaces -o wide현재 Deployment가 생성 된 namespace가 아닌 kube-system namespace에서 사용 중인 Pods들까지 확인할 수 있었다.
Node 1은 이미 5개의 IP을 할당 받아 사용 중이었고 Node 2는 4개의 IP을 할당 받아 사용 중이었다. 총 할당 가능한 15개의 IP 중 이미 4, 5개의 IP을 기존 시스템에서 사용 중인 상태라 30개의 Pods 중 9개가 부족한 21개의 Pods만 정상적으로 배포가 된 것을 확인할 수 있었다.
그럼 EC2 Instance Type에 종속되는 Pods 배포 수량을 극복할 수 있는 방안은 없을까? 아니다 Prefix Delegation 방식을 사용하면 Instance Type에 한정되지 않고 Pods을 배포할 수 있다.
자세한 내용은 아래 링크를 참고하면 된다.Amazon EC2 노드에 사용 가능한 IP 주소의 양 늘리기 – Amazon EKS관리형 노드 그룹은 maxPods의 값에 최대 수를 적용합니다. vCPU가 30개 미만인 인스턴스의 경우 최대 수는 110이고 다른 모든 인스턴스의 경우 최대 수는 250입니다. 이 최대 수는 접두사 위임의 활성docs.aws.amazon.com
나는 t3.medium Type을 Worker Node에 사용했고 해당 Node의 Allocatable을 확인하는 명령어를 통해 가용 가능 Pods을 확인해보았다. 앞서 계산한 바와 같이 17개임을 확인 할 수 있다.
50개의 Pods을 배포하는 명령어를 실행했을 때 21개만 배포가 되어있는 것을 확인할 수 있다. 이는 앞서 배포했을 때 확인할 수 있었던 수치와 동일하다.
설정값을 바꾸기 위해 kops edit cluster을 통해 내용을 수정하고 Rolling Update을 실행했다.
kops edit cluster
<em>#maxPods 수정</em>
kubelet:
anonymousAuth: false
maxPods: 50
<em>#ENABLE_PREFIX_DELEGATION 수정</em>
networking:
amazonvpc:
env:
- name: ENABLE_PREFIX_DELEGATION
value: "true"
<em>#Rolling Update 진행, 해당 과정에서 Node들의 IP 변경 발생하고 약 15~20분 정도 소요 된다.</em>
kops update cluster --yes && echo && sleep 5 && kops rolling-update cluster --yesRolling Update 이후 배포 가능 Pods 확인을 진행하였다.
그 후 다시 Replicas을 50으로 수정하여 배포를 진행하였다.
50개가 모두 실행 중인 것을 확인할 수 있었다. ENI 정보와 IP 정보를 조회했을 때도 해당 수량이 증가한 것을 알 수 있었다.
나는 실습 전에 CPU Limits을 제거하고 진행했기 때문에 원할하게 Pods들이 증가했으나 Network 제한만 푼다고 해서 Pods들이 많이 생성되지 않을 수 있다. 그럴 때는 아래와 같은 방법으로 CPU Limits을 해제하면 된다.
kubectl describe limitranges <em># LimitRanges 기본 정책 확인 : 컨테이너는 기본적으로 0.1CPU(=100m vcpu)를 최소 보장(개런티)</em>
kubectl delete limitranges limits
kubectl get limitranges위 방법으로 CPU 제한을 해제하고 배포를 진행해보면 더 많은 수의 Pods가 배포되는 것을 확인할 수 있다.
2. LoadBalancer Controller with NLB
Kubernetes의 Service에는 ClusterIP, NodePort, Loadbalancer Type이 있다.
ClusterIP : Control Plane의 iptables을 이용하여 내부에서만 접근 가능한 방식으로 외부에서의 접근은 불가능하다.
NodePort : 위 ClusterIP는 외부에서 접근이 불가능하기 때문에 외부에서 접근 가능하게 하기 위해서 Worker Node의 Port을 맵핑하여 통신할 수 있도록 한다.
Loadbalancer : NodePort 방식과 마찬가지로 외부에서 접근할 수 있는 방식이다. 다만, Worker Node의 Port을 통해 접근하는 방식이 아닌 앞단에 위치한 LoadBalancer을 통해 접근하게 된다.
Loadbalancer Controller : Public Cloud을 사용할 경우 각 CSP에서 제공하는 Loadbalancer을 사용하기 위해 설치하는 Controller이다. 이를 통해 CSP의 LB을 제어할 수 있게 된다.
나는 one-click kOps yaml을 사용하여 실습을 진행했기 때문에 그 과정에 IAM Policy 생성 및 Role Attach까지 같이 마무리를 하였다. 혹시 그 내용이 누락되어 있다면 해당 내용을 추가로 진행해야 한다. (특히 Rolling Update 등으로 IAM Profile이 빠져있을 수 있다.)
NLB가 같이 포함 된 yaml을 사용하여 Deployment 생성을 진행했다.
그 후 정보를 확인하여 NLB 주소를 확인할 수 있었다.
NLB 주소를 Client에서 접속 시도하여 정상적으로 페이지가 호출되는 것까지 확인하였고 해당 NLB 주소는 내 도메인에 연결 및 테스트까지 완료하였다.
내 도메인 레코드와 NLB을 통해 정상적으로 분산 되는지를 테스트하였고 이상 없이 분산 되는 것을 확인했다.
NLB=$(kubectl get svc svc-nlb-ip-type -o jsonpath={.status.loadBalancer.ingress[0].hostname})
curl -s $NLB
for i in {1..100}; do curl -s $NLB | grep Hostname ; done | sort | uniq -c | sort -nr
3. Kubernetes Storage
Kubernetes Storage : hostPath, emptyDir, PV/PVC 등이 있고 이번 실습에는 PV/PVC을 진행할 예정이다.
hostPath : Pods가 배포 된 Worker Node(Host)의 Directory Path을 Pod에 Mount하여 사용하는 방법으로 Host Directory Path에 Data을 저장하기 때문에 Pods가 삭제되더라도 Data는 유지시킬 수 있다.
emptyDir : Pod 내부에 존재하고 휘발성을 뛰고 있다. hostPath와 다르게 Pod을 삭제하면 Data도 삭제되기 때문에 이 점은 유의해야 한다.
PV/PVC : hostPath와 언뜻 비슷해보이지만 hostPath는 Pods가 배포 된 Worker Node의 공간을 사용한다고 봤을 때 PV/PVC는 공유 공간이라고 보는 게 좋다. 동일한 Worker Node가 아니더라도 공간을 공유할 수 있으며 이를 위해 AWS에서는 EBS, EFS 등을 사용한다.
EBS을 생성하고 추가 된 EBS 볼륨을 확인하는 내용으로 PV/PVC 실습을 진행한다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4GiapiVersion: v1
kind: Pod
metadata:
name: app
spec:
terminationGracePeriodSeconds: 3
containers:
- name: app
image: centos
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: ebs-claim위 내용으로 PVC 및 Pods을 생성한다. 4GB의 용량에 RW Access가 설정 된 EBS을 생성한 후 Pods에 해당 EBS을 Mount하는 내용이다. 생성 된 Pods의 /data 경로를 보면 해당 EBS가 마운트되어 있어야 한다. 아래 방법으로 해당 내용을 확인한다.
/data/out.txt 파일을 호출하고 app Pod의 Filesystem 정보를 조회한 내용이다. 제대로 Mount되었음을 확인할 수 있다.
4. 마무리
지난 실습 때 Pods 생성 제한이나 NLB 등을 제대로 이해하지 못해 추가로 진행하였는데 늦게라도 해보길 잘했다는 생각이 들었다. Storage 부분은 특이한 내용은 없었고 기존 컨테이너를 공부할 때 배웠던 내용들이 같이 들어있어서 이해하는데 도움이 됐다.
Network 부분이 계속 어려웠었는데 이번 기회가 기술 성숙도를 올릴 수 있는 기회가 되길 바란다.
