EKS 스터디 2주차 (Networking)

 

 

(많이) 늦었지만, EKS 스터디 2주차 (네트워크) 정리와 복습하면서 공부해본 내용을 정리 해보겠습니다.

 

목차

• 알쓸리잡(알아두면 쓸데있는 리눅스 잡학지식)
  
  • 네트워크 통신을 확인하기 위해 알아야하는 도구들
• 워커 노드의 구성
• CNI란?
• 노드에서 제공가능한 파드 한계
• 워커 노드에서 일어나는 네트워크
• 쿠버네티스 서비스
• 서비스 노출

 

본문

알쓸리잡(알아두면 쓸데있는 리눅스 잡학지식)

복습을 하면서 새롭게 알게되는 리눅스 프로그램들을 소개하고, 간단한 사용법을 나열하면 좋겠다고 생각해서 포함했습니다.

자세한 내용은 참고링크를 걸어둘테니 필요한 만큼 지식을 탐독하시기 바랍니다.

스터디에서는 간략히 넘어가는 부분이기도 하고, 저처럼 궁금증이 생길수도 있겠다 싶어 작성하게 되었습니다.

이번에 알아볼 프로그램 목록은 이러합니다.

• ip
• iptables
• tcpdump

ip

ip 이 명령어는 리눅스를 오랫동안(?) 사용해본 아재들한테 "김군아, 그 서버 아이피 뭐라고 ?" 라고 물어보면 쓰는 ifconfig나 "어이 김씨, 라우트 테이블 조회해봤어?" 라고 물어봤을 때 쓰는 route 같은 명령어를 대체할 수 있는 명령어 입니다.

addr 이라는 옵션을 붙여서 `ip addr`를 입력하게 되면 현재 NIC(AWS에서는 ENI)에 대한 정보를 확인할 수 있습니다.

route라는 옵션을 붙여서 `ip route`를 입력하면, 라우트 테이블을 조회할 수 있습니다. 

- 라우트 정보를 추가, 삭제하는 기능을 포함합니다.

- 약어도 지원합니다.  

참고링크: 링크

ifconfig, route 를 대체하는 Linux ip 명령어

iptables

OS 방화벽중 하나로, 규칙을 기반으로 해서 패킷을 허용하거나 차단하는 프로그램 입니다.

 

참고링크: 링크

iptables 개념 및 명령어

 

tcpdump

Network Interface를 거치는 패킷을 캡쳐해주는 도구입니다.

옵션으로 필터링을 걸어서 필터링 된 패킷을 화면에 출력하거나 파일로 저장할 수 있습니다.

필터링 옵션에서는 Network Interface를 지정하거나 출발지, 도착지 IP 혹은 포트, TCP, UDP 등을 지정할 수 있습니다.

참고링크: 링크

IT위키

 

실습배포

배포하기

# cloudformation template.yml 파일을 다운로드 받습니다.
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick.yaml

# 아래 변수는 각자 상황에 맞게 넣어주세요.
KeyName                  # EC2 key pair
SgIngressSshCidr         # Bastion node에 SSH 접속가능한 ip cidr
ClusterBaseName          # 클러스터 이름
MyIamUserAccessKeyID     # AWS IAM User Access Key
MyIamUserSecretAccessKey # AWS IAM User Secret Key

 

혹은 cloudformation 에서 위 객체 주소를 입력해줍니다. 

배포가 완료되면, 위와같이 cloudformation 출력부분에서 bastion node의 public IPv4가 값에 표시됩니다.

CLI에서도 AWS CLI를 활용하여 동일한 값을 출력할 수 있습니다.

Bastion Host에 SSH 접속을 위해 위와 같이 입력후 접속해봅시다.

Bastion Host 의 Public IP는 콘솔에서도 아래와 같이 확인할 수 있습니다.

 

 

 

위 명령어로 SSH 접속을 하게 되면 Bastion 노드에 정상적으로 접근이 되는 것을 확인할 수 있습니다.

 

default namespace를 적용해볼까요 ?

 

# 노드의 정보를 확인해봅시다.
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone

eksctl get iamidentitymapping --cluster myeks

 

각 노드가 각각의 AZ에 떠있는 것을 확인할 수 있네요.

EKS Cluster에 할당된 IAM 역할도 확인할 수 있습니다.

 

 

 

작업노드들(Worker Nodes)의 정보를 등록해볼까요 ? 

각 AZ별로 노드를 N1, N2, N3으로 구분하여 profile 파일에 넣고 source 명령어로 불러옵니다.

이렇게 콘솔에서 매번 확인하지 않아도 호스트 정보를 변수에 담아놓고 사용할 수 있습니다.

 

보안그룹 (Security Group)의 인바운드(Inbound) 설정을 추가하여, 인스턴스간에 네트워크를 허용해줍니다.

protocol 의 -1은 all을 뜻합니다. 

 

 

적용된 결과를 출력해주네요. 확인해보니 잘 적용된 것 같습니다.

콘솔에서도 잘 확인이 됩니다.

 

역시나 ping test도 잘 됩니다.

 

배포된 내용 확인하기

 

배포된 컨테이너의 이미지를 출력합니다. 

(매번 가시다님의 커맨드라인을 보면서 배울점이 너무 많아서 감사합니다. 고맙습니다 !!)

eksctl에 설치 혹은 업데이트된 애드온(add-on)을 출력합니다.

실습을 위한 모든 준비가 된 것을 확인했습니다. 

 

실습 - CNI란?

