[KANS 3기] 3주차 실습환경 구성하기 (1/3)

들어가기 전에...

이번 3주차 스터디는 k8s cni 중 하나인 calico에 대한 내용을 다룹니다. 이 게시글을 이해하기 위해서는 쿠버네티스 지식과 네트워크 지식이 필요합니다. 

 

목표

실습 환경은 아래 이미지와 같은 구성도로 만들어집니다. AWS 환경에서는 k8s-rtr 대신 AWS VPC 내부의 라우터가 역할을 대신합니다. AWS의 내부 라우터 리소스는 실제로 확인할 수 없습니다. vpc의 라우팅 테이블이 어떻게 구성되어 있는지는  다음 문서를 읽어보시면 이해가 쉽습니다. (https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Route_Tables.html)

가시다님 제공

 

리소스 생성

위 구성과 같이 리소스를 생성하겠습니다.

준비물

AWS 계정이 필요합니다.

- 계정이 없는 경우에는 다음 영상을 참고해주세요. (https://www.youtube.com/watch?v=MFJxQRrPD_E

AWS 계정으로 로그인 한 다음, 서울리전으로 가서, aws ec2 key-pair를 생성합니다.

key 파일을 다운로드해서 잘 보관합니다.

cloudformation을 통해 리소스 생성

모든 리소스를 바닥부터 생성할 수 없기 때문에 gasida님께서 제공해주신 cloudformation template file을 가지고 진행하도록 하겠습니다.

KEY_PAIR_NAME='yeoli' # 이전에 생성한 키페어 이름 
STACK_NAME='yeoli-k8s-study' # cloudformation stack 이름 
PROFILE_NAME='lab' # (optional, aws 자격증명 프로파일이름)

curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-3w.yaml
aws cloudformation deploy \
  --template-file kans-3w.yaml \
  --stack-name $STACK_NAME \
  --parameter-overrides \
  KeyName=$KEY_PAIR_NAME \
  SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 \
  --region ap-northeast-2 \
  --profile $PROFILE_NAME

 

잠시 기다리면 ec2 instance 목록에 다음과 같이 4대의 인스턴스가 생성되어 있는 것을 확인할 수 있습니다.

나머지 설정을 위해서 앞서 생성한 key-pair로 ec2에 접속해보겠습니다.

먼저 public ip를 확인합니다.

 

ip를 확인했으니 terminal에서 해당 ec2에 ssh 접속을 하겠습니다.

ssh -i [keypair file] ubuntu@[target ec2 public IP]

 혹시 아래와 같은 오류가 발생한다면 파일의 권한이 너무 공개되어 있어 그런거니 소유자만 읽을 수 있는 권한으로 변경해줍니다.

chmod 400 [keypair file]

 

이제 정상적으로 접속이 되는 걸 확인할 수 있습니다.

생성된 리소스 설정 확인

ec2 instance가 생성되자마자 성급하게 로그인했다면 아직 k8s가 구성되고 있는 중일 수 있습니다. 하나씩 확인하면서 구성이 다 되었는지 확인해보겠습니다.

kubectl cluster-info
kubectl get node -owide
kubectl get service,ep
kubectl get pod -A -owide

아직 모든 파드가 다 생성된 게 아니니 조금 기다려줬다가 pod가 running으로 바뀔때까지 기다려줍니다.

 

네트워크 인터페이스 및 라우팅 정보

ip 명령어로 routing table, ip address를 확인합니다.

 

현재 사용가능한 cni 를 확인하고 iptables에 설정된 filter, nat 테이블 규칙이 얼마나 설정되어 있는지 확인합니다. 

filter table은 기본 테이블입니다. INPUT, FORWARD, OUTPUT 체인이 포함됩니다. 

INPUT : 목적지가 호스트인 모든 패킷

FORWARD:  목적지가 호스트가 아닌 패킷 (즉 호스트를 거쳐가는 패킷)

OUTPUT: 출발지가 호스트인 모든 패킷

참조: https://blessu1201.github.io/2020/09/08/iptables.html

IPTABLES 옵션 정리 - Honey Blog

 

nat table은 새로운 연결을 생성하는 패킷이 발생했을 때 참조되는 테이블입니다.  PREROUTING, OUTPUT, POSTOUTING 체인을 포함합니다. 

PREROUTING (DNAT): 패킷 도착지 주소 변경

POSTOUTING (SNAT or masquerade): 패킷 출발지 주소 변경

OUTPUT: 호스트에서 밖으로 흐르는 패킷의 도착지를 변경한다.

PREROUTING / OUTPUT chain의 차이는 패킷 발생 주체가 다르다. PREROUTING은 외부의 패킷을 가로채서 도착지 주소를 변경하고, OUTPUT은 호스트에서 발생한 패킷의 도착지 주소를 변경한다.

 

위 내용을 보면, Calico를 구성하기 전에 chaing rule 은 다음과 같다.

filter chain rule은 50개

nat chain rule은 48개 

 

calico 구성하기

가시다님이 스터디 상황에 맞게 수정해주신 파일을 사용하겠습니다. 
기존 https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/calico.yaml 파일에서 아래 주석부분이 수정된 파일입니다.

#            # Block size to use for the IPv4 POOL created at startup. Block size for IPv4 should be in the range 20-32. default 24
#            - name: CALICO_IPV4POOL_BLOCK_SIZE
#              value: "24"

kubectl apply -f https://raw.githubusercontent.com/gasida/KANS/main/kans3/calico-kans.yaml

 

명령어 한 줄로 calico cni가 구성됩니다.

 

calico 구성 확인

 

아래 명령어로 calico 를 구성하는 pod가 제대로 배포되고 있는지 확인할 수 있습니다.

kubectl get pods -A -o wide

 

 

pod가 모두 배포된 것을 확인했으니 calico를 구성하면 어떤 내용이 변경되는지 확인해보겠습니다. 

 

calico 구성 전과 후를 비교하기 위해 다음과 같이 표로 정리해봤습니다.

	# of filter table chaning rules	# of nat table chaning rules
calico 구성 전	50	48
calico 구성 후	210	126

 

calico 를 구성하면서 뭔가 많은 chainig rule이 추가되었다는 사실을 확인할 수 있습니다.

그리고 한 가지 더 확인해보겠습니다.

 

 

ip -c route 
ip -c addr

calico 가 구성되면서 라우팅 정보가 추가되었고, ip 정보가 추가된 것을 확인할 수 있습니다.

궁금한 점이 많아지지만 다음 글에서 172.16.x.x 대역과 iptables chaing rule, 라우팅 테이블에 관하여 더 살펴보도록 하겠습니다.

 

calicoctl 설치

칼리코를 조금 더 쉽게 다루기 위해 아래 명령어를 사용하여 calicoctl을 설치하겠습니다.

# calicoctl install
curl -L https://github.com/projectcalico/calico/releases/download/v3.28.1/calicoctl-linux-amd64 -o calicoctl
chmod +x calicoctl && mv calicoctl /usr/bin
calicoctl version

 

k9s 구성하기

쿠버네티스를 좀 더 쉽게 살펴보기 위해 k9s를 구성합니다. k9s는 metric-server를 구성하면 popeye를 사용하여 kube-ops-view를 대체할 수 있습니다. k9s 사용방법은 아래 글을 참고하시면 됩니다.

https://yeoli-tech.tistory.com/42#%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%C2%A0-%EB%8F%84%EA%B5%AC-%EC%84%A4%EC%B9%98

[KANS 3기] 2주차 스터디 내용 정리

 

k9s 설치

# mac
brew install k9s

# ubuntu
wget https://github.com/derailed/k9s/releases/download/v0.27.4/k9s_Linux_amd64.tar.gz \
  && tar -zxvf k9s_Linux_amd64.tar.gz \
  && mv k9s /usr/bin/k9s \
  && rm k9s_Linux_amd64.tar.gz

 

metric-server 설치

1. 각 worker node에 존재하는 kubelet은 cAdvisor을 포함하고 있습니다.

2. cAdvisor가 pod 내 컨테이너의 메트릭 정보를 수집하여 노출합니다.

3. kubelet이 cAdvisor의 메트릭을 수집하고 다시 노출합니다.

4. metric-server가 kubelet의 메트릭을  다시 수집 및 노출합니다.

5. kube-apiserver가 metric-serverd의 메트릭을 수집합니다.

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm upgrade --install metrics-server metrics-server/metrics-server -n kube-system

 

 

k9s 사용법

k9s # k9s 실행

 

metric-server를 구성하고나면, k9s에서 각 파드별 cpu,mem 사용량을 확인할 수 있습니다.

 

뿐만 아니라 :pu 입력시 pulse 기능을 사용할 수 있습니다. deployment, 레플리카셋, 스테이트풀셋, 데몬셋 뿐만 아니라 하드웨어 사용량을 확인하기도 쉽습니다.

 

 

 

여기까지해서 스터디 실습 준비를 마쳤습니다. 이제 본격적으로 calico가 무엇인지 파헤쳐 봅시다.