네트워크 모델은 각 노드의 컨테이너 런타임에 의해 구현된다. 가장 일반적인 컨테이너 런타임은 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용하여 네트워크 및 보안 기능을 관리한다. 여기서는 칼리코(K8s Calico CNI)와 EKS에서 사용하는 VPC CNI를 설명하겠습니다.

가시다님 스터디 자료

위 그림을 살펴보면, 칼리코 CNI 에서는 파드의 대역과 노드의 대역이 다르고, VPC CNI에서는 노드와 파드의 네트워크 대역이 같은 것을 알 수 있습니다. 결과적으로 칼리코 CNI에서는 파드에서 노드의 네트워크를 타면서 오버레이 통신되어야 하는 단점이 생깁니다.

결과적으로 VPC CNI가 네트워크 최적화를 위해 더 좋은 선택이라고 할 수 있습니다. (반박시 그대의 말이 맞습니다.)

더 상세한 내용은 다음에 따로 주제를 잡고 포스팅을 해보겠습니다. 

 

또한, EC2에는 인스턴스 사이즈에 따라서 사용가능한 Secondary IPv4가 제한되어 있습니다.

그렇다면, 어떻게 제한되어 있는지 살펴봅시다. 

2가지 방식이 있네요. 보조아이피와 접두사 위임. 

보조 아이피는 아래 공식처럼

최대 파드수 = ENI * (ENI당 지원하는 IPv4 갯수 - 1) + 2

접두사 위임은

ENI * (ENI당 지원하는 IPv4 갯수 - 1) * 16 인것을 알 수 있습니다.

 

그럼 이제 테스트용 파드를 배포한 다음, 네트워크를 확인해보겠습니다.

파드를 배포하기전에 tmux로 화면을 나누었습니다. 아래에는 각 노드의 네트워크 상황을 모니터링 하기 위해 아래 명령어를 입력했습니다.

watch -d "ip link | egrep 'eth|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"

 

테스트용 파드를 배포합시다.

cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot-pod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: netshoot-pod
  template:
    metadata:
      labels:
        app: netshoot-pod
    spec:
      containers:
      - name: netshoot-pod
        image: nicolaka/netshoot
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

 

못 보던 내용들이 아래 생겼죠. 아래 모니터링에서 변경된 부분을 확인해봅시다. 

또한, 파드 이름을 변수로 지정하여 클러스터에서 파드 정보를 조회한 것과 변경된 부분이 일치하는 지 봅시다.

첫 번째 파드 netshoot-pod-7757d5dd99-gvq5z 는 3번노드(우측)에 붙고, 

두 번째 파드는 2번노드(중앙), 세 번째파드는 1번노드(좌측)에 할당된 것을 확인할 수 있습니다.

 

노드내에서 네트워크 인터페이스를 확인해봅시다

ip -br -c addr show
ip -c link
ip -c addr
ip route # 혹은 route -n

그러면 위 이미지에서 확인했던 enifb8391d696f(192.168.3.214), enif1441bab394(192.168.3.217) 두 네트워크 인터페이스가 노드 내에서 어떻게 연결되는 지 확인할 수 있습니다. 

 

3번 파드 안에서 네트워크 정보를 확인해볼 수 있습니다. 

 

노드간 파드 통신

구성은 아래와 같습니다. 1번 파드(3번노드)에서, 2번 파드(2번노드)로 핑을 보내는 테스트를 하고자 합니다. 

이를 통해 파드간에

아래 화면 구성

(좌측 상단) : 3번 노드    (좌측 하단) : 1번 파드(3번 노드)

(우측 상단) : 2번 노드    (우측 하단) : 2번 파드 (2번 노드에 위치함)

파드에서 어떤 인터페이스를 통해 pint 테스트가 일어나는 지 알 수 있습니다.

 

아래 이미지는 amazon vpc-cni 참고자료입니다.

https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md

 

 

서비스의 종류

쿠버네티스 서비스는 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법입니다.

(https://kubernetes.io/ko/docs/concepts/services-networking/service/)

종류에는

ClusterIP :  클라이언트가 'ClusterIP' 접속 시 해당 노드의 iptables에 의해 DNAT 처리가 되어 목적지 파드와 통신

DNAT: 목적지 주소를 변경하는 NAT(Destination NAT)[https://zigispace.net/1121]

 

NodePort :  외부 클라이언트가 '노드IP:NodePort' 접속 시 해당 노드의 iptables 룰에 의해서 SNAT/DNAT 되어 목적지 파드와 통신

LoadBalancer :  작업 노드들 앞에 NLB가 연결되어 있는 구성입니다.

 

LoadBalancer Controller :  AWS Load Balancer + NLB IP모드 동작 with AWS VPC CNI

 

위와 같은 Service 구성을 통해 파드에 위치한 어플리케이션이 외부와 통신할 수 있습니다. 여기서 추가적으로 ExternalDNS(개인 도메인이 필요함)가 있는 경우에 도메인을 붙여 서비스를 공개할 수 있습니다.

 

서비스는 어플리케이션의 요구사항에 맞게 구성하면 될 것 같습니다. 

2주차 스터디 후기는 한 주 밀렸지만, 마칠때까지 꾸준함을 갖고 포스팅 해보도록 하겠습니다.

읽어주셔서 대단히 감사합니다.

 

새로운 기술을 배우다보니 재밌는 아이디어들이 샘솟아서 즐겁네요.

 

사용한 리소스는 꼭 삭제해주세요. !!!

eksctl delete cluster --name $CLUSTER_NAME && aws cloudformation delete-stack --stack-name $CLUSTER_NAME