여리의 기술블로그

Databricks Auto Loader: Legacy File Notification에서 Managed File Events로 전환하기

엔지니어-여리 — Mon, 2 Feb 2026 01:49:35 +0900

TL;DR

S3 버킷당 Event Notification 100개 제한에 부딪혀 Managed File Events(MFE)로 전환했습니다. 공식 문서는 간단해 보이지만, CDC 환경에서는 자칫 잘못하면 데이터 유실이 발상할 수 있습니다. 이 글에서는 CDC 파이프라인에서 MFE로 안전하게 전환하는 방법과, 놓치기 쉬운 내용들을 다룹니다.

문제 상황: S3 Event Notification 한계에 부딪히다

Aurora MySQL에서 DMS를 통해 S3로 CDC 데이터를 적재하고, Databricks Delta Live Tables(DLT)로 ETL 파이프라인을 운영하고 있었습니다. 초기에는 Auto Loader의 Legacy File Notification 모드를 사용했는데, 파이프라인이 늘어나면서 한계에 도달했습니다.
S3 버킷당 Event Notification 설정은 최대 100개로 제한됩니다.(Hard Limit) Legacy File Notification 모드에서는 파이프라인마다 개별 SNS/SQS를 생성하기 때문에, 테이블 수가 늘어날수록 이 한계에 빠르게 도달합니다. 새로운 테이블을 추가하려면 기존 파이프라인을 통합하거나 버킷을 분리해야 하는 상황이 왔습니다.

해결책: Managed File Events(MFE)

Databricks의 Managed File Events는 이 문제를 해결해 줍니다. MFE는 Databricks가 관리하는 단일 SNS/SQS 인프라를 모든 파이프라인이 공유하는 방식입니다. 버킷당 1개의 Event Notification만 사용하므로 사실상 파이프라인 확장에 제한이 없어집니다.

MFE의 Trade-off

물론 MFE도 만능은 아닙니다. 공유 인프라를 사용하기 때문에 처리량 제한이 있습니다. AWS 환경에서는 초당 약 2,000건의 파일 이벤트 처리가 한계입니다. 대규모 배치성 파일 적재가 빈번한 환경이라면 이 제한을 고려해야 합니다. 다만 현재 저희 환경에서는 충분히 감당 가능한 수준이었습니다.

왜 주의해야 하는가 : CDC 환경의 함정

공식 문서의 마이그레이션 절차는 다음을 안내합니다:

tearDownNotificationResources API로 기존 SNS/SQS 제거
External Location에 File Events 활성화
cloudFiles.useManagedFileEvents를 true로 설정
기존 cloud-specific 옵션 제거
스트림 재시작 (첫 실행 시 directory listing으로 동기화)

이 절차는 소스 데이터 유입을 중단할 수 있는 환경에서는 동작합니다. 예를 들어 배치성 파일 적재라면, 적재를 잠시 멈추고 SQS의 모든 메시지를 처리한 뒤 전환하면 됩니다.
하지만 CDC 환경에서는 이야기가 다릅니다.

DMS는 계속 돌아가고 있고, S3에는 끊임없이 새 파일이 생성됩니다. 이 상태에서 tearDownNotificationResources를 호출하면 어떻게 될까요?

SQS에 아직 처리되지 않은 메시지가 남아있는 상태에서 큐가 삭제됩니다
해당 메시지에 해당하는 파일들은 Auto Loader가 인식하지 못합니다
데이터 유실 발생

물론 DMS를 중단하고, SQS 메시지를 모두 소진한 뒤, MFE로 전환하고, 다시 DMS를 시작하는 방법도 있습니다. 하지만 이 방식은 다운타임이 길어지고, "메시지를 충분히 다 받았다"는 것을 확인하기도 쉽지 않습니다.
결국 CDC 환경에서 안전하게 전환하려면 Full Refresh가 필수입니다. 전환 과정에서 일부 데이터 유실이 발생할 수 있음을 인정하고, Full Refresh로 소스 데이터와 정합성을 다시 맞추는 것이 현실적인 방법이었습니다.

문서에서 살펴보기 어려웠던 것들

CDC 환경의 문제 외에도, 실제 적용 과정에서 문서에서 놓치기 쉬운 함정들을 만났습니다.

1. 숨겨진 File Events 활성화 버튼

MFE를 사용하려면 External Location에서 File Events를 활성화해야 합니다. 문제는 이 설정 버튼이 UI에서 바로 보이지 않는다는 것입니다.

2. Unity Catalog 권한 설정의 함정

DLT 파이프라인이 Unity Catalog를 사용한다면, 파이프라인 Runner(Service Principal 또는 User)에게 적절한 권한이 부여되어야 합니다. 문서에는 이 부분이 명확하게 설명되어 있지 않았습니다.

3. S3 경로 표기법: s3a:// → s3:// (중요)

이건 정말 예상하지 못한 부분이었습니다. 기존 Legacy File Notification 모드에서는 s3a://bucket-name/path 형식을 사용했습니다. MFE로 전환 후 동일한 경로를 사용했더니 파일을 인식하지 못했습니다.

이 부분을 수정하지 않으면, 파이프라인은 정상적으로 돌지만 실제로 데이터를 가져오지 못하는 이슈가 발생합니다.

(참고) s3a:// 형식으로 기술했던 것은 Hadoop/Spark 오픈소스 생태계의 S3 접근 프로토콜. MFE 모드에서 스킴을 s3a로 해도 에러는 발생하지 않으나 실제로 동작하지 않음

# 기존 Legacy File Notification 모드
# path = "s3a://my-bucket/cdc-data/"

# MFE 모드에서는 이렇게 변경해야 합니다
path = "s3://my-bucket/cdc-data/"

4. 제거해야 하는 기존 옵션들

문서에서는 cloudFiles.queueUrl 같은 cloud-specific 옵션을 제거하라고 안내하고 있습니다. 하지만 실제로는 문서에 언급되지 않은 옵션들도 제거해야 했습니다.

cloudFiles.queueName
cloudFiles.subscription
databricks.serviceCredential
cloudFiles.privateKey
cloudFiles.clientSecret

실제 마이그레이션 과정

CDC 환경에서 데이터 유실 없이 MFE로 전환한 실제 과정입니다.

Step 1. 모든 관련 파이프라인 중지

전환 대상 DLT 파이프라인들을 모두 중지합니다. 이 시점부터 DMS가 S3에 적재하는 파일들은 처리되지 않습니다.

Step 2. 기존 Notification 리소스 제거

tearDownNotificationResources API를 사용하여 기존 SNS/SQS 리소스를 제거합니다. 이때 SQS에 남아있던 미처리 메시지는 유실됩니다.

Step 3. MFE 설정 적용

External Location에서 File Events 활성화
노트북 코드에서 S3 경로를 s3:// 형식으로 변경
cloudFiles.useManagedFileEvents = true 설정
기존 cloud-specific 옵션 및 불필요한 옵션 제거

Step 4. 파이프라인 재시작 및 Full Refresh 실행

파이프라인을 재시작하고, 해당 파이프라인에 참조되는 모든 테이블에 대해 Full Refresh를 실행합니다. 이 과정에서 소스 데이터와 정합성이 다시 맞춰집니다.

Step 5. 검증

External Location의 Test Connection 기능으로 File Events가 정상 동작하는지 확인하고, 데이터 정합성을 검증합니다.

덤으로 얻은 것: 파이프라인 분리와 고가용성

이번 작업을 계기로 기존에 단일 스키마로 운영하던 구조를 소스 DB 스키마 기준으로 분리했습니다. 이전에는 하나의 거대한 파이프라인이 모든 테이블을 처리했다면, 이제는 스키마별로 독립된 파이프라인이 동작합니다.
이 구조 변경으로 얻은 이점:

장애 격리: 특정 스키마에 문제가 생겨도 다른 스키마의 데이터 처리에 영향을 주지 않습니다
운영 유연성: 스키마 단위로 Full Refresh나 장애 대응이 가능해져 운영 부담이 줄었습니다
데이터 일관성: 각 파이프라인의 데이터 일관성 경계가 명확해졌습니다

마이그레이션 체크리스트

비슷한 전환을 계획하고 계신 분들을 위해 체크리스트를 정리했습니다.
사전 준비

Databricks Runtime 14.3 LTS 이상 사용 여부 확인
Unity Catalog 활성화 여부 확인
필요한 권한 확보 (CREATE STORAGE CREDENTIAL, CREATE EXTERNAL LOCATION 등)
Full Refresh 소요 시간 산정 및 다운타임 확보

마이그레이션 실행

모든 관련 DLT 파이프라인 중지
tearDownNotificationResources API로 기존 리소스 제거
External Location에 File Events 활성화
노트북 코드에서 S3 경로를 s3:// 형식으로 변경
cloudFiles.useManagedFileEvents = true 설정
기존 cloud-specific 옵션 및 불필요한 옵션 제거
파이프라인 재시작 및 Full Refresh 실행

검증

External Location의 Test Connection으로 File Events 정상 동작 확인
데이터 정합성 검증

마치며

MFE 전환 자체는 올바른 선택이었습니다. S3 Event Notification 제한에서 벗어나 파이프라인 확장성을 확보했고, 부수적으로 아키텍처도 개선할 수 있었습니다.
다만 CDC 환경에서는 주의하지 않으면 데이터가 유실됩니다. 문서는 소스 데이터 유입을 중단할 수 있는 환경을 전제로 작성되어 있기 때문입니다. CDC 파이프라인을 운영하고 계신다면, Full Refresh를 위한 충분한 다운타임을 확보하시길 권합니다.

참고 자료

Cursor에서 Bedrock최신 모델을 써봅시다.

엔지니어-여리 — Tue, 11 Mar 2025 22:10:34 +0900

Cursor에서는 다양한 생성형 AI 모델을 제공해줍니다.

무료로 사용하는 사람들도 조금은 사용할 수 있지만 조금 쓰다보면 quota를 넘기기 일쑤입니다. 그래서 많은 사람들이 Cursor를 Pro plan 이상으로 비용을 내면서 사용하고 있습니다. 오늘은 cursor AI의 OpenAI 모델을 Bedrock Access Gateway로 대체하여 Cursor + Bedrock 연동을 해보도록 하겠습니다.

Cursor AI의 plan별 비용

먼저 Bedrock Access Gateway를 구성해봅시다.

그 전에 사용하고자 하는 Bedrock 모델을 활성화 해줍니다.

https://us-west-2.console.aws.amazon.com/bedrock/home?region=us-west-2#/modelaccess

us-west-2.console.aws.amazon.com

Antropic 사의 Claude 3.7 Sonnet 모델을 활성화해줍니다.

그 다음, secrets manager 서비스에서 secrets 를 만들어줍니다.

api_key: bedrock 으로 key:value pair를 만들어줍니다.

secrets 이름은 BedrockProxyAPIKey로 하겠습니다.

이후에, Bedrock Access Gateway를 구성하기 위해 bedrock access gateway github page에 방문합니다.

https://github.com/aws-samples/bedrock-access-gateway

GitHub - aws-samples/bedrock-access-gateway: OpenAI-Compatible RESTful APIs for Amazon Bedrock

OpenAI-Compatible RESTful APIs for Amazon Bedrock. Contribute to aws-samples/bedrock-access-gateway development by creating an account on GitHub.

github.com

가운데 CloudFormation stack 링크를 제공해줍니다. ALB + Fargate 1-Click Deploy 버튼을 눌러 Cloudformation 페이지로 접근합니다.

여기서 ApiKeySecretArn은 앞서 만든 secret의 arn 을 넣어줍니다.

그 다음 DefaultModelId는 아까 활성화한 model을 쓰고 싶습니다. 신나게 bedrock service로 가서 model ID를 복사해서 붙여넣으시면 동작하지 않습니다.

bedrock access gateway github에서 https://github.com/aws-samples/bedrock-access-gateway/blob/main/docs/Usage.md#reasoning 페이지를 보시면 model ID가 있습니다. 이걸 사용합니다.

us.anthropic.claude-3-7-sonnet-20250219-v1:0

Cloudformation 배포를 기다린 다음 Outputs 탭에 보시면 URL이 하나 있는 것을 확인할 수 있습니다. 이걸 복사합니다.

자 마지막으로 cursor 에서

기본설정 - Cursor Settings를 선택해 설정 화면에서 Models를 선택합니다.

OpenAI API Key는 아까 secrets에서 api_key의 값으로 넣은 bedrock을 넣어줍니다.

Override OpenAI Base URL에는 cloudformation에서 Output으로 나왔던 url을 넣어줍니다.

모두 입력 후 Save 버튼을 누르고, Verify 버튼을 눌러 줍니다. 그리고 Enable OpenAI API Key 버튼을 클릭해줍니다.

우측 상단에 초록색으로 활성화가 되면 설정이 완료되었습니다.

OpenAI 를 override 하였으므로, 모델은 gpt-4o로 설정해줍니다.

AFT 코드를 읽혀봤더니 잘 읽는 것을 살펴볼 수 있습니다.

[KANS 3기] 9주차 VPC CNI

엔지니어-여리 — Thu, 31 Oct 2024 02:12:41 +0900

실습환경 구성

배포

cloudformation template를 적용하여 stack을 배포하겠습니다.

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/eks-oneclick.yaml

stack 이름을 myeks로 설정한 다음 배포해줍니다.

cloudformation stack이 모두 완료되는 시간은 20분정도 소요될 수 있습니다.

모든 리소스가 생성된 이후에는 ec2에서 bastion host를 통해서 클러스터에 접근할 수 있습니다.

배포 확인

# default 네임스페이스 적용
kubectl ns default

# 설치 확인
kubectl cluster-info

# 클러스터 정보 확인
eksctl get cluster

# 클러스터 노드그룹 정보 확인
eksctl get nodegroup --cluster $CLUSTER_NAME

# 클러스터 구성정보 확인
kubectl config view

# node 조회
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone

# iam identity mapping
eksctl get iamidentitymapping --cluster myeks

# krew 플러그인 확인
kubectl krew list

# 모든 네임스페이스에서 모든 리소스 확인
kubectl get-all

# 클러스터에 설치된 add on 조회
eksctl get addon --cluster $CLUSTER_NAME

VPC CNI

소개

파드가 VPC의 ip를 직접 사용하므로, VPC내 다른 리소스와 원활하게 통신할 수 있습니다.

오버레이 네트워크를 사용하지 않아서 네트워크 성능이 우수합니다.

CNI 플러그인은 노드에서 ENI를 관리합니다. 노드가 프로비저닝되면 CNI 플러그인은 노드의 서브넷에서 기본 ENI로 슬롯 풀(IP 또는 접두사)을 자동으로 할당합니다. 이를 웜 풀이라고 하며 크기는 노드의 인스턴스 유형에 따라 결정됩니다. CNI 설정에 따라 슬롯은 IP 주소 또는 접두사가 될 수 있습니다. ENI의 슬롯이 할당되면 CNI는 슬롯의 웜 풀이 있는 추가 ENI를 노드에 연결할 수 있습니다. 이러한 추가 ENI를 보조 ENI라고 합니다. 각 ENI는 인스턴스 유형에 따라 특정 수의 슬롯만 지원할 수 있습니다. CNI는 필요한 슬롯 수에 따라 인스턴스에 더 많은 ENI를 연결하며, 이는 일반적으로 Pod 수에 해당합니다. 이 프로세스는 노드가 더 이상 추가 ENI를 지원할 수 없을 때까지 계속됩니다. CNI는 또한 더 빠른 Pod 시작을 위해 웜 ENI와 슬롯을 미리 할당합니다. 각 인스턴스 유형에는 연결할 수 있는 최대 ENI 수가 있습니다. 이는 컴퓨팅 리소스 외에도 Pod 밀도(노드당 Pod 수)에 대한 제약 조건 중 하나입니다.

calico CNI vs VPC CNI

Calico CNI에는 오버레이를 통해 노드간 통신이 가능한 반면, VPC CNI는 VPC 와 같은 대역을 활용하기 때문에 파드간 통신을 같은 네트워크 내에서 가능합니다.

네트워크

노드의 기본 네트워크

워커 노드에서 Private IP와 Secondary Private IP가 있는 것을 확인할 수 있습니다.

secondary private IP를 사용하는지 확인하기 위해 파드를 생성해보겠습니다.

cat <<EOF | kubectl apply -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

새로운 파드를 생성하니, 보조 프라이빗 IP를 사용합니다.

# network 정보 조회
ip -br -c addr show
ip -c link
ip -c addr
ip route # 혹은 route -n

노드간 파드 통신

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

파드에서 외부 통신

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

파드 생성 제한

Secondary IPv4 addresses (기본값) : 인스턴스 유형에 최대 ENI 갯수와 할당 가능 IP 수를 조합하여 선정

인스턴스 타입 별 ENI 최대 갯수와 할당 가능한 최대 IP 갯수에 따라서 파드 배치 갯수가 결정됨
단, aws-node 와 kube-proxy 파드는 호스트의 IP를 사용함으로 최대 갯수에서 제외함

최대 파드 생성 갯수 : (Number of network interfaces for the instance type × (the number of IP addressess per network interface - 1)) + 2

인스턴스의 MaxENI 테이블 확인하는 방법

aws ec2 describe-instance-types --filters Name=instance-type,Values=t3.* \
 --query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
 --output table

최대 파드 생성 확인

# 디플로이먼트 생성
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/2/nginx-dp.yaml
kubectl apply -f nginx-dp.yaml

# 파드 증가 to 8
kubectl scale deployment nginx-deployment --replicas=8

# 파드 증가 to 50
kubectl scale deployment nginx-deployment --replicas=50

현재까지는 요청한 파드가 모두 생성되고 있음을 확인할 수 있습니다.

파드 갯수를 50개로 늘리자 Pending 인 파드가 하나씩 보이기 시작합니다.

Pending인 파드의 수를 세보니 10개로 확인됩니다.

t3.medium 노드 3대에는 각각 17개의 파드가 생성되어 있는 것을 알 수 있습니다. 이 수를 넘어서는 파드를 생성할 수 없기 때문에 현재 모드에서 노드당 지원하는 파드 수를 알아두어야 합니다.

이를 해결하기 위한 방법으로 IPv4 Prefix Delegation을 활용할 수 있습니다.

접두사 모드를 활용하면 ENI당 16개의 IPv4를 활용할 수 있습니다.

https://www.eksworkshop.com/docs/networking/vpc-cni/prefix/

Prefix Delegation | EKS Workshop

Increase pod density on Amazon Elastic Kubernetes Service with prefix delegation.

www.eksworkshop.com

Service, loadbalancer controller

k8s의 서비스는

ClusterIP

NodePort

LoadBalancer (NLB 인스턴스 유형)

LoadBalancer (NLB IP모드 동작 with AWS VPC CNI)

가 있습니다.

ClusterIP 는 파드의 요청을 Control Plane의 iptables의 rule를 통해 각 node의 pod로 전달해줍니다.

NodePort 는 각요청을 Data Plane의 노드 내에 있는 iptables의 rule을 통해 대상 pod로 전달해줍니다.

Loadblancer는 별개의 로드밸런서 리소스가 요청을 각 노드의 iptables로 전달, iptables rule에 의해 대상 pod 로 요청을 전달합니다.

이때 AWS VPC CNI 구성에서 NLB IP모드에서는 로드밸런서가 각각의 파드 ip를 알고 파드로 요청을 바로 전달하는 유형입니다.

Ingress

인그레스는 클러스터 내부의 서비스 (ClusterIP, NodePort, LoadBalancer)를 외부로 노출하는 proxy 역할을 제공해주는 리소스입니다.

ExternalDNS

서비스나 인그레스 생성시에 설정된 도메인 (AWS Route53과 같은)에 레코드를 자동으로 생성/삭제 해주는 리소스입니다.

이를 활용하기 위해서는 route53에 public domain을 소유하고 있어야 합니다. 또한 ExternalDNS 리소스가 직접 route53에 접근해야하므로, IRSA 혹은 pod-identity와 같은 자격증명을 필요로합니다.

[KANS 3기] 8주차 Cilium CNI

엔지니어-여리 — Sat, 26 Oct 2024 22:24:20 +0900

이번 주는 Cilium CNI에 대해서 공부한 내용을 정리해보고자 합니다.

실습 환경 구성

배포

실습환경 구성은 이전에 한 방법과 같이 cloudformation template를 배포합니다.

#cloudformation template url
https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-8w.yaml

clouformation template은 3분이내에 배포가 완료되지만, 생성된 ec2의 userdata가 모두 구성되는데 시간이 소요될 수 있습니다.

배포 후 5~7분 정도 지난 후 접속해보시는 걸 권장드립니다.

배포확인

배포가 완료되었는지 확인을 위해 ssh 접속한 뒤, 환경을 확인해보겠습니다.

클러스터 기본 정보 확인
kubectl cluster-info

# 노드 상태 확인
kc get node -owide

# 모든 파드 정보를 확인합니다.
kc get pod -A

hostnamectl

# cilium이 제대로 동작하기 위해서는 커널 버전을 5.8 이상으로 설정해야합니다.
uname -a

간단한 명령어로 클러스터 상태를 확인할 수 있습니다.

Cilium 소개

- cilium은 eBPF 기반으로 Pod Network 환경 + 보안을 제공하는 CNI plugin 입니다.

- 추가적인 App이나 설정 변경 없이 리눅스 커널을 자유롭게 프로그래밍하여 동작합니다.

- 모든 패킷을 가로채기 위해 수신 NIC의 Ingress TC Hook을 사용합니다.

- 네트워크 모드는 2가지 지원합니다. 터널모드 (VXLAN, GENEVE), 네이티브 라우팅 모드

- kube-proxy 가 없습니다.

BPF, eBPF

전통적인 리눅스 네트워크 스택에서는 netfilter / iptables를 기반으로 동작합니다. iptables를 활용한 방식은 쿠버네티스 클러스터가 동작하는 동안 패킷을 처리하는 데 레이어를 건너뛰기 어렵습니다. (규칙이 일치될 때까지 모든 규칙을 평가합니다.) 이를 해결하기 위해 BPF, eBPF가 등장하였습니다.

eBPF의 동작은 아래 그림과 같습니다.

기존의 iptables에서 패킷필터를 처리하는 게 아닌 eBPF는 커널 샌드박스에서 구성된 dynamic programming에 의해 필터링 되어 더 나은 성능을 제공할 수 있습니다.

eBPF에서 제공하는 기능은 대표적으로 4가지 입니다.

성능 비교

영역에 따른 패킷 차단 성능 (10GB)

네트워크 구조

성능 표

Userspace: Device Driver - Ingress - Proto Handler - Routing - Input - Upper Layer (L4 ~)

Netfilter : Device Driver - Ingress - Proto Handler - Routing - Input (L4)

TC : Device Driver - Ingress (L3)

XDP: Device Driver (L2)

Architecture

cilium architecture에 대한 자세한 설명은 https://www.youtube.com/watch?v=LCQ89uBB7zE 링크에 자세한 설명이 포함되어 있습니다.

그밖에 cilium

Cilium Agent : 데몬셋으로 실행, K8S API 설정으로 부터 '네트워크 설정, 네트워크 정책, 서비스 부하분산, 모니터링' 등을 수행하며, eBPF 프로그램을 관리한다.
Cilium Operator : K8S 클러스터에 대한 한 번씩 처리해야 하는 작업을 관리.
Hubble : 네트워크와 보안 모니터링 플랫폼 역할을 하여, 'Server, Relay, Client, Graphical UI' 로 구성되어 있다.
Data Store : Cilium Agent 간의 상태를 저장하고 전파하는 데이터 저장소, 2가지 종류 중 선택(K8S CRDs, Key-Value Store)

또한 cilium 커맨드라인 도구로 cilium-cli가 있습니다.

배포

# cilium helm repo 추가
helm repo add cilium https://helm.cilium.io/
helm repo update

# cilium helm chart 설치
helm install cilium cilium/cilium --version 1.16.3 --namespace kube-system \
--set k8sServiceHost=192.168.10.10 --set k8sServicePort=6443 --set debug.enabled=true \
--set rollOutCiliumPods=true --set routingMode=native --set autoDirectNodeRoutes=true \
--set bpf.masquerade=true --set bpf.hostRouting=true --set endpointRoutes.enabled=true \
--set ipam.mode=kubernetes --set k8s.requireIPv4PodCIDR=true --set kubeProxyReplacement=true \
--set ipv4NativeRoutingCIDR=192.168.0.0/16 --set installNoConntrackIptablesRules=true \
--set hubble.ui.enabled=true --set hubble.relay.enabled=true --set prometheus.enabled=true --set operator.prometheus.enabled=true --set hubble.metrics.enableOpenMetrics=true \
--set hubble.metrics.enabled="{dns:query;ignoreAAAA,drop,tcp,flow,port-distribution,icmp,httpV2:exemplars=true;labelsContext=source_ip\,source_namespace\,source_workload\,destination_ip\,destination_namespace\,destination_workload\,traffic_direction}" \
--set operator.replicas=1

# 변수 설명
--set debug.enabled=true # cilium 파드에 로그 레벨을 debug 설정
--set autoDirectNodeRoutes=true # 동일 대역 내의 노드들 끼리는 상대 노드의 podCIDR 대역의 라우팅이 자동으로 설정
--set endpointRoutes.enabled=true # 호스트에 endpoint(파드)별 개별 라우팅 설정
--set hubble.relay.enabled=true --set hubble.ui.enabled=true # hubble 활성화
--set ipam.mode=kubernetes --set k8s.requireIPv4PodCIDR=true # k8s IPAM 활용
--set kubeProxyReplacement=true # kube-proxy 없이 (최대한) 대처할수 있수 있게
--set ipv4NativeRoutingCIDR=192.168.0.0/16 # 해당 대역과 통신 시 IP Masq 하지 않음, 보통 사내망 대역을 지정
--set operator.replicas=1 # cilium-operator 파드 기본 1개
--set enableIPv4Masquerade=true --set bpf.masquerade=true # 파드를 위한 Masquerade , 추가로 Masquerade 을 BPF 로 처리 >> enableIPv4Masquerade=true 인 상태에서 추가로 bpf.masquerade=true 적용이 가능

실제 환경에 적용하면 다음 영상과 같이 cilium을 helm chart로 설치하고 파드가 생성되는 것을 확인할 수 있습니다.

cilium을 설치하게 되면 이전에 pending 상태였던 파드들이 배포되는 것을 알 수 있습니다. 이는 cilium이 kube-proxy를 사용하지 않으므로 처음에 배포했던 cloudformation template에서는 kube-proxy를 제외하고 설치하였기 때문에 kube-proxy가 없어 pod가 배포되지 않았었고, kube-proxy를 대체할 수 있는 cilium CNI가 구성되어 생성 대기중이던 pod가 배포되기 시작하였기 때문입니다.

cilium 설치시 생성되는 파드중 cilium envoy는 최소한의 Envoy 확장 및 사용자 지정 정책 적용 필터로 구축됩니다. Cilium은 이 최소한의 배포를 클러스터의 네트워크 정책에 지정된 대로 HTTP 및 기타 L7 정책을 적용하기 위한 호스트 프록시로 사용합니다. 실리움 프록시는 실리움 이미지 내에 배포됩니다.

다른 cni와 다르게 cilium을 구성하면 iptables가 한 눈에 보일정도로 짧아지는 것을 확인할 수 있습니다.

CLI 설치

# Cilium CLI 설치
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

간단한 명령어로 cilium cli를 설치할 수 있습니다. 이때 architecture를 잘 설정하여 설치하시기 바랍니다.

cilium이 어떻게 설치되어있는지 한 눈에 볼 수 있으니 파악이 쉽습니다.

설치 정보 확인

# 확인
cilium status --wait
cilium config view

명령어 한 줄로 cilium 설정 정보 확인을 할 수 있습니다.

export CILIUMPOD0=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-s  -o jsonpath='{.items[0].metadata.name}')
alias c0="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- cilium"
c0 status --verbose

데몬셋 파드 내에서 cilium cli 명령어로 설정을 확인할 수 있습니다.

kubeProxyReplacement 즉 kube-proxy 없이 동작을 대처한다는 옵션이 잘 설정되어 있음을 확인할 수 있습니다.

아래에는 관련 설정 값들을 확인할 수 있습니다.

IPAM이 설정되어 각 노드별로 등록되어있음을 확인할 수 있습니다.

BPF 맵의 사이즈를 확인할 수 있습니다.

agent 기반의 ip masquerading을 켜기 위해 아래 명령어를 실행해줍니다.

helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values --set ipMasqAgent.enabled=true

이렇게 cilium 설정이 변경되면 자동으로 cilium 파드가 재생성되는 것을 확인할 수 있습니다.

export CILIUMPOD0=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-s  -o jsonpath='{.items[0].metadata.name}')
alias c0="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- cilium"
c0 status --verbose | grep Masquerading

설정을 확인하기 위해 다시 명령어를 입력해보면 다음과 같은 내용을 확인할 수 있습니다.

변수 및 약어 설정

# cilium 파드 이름
export CILIUMPOD0=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-s  -o jsonpath='{.items[0].metadata.name}')
export CILIUMPOD1=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-w1 -o jsonpath='{.items[0].metadata.name}')
export CILIUMPOD2=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-w2 -o jsonpath='{.items[0].metadata.name}')

# 단축키(alias) 지정
alias c0="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- cilium"
alias c1="kubectl exec -it $CILIUMPOD1 -n kube-system -c cilium-agent -- cilium"
alias c2="kubectl exec -it $CILIUMPOD2 -n kube-system -c cilium-agent -- cilium"

alias c0bpf="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- bpftool"
alias c1bpf="kubectl exec -it $CILIUMPOD1 -n kube-system -c cilium-agent -- bpftool"
alias c2bpf="kubectl exec -it $CILIUMPOD2 -n kube-system -c cilium-agent -- bpftool"

# Hubble UI 웹 접속
kubectl patch -n kube-system svc hubble-ui -p '{"spec": {"type": "NodePort"}}'
HubbleUiNodePort=$(kubectl get svc -n kube-system hubble-ui -o jsonpath={.spec.ports[0].nodePort})
echo -e "Hubble UI URL = http://$(curl -s ipinfo.io/ip):$HubbleUiNodePort"

# 자주 사용 명령
helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values --set
kubetail -n kube-system -l k8s-app=cilium --since 12h
kubetail -n kube-system -l k8s-app=cilium-envoy --since 12h

추가로, cilium의 cheat sheet도 공유하겠습니다. 원본 파일은 https://isovalent.com/blog/post/cilium-cheat-sheet/에서 다운로드 받을 수 있습니다.

Cilium Cheat Sheet - Master the Cilium CLI to Manage and Configure your Kubernetes Network - Isovalent

Download the Cilium Cheat Sheet - helping you get to master the Cilium CLI, produced by the creators of Cilium

isovalent.com

Isovalent - Cilium Cheat Sheet.pdf

12.74MB

앞서 설정한 단축어를 활용하면 다음과 같은 방식으로 활용할 수 있습니다.

# cilium 파드 확인
kubectl get pod -n kube-system -l k8s-app=cilium -owide

# cilium 파드 재시작
kubectl -n kube-system rollout restart ds/cilium
혹은
kubectl delete pod -n kube-system -l k8s-app=cilium

# cilium 설정 정보 확인
cilium config view

# cilium 파드의 cilium 상태 확인
c0 status --verbose

# cilium 엔드포인트 확인
kubectl get ciliumendpoints -A
c0 endpoint list

cilium 데몬셋 파드의 cilium 상태 확인

ip 목록 조회

c0에 해당하는 파드에 설정된 서비스 목록 등을 확인할 수 있습니다.

Hubble UI

통신 및 서비스와 네트워킹 인프라의 동작에 대한 심층적인 가시성을 완전히 투명한 방식으로 제공하는 관찰성을 제공하는 도구

애플리케이션 코드 수정 등 추가 설정 없이 동작합니다.

서비스, 파드, id 기반으로 모니터링/제어를 제공합니다.

Hubble relay를 활용하여 전체 클러스터, 클러스터 메시 환경에서 클러스터에 대한 가시성을 제공합니다.

kubectl patch -n kube-system svc hubble-ui -p '{"spec": {"type": "NodePort"}}'
HubbleUiNodePort=$(kubectl get svc -n kube-system hubble-ui -o jsonpath={.spec.ports[0].nodePort})
echo -e "Hubble UI URL = http://$(curl -s ipinfo.io/ip):$HubbleUiNodePort"

Cilium 구성요소중 Hubble의 UI 접근을 위해 service type을 nodeport로 변경하여 접속합니다.

url로 접속하면 다음과 같은 페이지에 접근가능합니다.

네임스페이스를 선택하여 hubble UI에 접근 가능합니다. 원하는대로 트래픽을 필터링할 수 있습니다.

네트워크

패킷 흐름

Endpoint to Endpoint

Egress from Endpoint

Ingress to Endpoint

노드간 파드 통신

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: netpod
  labels:
    app: netpod
spec:
  nodeName: k8s-s
  containers:
  - name: netshoot-pod
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Pod
metadata:
  name: webpod1
  labels:
    app: webpod
spec:
  nodeName: k8s-w1
  containers:
  - name: container
    image: traefik/whoami
  terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Pod
metadata:
  name: webpod2
  labels:
    app: webpod
spec:
  nodeName: k8s-w2
  containers:
  - name: container
    image: traefik/whoami
  terminationGracePeriodSeconds: 0
EOF

위 코드블럭을 사용하여 파드를 생성합니다.

3개의 파드가 배포됩니다.

c0 status --verbose | grep Allocated -A5
c1 status --verbose | grep Allocated -A5
c2 status --verbose | grep Allocated -A5

앞에서 설정한 단축어(alias)로 cilium 의 상태를 확인해보겠습니다.

# cilium endpoint 조회
kubectl get ciliumendpoints
kubectl get ciliumendpoints -A

# c0 cilium pod의 endpoint 목록 조회
c0 endpoint list

# c0 cilium pod의 bpf endpoint 목록 조회
c0 bpf endpoint list

# c0 cilium pod bpf map 중 cilium_lxc 조회
c0 map get cilium_lxc

# c0 ip 조회
c0 ip list

파드간 통신을 위해 이번에도 단축어를 지정해줍니다.

# 테스트 파드들 IP
NETPODIP=$(kubectl get pods netpod -o jsonpath='{.status.podIP}')
WEBPOD1IP=$(kubectl get pods webpod1 -o jsonpath='{.status.podIP}')
WEBPOD2IP=$(kubectl get pods webpod2 -o jsonpath='{.status.podIP}')

# 단축키(alias) 지정
alias p0="kubectl exec -it netpod  -- "
alias p1="kubectl exec -it webpod1 -- "
alias p2="kubectl exec -it webpod2 -- "

이후, 파드에 통신을 보내보겠습니다.

# netpod 네트워크 정보 확인
p0 ip -c -4 addr
p0 route -n
p0 ping -c 1 $WEBPOD1IP && p0 ping -c 1 $WEBPOD2IP
p0 curl -s $WEBPOD1IP && p0 curl -s $WEBPOD2IP
p0 curl -s $WEBPOD1IP:8080 ; p0 curl -s $WEBPOD2IP:8080
p0 ping -c 1 8.8.8.8 && p0 curl -s wttr.in/seoul
p0 ip -c neigh

파드 0 에서 파드 1로 요청하는 경우, 파드 0 에서 파드 2로 요청하는 경우,

파드 0에서 파드 1로 8080포트로 요청하는 경우, 파드 0에서 파드 2로 8080포트로 요청하는 경우

파드 0에서 8.8.8.8 (google dns)로 요청하는 경우, 파드0에서 wttr.in/seoul (날씨 사이트로 요청하는 경우)

를 한번에 보내봤습니다. 통신이 잘 되는 것을 확인할 수 있습니다.

Hubble에서 마찬가지로 각 파드간 통신 기록을 즉각적으로 확인할 수 있습니다. 상세정보를 확인하고자 하는 내역을 클릭하면 자세한 정보가 추가로 나타납니다.

서비스 통신

(좌) 네트워크 기반 로드밸런싱 vs (우) 소켓 기반 로드밸런싱

동작하는 앱이 connect() 시스템콜을 이용하여 소켓을 연결할 때 목적지 주소가 서비스 주소(10.10.8.55)이면 소켓의 목적지 주소를 바로 백엔드 주소(10.0.0.31)로 설정합니다.

이후 앱에서 해당 소켓을 통해 보내는 모든 패킷의 목적지 주소는 이미 백엔드 주소(10.0.0.31)로 설정되어 있기 때문에 중간에 DNAT 변환 및 역변환 과정이 필요없어집니다. (network hop이 줄어듬)

socket send/recv: socket send/recv hook은 TCP 소켓의 모든 송/수신 작업에서 실행되고 hook에서 검사/삭제/리다이렉션 하게 되빈다. 즉, Pod 내에서 Syscall에 Hook을 걸어 요청을 변경해버립니다. (아주 빠름)

실습

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Service
metadata:
  name: svc
spec:
  ports:
    - name: svc-webport
      port: 80
      targetPort: 80
  selector:
    app: webpod
  type: ClusterIP
EOF

코드 블록를 실행해줍니다.

# 서비스IP를 변수에 지정
SVCIP=$(kubectl get svc svc -o jsonpath='{.spec.clusterIP}')

# Pod1 에서 Service(ClusterIP) 접속 트래픽 발생
kubectl exec netpod -- curl -s $SVCIP
kubectl exec netpod -- curl -s $SVCIP | grep Hostname

netpod 파드에서 (pod1) 서비스의 IP에 요청을 보내보겠습니다.

실제로 내부에서 어떻게 동작하는지 자세히 살펴봅시다.

kubectl exec netpod -- strace -s 65535 -f -tt curl -s $SVCIP

strace 명령어로 curl 명령이 어떻게 동작했는지 살펴보겠습니다.

302번 라인에서 connect call이 발생합니다. 대상은 10.10.201.234 이 ip는 서비스의 ip입니다. 이때는 서비스의 ip로 요청을 하는 걸 알 수 있습니다.

하지만 바로 다음 라인인 getsockname 에서는 172.16.0.182 아이피로 변경되었습니다. 바로 도착지 pod의 ip인 것을 확인할 수 있습니다.

앞선 그림의 이부분에 해당하는 과정입니다. 이를 통해 service ip (clusterIP)로 요청을 했으나 실제로는 도착지 파드 ip로 바로 연결되어 있음을 알 수 있습니다.

코멘트: network stack을 말도 안되게 간소화 시켜버리는 것 같습니다.

리소스 삭제

kubectl delete pod --all && kubectl delete svc svc

모니터링 (Prometheus & Grafana)

구성

# 배포
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.16.3/examples/kubernetes/addons/prometheus/monitoring-example.yaml
kubectl get all -n cilium-monitoring

# NodePort 설정
kubectl patch svc grafana -n cilium-monitoring -p '{"spec": {"type": "NodePort"}}'
kubectl patch svc prometheus -n cilium-monitoring -p '{"spec": {"type": "NodePort"}}'

접속

# Grafana 웹 접속
GPT=$(kubectl get svc -n cilium-monitoring grafana -o jsonpath={.spec.ports[0].nodePort})
echo -e "Grafana URL = http://$(curl -s ipinfo.io/ip):$GPT"

# Prometheus 웹 접속 정보 확인
PPT=$(kubectl get svc -n cilium-monitoring prometheus -o jsonpath={.spec.ports[0].nodePort})
echo -e "Prometheus URL = http://$(curl -s ipinfo.io/ip):$PPT"

prometheus 웹 접속을 통해서 메트릭 지표를 살펴볼 수 있습니다.

cilium 에서 제공하는 monitoring example 헬름차트에는 cilium dashboard가 기본구성으로 포함되어 있습니다.

cilium metric 을 확인할 수 있는 대시보드 cilium cni의 모니터링을 하기위한 목적으로 사용할 수 있습니다.

Hubble UI에서 확인할 수 있는 지표를 Grafana에서도 Prometheus를 통해 함께 확인할 수 있습니다.

Network Policy (L3, L4, L7)

ID 기반 (L3)

파드의 label을 활용하여 엔드포인트간의 연결을 제어합니다.
label role=frontend가 있는 모든 엔드포인트는 label role=backend가 있는 모든 엔드포인트에 연결할 수 있습니다.

Port 기반 (L4)

들어오는 요청/나가는 요청에 대해서 허용할 포트를 제한할 수 있습니다.
예를 들어, 위 그림에서 label이 role=frontend인 엔드포인트는 포트 443(https)에서만 나가는 연결을 만들 수 있습니다.
엔드포인트 role=backend는 포트 443(https)에서만 연결을 허용할 수 있습니다.

애플리케이션 기반 (L7)

암호화된 HTTP 및 원격 프로시저 호출(RPC) 프로토콜을 위해 애플리케이션 수준에서 세분화된 액세스 제어를 제공합니다.
label role=frontend이 있는 엔드포인트는 REST API 호출 GET/userdata/[0-9]+만 수행할 수 있습니다.
role=backend가 있는 다른 모든 API 상호 작용은 제한됩니다.

실습

스타워즈 데모

# 리소스 배포
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/1.16.3/examples/minikube/http-sw-app.yaml

배포 후 파드의 label을 확인합니다.

리소스가 모두 배포된 뒤 실습 전 endpoint 정보를 확인하겠습니다.

# xwing 파드에서 deathstar service로 요청
kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

# tiefighter 파드에서 deathstar service로 요청
kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

이후 xwing 파드에 접속하여, 데스스타 service로 요청을 보내보겠습니다.

곧바로 tiefighter에서도 deathstar 서비스로 요청을 보내보겠습니다.

이제, hubble ui를 접속하면 xwing, tiefighter 가 데스스타에 잘 착륙(landing)한 것을 확인할 수 있습니다.

이제 xwing이 착륙하지 못하도록 해보겠습니다.

cat <<EOF | kubectl apply -f -
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L3-L4 policy to restrict deathstar access to empire ships only"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
EOF

데스스타에 착륙(요청) 가능한 파드는 org=empire 라벨이 할당된 tiefighter 가 될겁니다.

다시 curl을 사용하여 데스스타에 착륙 요청을 시도합니다.

예상과 동일하게 tiefighter는 landing(request) 가능한 반면, xwing은 요청이 차단됩니다. 이 또한 hubble ui에서 확인 가능합니다.

L2 Announcements / L2 Aware LB (beta)

소개

L2 Announcements는 로컬 영역 네트워크에서 서비스를 표시하고 도달 가능하게 만드는 기능입니다. 이 기능은 주로 사무실 또는 캠퍼스 네트워크와 같이 BGP 기반 라우팅이 없는 네트워크 내에서 온프레미스 배포를 위해 고안되었습니다.
이 기능을 사용하면 ExternalIP 및/또는 LoadBalancer IP에 대한 ARP 쿼리에 응답합니다. 이러한 IP는 여러 노드의 가상 IP(네트워크 장치에 설치되지 않음)이므로 각 서비스에 대해 한 번에 한 노드가 ARP 쿼리에 응답하고 MAC 주소로 응답합니다. 이 노드는 서비스 로드 밸런싱 기능으로 로드 밸런싱을 수행하여 북쪽/남쪽 로드 밸런서 역할을 합니다.
NodePort 서비스에 비해 이 기능의 장점은 각 서비스가 고유한 IP를 사용할 수 있으므로 여러 서비스가 동일한 포트 번호를 사용할 수 있다는 것입니다. NodePort를 사용할 때 트래픽을 보낼 호스트를 결정하는 것은 클라이언트에게 달려 있으며 노드가 다운되면 IP+Port 콤보를 사용할 수 없게 됩니다. L2 공지를 사용하면 서비스 VIP가 다른 노드로 간단히 마이그레이션되고 계속 작동합니다.

실습

helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \
--set l2announcements.enabled=true --set externalIPs.enabled=true \
--set l2announcements.leaseDuration

# 설정 확인
c0 config --all  |grep L2

# CiliumL2AnnouncementPolicy 생성
cat <<EOF | kubectl apply -f - 
apiVersion: "cilium.io/v2alpha1"
kind: CiliumL2AnnouncementPolicy
metadata:
  name: policy1
spec:
  serviceSelector:
    matchLabels:
      color: blue
  nodeSelector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: DoesNotExist
  interfaces:
  - ^ens[0-9]+
  externalIPs: true
  loadBalancerIPs: true
EOF

# CiliumL2AnnouncementPolicy 생성 확인
kubectl get ciliuml2announcementpolicy
kc describe l2announcement

# CiliumLoadBalancerIPPool 생성
cat <<EOF | kubectl apply -f - 
apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
  name: "cilium-pool"
spec:
  allowFirstLastIPs: "No"
  blocks:
  - cidr: "10.10.200.0/29"
EOF

# cilium ip pool 조회
kubectl get CiliumLoadBalancerIPPool

예제 코드를 실행하여 간단히 구성한 뒤, 설정을 확인할 수 있습니다.

테스트 파드 생성

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: webpod1
  labels:
    app: webpod
spec:
  nodeName: k8s-w1
  containers:
  - name: container
    image: traefik/whoami
  terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Pod
metadata:
  name: webpod2
  labels:
    app: webpod
spec:
  nodeName: k8s-w2
  containers:
  - name: container
    image: traefik/whoami
  terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Service
metadata:
  name: svc1
spec:
  ports:
    - name: svc1-webport
      port: 80
      targetPort: 80
  selector:
    app: webpod
  type: LoadBalancer  # 서비스 타입이 LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: svc2
spec:
  ports:
    - name: svc2-webport
      port: 80
      targetPort: 80
  selector:
    app: webpod
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: svc3
spec:
  ports:
    - name: svc3-webport
      port: 80
      targetPort: 80
  selector:
    app: webpod
  type: LoadBalancer
EOF

이렇게 클라우드 환경이 아닌 온프레미스 환경에서 loadbalancer 유형의 서비스를 활용할 수 있습니다.

XDP

Cilium에서 XDP를 활용하기 위해서는 NIC (Network Interface Controller) 혹은 ENI (Elastic Network Interface, AWS)에서 XDP처리를 지원해야 합니다.

aws ec2 에서 xdp 지원여부 확인하기

터미널 내에서 xdp를 지원하는 nic인지 확인하기 위해서는 ethtool을 사용하여 확인할 수 있습니다.

먼저 ifconfig 명령어로 네트워크 인터페이스를 확인해야합니다.

이후 ethtool 명령어로 네트워크 인터페이스 정보를 조회합니다.

AWS에서 향상된 네트워킹 기능 활성화하는 가이드 문서

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/enhanced-networking-ena.html#enabling_enhanced_networking

ENA 활성화 여부 확인하기

# ubuntu
apt upgrade
apt install -y -q awscli 



# ena 지원하는 인스턴스 여부 확인
AMI_ID=$(curl 169.254.169.254/latest/meta-data/ami-id)
aws ec2 describe-images --image-id $AMI_ID --query "Images[].EnaSupport"

# nic driver 확인
ethtool -i ens5

AWS EC2 인스턴스에 장착된 네트워크 인터페이스는 3종류입니다. (ENI, ENA, EFA) 기본적으로는 ENI가 장착되어있고 성능은 ENI < ENA < EFA 순으로 좋습니다.

aws에서 xdp를 지원하기 시작한 시점은 2020년 1월로 보입니다. ena driver 2.2.0 부터 지원하는 것으로 확인됩니다.

https://github.com/amzn/amzn-drivers/issues/8

최신 인스턴스에는 당연히 이전 드라이버가 있진 않을거라 문제되진 않을 것 같습니다.

XDP 사용을 위해 ENA이상의 네트워크 어댑터를 지원하는 인스턴스를 활용하면 될 것으로 보입니다.

AWS Nitro network system에 구축된 인스턴스는 모두 ENA를 지원한다고 합니다.

Nitro System에 포함된 인스턴스 목록

https://docs.aws.amazon.com/ko_kr/ec2/latest/instancetypes/ec2-nitro-instances.html#nitro-instance-types

AWS Nitro 시스템에 구축된 인스턴스 - Amazon EC2

ENA FreeBSD v2.3.1 이전의 드라이버 버전은 지원되지 않으므로 탄력적 네트워크 인터페이스 연결 실패가 발생합니다.

docs.aws.amazon.com

Nitro System의 이전 세대 지원

https://aws.amazon.com/ko/ec2/faqs/#Nitro_System_Support_for_Previous_Generation

Amazon EC2 FAQ - AWS

aws.amazon.com

회고

스터디가 마친 뒤에는 온프레미스 클러스터를 Cilium 으로 구성하여 다양한 작업을 진행해보고 싶어졌습니다.

혼자 공부하기에 어려웠던 네트워킹 지식을 가시다님 스터디를 통해서 시간 절약을 많이 했습니다. 모든 내용을 이해하진 못했지만 필요한 내용을 찾아서 공부할 정도는 되었다고 생각하여 알차게 복습 또 복습하고자 합니다.

[KANS 3기] 7주차 Service Mesh - Istio

엔지니어-여리 — Wed, 16 Oct 2024 01:23:26 +0900

실습환경 구성

실습 template

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-7w.yaml

위 url을 cloudformation stack 으로 실행합니다.

stack name, keyName 등을 적절히 선택해줍니다.

cloudformation에서 생성된 리소스는 다음과 같이 확인이 가능합니다.

Istio 소개

개요

MSA 환경에서 시스템 전체의 모니터링의 어려움과 운영 중 장애 발생시 원인과 문제점을 찾기가 어려워졌습니다. 이를 해결하기 위해 네트워크 통신의 안정성과 보안, o11y 등의 요구사항이 증가하였습니다. 이런 문제점들의 해결책으로 서비스메시가 등장하였습니다. istio는 서비스메시의 구현체중 하나로 데이터 플레인과 컨트롤 플레인이 존재합니다. 데이터플레인은 envoy proxy를 사이드카로 활용하고, 컨트롤 플레인은 이러한 envoy proxy를 관리하고 구성합니다.

istio는 2가지 모드를 제공하고 2가지 모드에 대해서 설명하겠지만 sidecar pattern에 대해서 더 자세히 다룰 예정입니다.

구성

istio는 control plane과 data plane이라는 영역으로 논리적으로 나뉩니다. data plane은 sidecar 형태로 배포된 일종의 지능형 proxy 입니다. 이러한 프록시는 microservice 사이의 모든 네트워크 통신을 중개하고 제어합니다. 또한 모든 메시 트래픽에 대한 원격 분석을 수집(collect)하고 보고(report) 합니다. control plane은 트래픽 라우팅을 위해 프록시를 관리하고 구성합니다.

istio는 각 pod 내에 sidecar 혀앹로 envoy proxy가 포함된 형태

Control Plane

1.5 버전 이전에는 Pilot, Citadel, Galley, Mixer 4가지 구성을 포함했습니다. 1.5 버전 이후에는 Mixer를 제외한 3가지 구성요소를 istiod라는 단일 구성으로 통합되었습니다.

Pilot: envoy sidecar에서 proxy routing rule을 관리, service discovery, load balancing 설정을 제공합니다.
Citadel: 보안 기능을 담당하며 TLS 인증서 발급 및 관리를 통해 서비스간 통신 암호화를 수행합니다.
Gally: istio와 쿠버네티스를 연결해주는 역할을 합니다.

Data Plane

istio는 확장된 버전의 envoy proxy를 사용합니다. 엔보이는 모든 인바운드 아웃바운드 트래픽을 중 개(mediate)하기위해서 c++로 개발된 고성능 프록시입니다.

envoy 가 하는일

Dynamic service discovery
로드밸런싱
TLS 종료
HTTP/2 and gRPC proxies
서킷 브레이커
헬스체크
Staged rollouts with %-based traffic split
Fault injection
Rich metrics

장점

사이드카 배포를 통해 원격 분석, 모니터링시스템 전송을 활용하여 전체 메시 동작 정보를 제공할 수 있습니다.
코드 재설계 없이 기존 배포에 istio 기능을 추가할 수 있습니다.

Envoy

개요

Envoy는 대규모 최신 서비스 지향 아키텍처를 위해 설계된 L7 프록시 및 통신 버스입니다. envoy는 '네트워크는 애플리케이션에 투명해야 한다'는 신념 아래에 탄생하였습니다. 결국 네트워크와 애플리케이션의 문제가 발생했을 때 문제 원인을 쉽게 파악하기 위한 목적으로 탄생한 것입니다.

envoy에서 사용되는 몇가지 단어가 있습니다.

Host: 네트워크 통신이 가능한 entity를 말합니다. logical network application을 뜻합니다.

Downstream: downstream host는 envoy에 요청을 전달하고, 응답을 받습니다.

Upstream: Upstream host는 envoy로부터 요청을 전달받고 응답을 반환합니다.

Listener: downstream client에 의해 연결된 포트, 유닉스 도메인 소켓과 같은 네트워크 영역을 말합니다. envoy는 downstream host가 연결할 수 있는 1개 이상의 listener를 노출합니다.

Cluster: envoy 가 트래픽을 포워드할 수 있는 논리적인 서비스 (엔드포인트 세트), 실제 요청이 처리되는 IP 또는 엔드포인트의 묶음을 의미합니다.

요청 흐름도.

출처: https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#high-level-architecture

SideCar 모드

설치

istioctl 설치 및 실습 설정

export ISTIOV=1.23.2
echo "export ISTIOV=1.23.2" >> /etc/profile
curl -s -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIOV TARGET_ARCH=x86_64 sh -
tree istio-$ISTIOV -L 2 # sample yaml 포함
cp istio-$ISTIOV/bin/istioctl /usr/local/bin/istioctl
istioctl version --remote=false

먼저, 실습환경 구성때만든 k3s-s 서버에 ssh를 통해서 접속합니다.

istioctl 설치 코드블록을 복사 및 적용하여 istioctl을 설치합니다.

현재 설치된 istioctl profile을 조회합니다.

우리는 이중 demo profile을 활용합니다. 설정을 조금 변경하도록 하겠습니다.

istioctl profile dump demo > demo-profile.yaml

명령을 통해, profile을 dump 해줍니다. 여기서 egressGateways를 비활성화로 변경합니다.

istioctl install 명령을 사용하여 변경된 demo profile을 적용해줍니다.

ingressgateway 살펴보기

적용이 잘 되었는지 확인합니다.

 kubectl get all,svc,ep,sa,cm,secret,pdb -n istio-system

svc: service

ep: endpoint

sa: service account

cm: configmap

pdb: pod disruption budget

 kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec":{"type":"NodePort"}}'

istio-ingressgateway 서비스의 서비스타입이 LoadBalancer 입니다. 이를 NodePort로 변경해줍니다.

이때 istio-ingressgateway pod는 여러 포트를 노출하고 있습니다.

kubectl get service -n istio-system istio-ingressgateway -o jsonpath='{.spec.ports}' | jq

각각의 포트는 위 명령어를 통해 확인할 수 있습니다. 15021 포트는 health check목적으로 사용됩니다.

그밖에 사용되는 port는 istio 공식 문서를 참조할 수 있습니다.

https://istio.io/latest/docs/ops/deployment/application-requirements/

istio 외부 노출

설정

# port 설정
export IGWHTTP=$(kubectl get service -n istio-system istio-ingressgateway -o jsonpath='{.spec.ports[1].nodePort}')

# /etc/hosts 파일 수정
MYDOMAIN=www.yeoli.io
echo "192.168.10.10 $MYDOMAIN" >> /etc/hosts
echo -e "export MYDOMAIN=$MYDOMAIN" >> /etc/profile

# istio ingress gw 접속 테스트 : 아직은 설정이 없어서 접속 실패가 된다
curl -v -s $MYDOMAIN:$IGWHTTP

### istio sidecar injection practice ###

# istio의 injection을 허용하는 네임스페이스를 설정합니다.
kubectl label namespace default istio-injection=enabled

# istio 네임스페이스의 로그를 모니터링합니다.
kubetail -n istio-system -l app=istiod -f

# nginx pod를 생성합니다.
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kans-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-websrv
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deploy-websrv
  template:
    metadata:
      labels:
        app: deploy-websrv
    spec:
      serviceAccountName: kans-nginx
      terminationGracePeriodSeconds: 0
      containers:
      - name: deploy-websrv
        image: nginx:alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip
spec:
  ports:
    - name: svc-webport
      port: 80
      targetPort: 80
  selector:
    app: deploy-websrv
  type: ClusterIP
EOF

Nginx 파드 구성

설정 에서 istio sidecar injection practice 항목을 따라해보겠습니다.

우측에서는 istio-system을 모니터링하고, 좌측에서는 nginx 파드를 생성합니다.

파드가 생성되면서 sidecar injection이 발생하였습니다.

kubectl get pod 명령어로 파드를 조회해보면, 파드 내 컨테이너가 1이 아닌 2인 것을 확인할 수 있습니다. 이를 좀 더 살펴보면, pod 내 정보에서는 init-proxy라는 컨테이너가 함께 구성되는 것을 알 수 있습니다. sidecar injection 형태로 istio의 컨테이너가 생성된 것을 알 수 있습니다.

Gateway/Virtual Service 구성

cat <<EOF | kubectl create -f -
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: test-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: nginx-service
spec:
  hosts:
  - "$MYDOMAIN"
  gateways:
  - test-gateway
  http:
  - route:
    - destination:
        host: svc-clusterip
        port:
          number: 80
EOF

위 manifest를 실행시켜 gateway, virtual service를 생성해줍니다.

생성된 gateway, virtual service는 다음과 같은 설정 정보를 포함하고 있습니다.

# gateway, virtual service 조회
kubectl get gw,vs

# istio proxy status 조회
istioctl ps

명령어를 사용하여 설정된 gateway, vs, proxy 상태를 조회합니다.

자 이제 www.yeoli.io 라는 도메인으로 테스트를 할 준비가 되었습니다.

curl -s $MYDOMAIN:$IGWHTTP | grep -o "<title>.*</title>"

# 결과
Welcome to nginx!

로그

kubetail -n default
Will tail 3 logs...
deploy-websrv-7d7cf8586c-qspjs deploy-websrv
deploy-websrv-7d7cf8586c-qspjs istio-proxy
deploy-websrv-7d7cf8586c-qspjs istio-init



[deploy-websrv-7d7cf8586c-qspjs deploy-websrv] 127.0.0.6 - - [19/Oct/2024:10:18:59 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.10.1" "-"
[deploy-websrv-7d7cf8586c-qspjs istio-proxy] [2024-10-19T10:18:59.053Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 0 0 "-" "curl/8.10.1" "5f7bee9b-d764-9e14-ad4a-a583233d16a8" "10.10.200.134" "172.16.2.8:80" inbound|80|| 127.0.0.6:55867 172.16.2.8:80 172.16.2.8:53002 invalid:outbound_.80_._.svc-clusterip.default.svc.cluster.local default
[deploy-websrv-7d7cf8586c-qspjs istio-proxy] [2024-10-19T10:18:59.053Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 1 0 "-" "curl/8.10.1" "5f7bee9b-d764-9e14-ad4a-a583233d16a8" "10.10.200.134" "172.16.2.8:80" outbound|80||svc-clusterip.default.svc.cluster.local 172.16.2.8:53002 10.10.200.134:80 172.16.2.8:50182 - default

출력 로그 이해하기

출력로그는 위와같은 구조로 구성되어있습니다. 한 번 이해해두시면 로그분석이 필요할 때 손쉽게 사용할 수 있습니다.

모니터링

이러한 복잡한 구조를 매번 확인할 때마다 로그를 보거나 routing rule, kubectl 등으로 확인하는 것은 매우 비효율적일 수 있습니다. 우리는 kiali를 활용하여 서비스 메시의 모니터링을 하고자 합니다.

구성된 실습환경에서 해당 경로에 포함된 리소스를 모두 실행시켜보겠습니다.

kubectl apply -f ~/istio-$ISTIOV/samples/addons # 디렉터리에 있는 모든 yaml 자원을 생성
kubectl rollout status deployment/kiali -n istio-system

# service type을 NodePort로 변경해줍니다.
kubectl patch svc -n istio-system kiali -p '{"spec":{"type":"NodePort"}}'

# grafana service 타입 변경: NodePort
kubectl patch svc -n istio-system grafana -p '{"spec":{"type":"NodePort"}}'

# prometheus service 타입 변경: NodePort
kubectl patch svc -n istio-system prometheus -p '{"spec":{"type":"NodePort"}}'


# kiali nodeport의 포트를 확인합니다.
KIALINodePort=$(kubectl get svc -n istio-system kiali -o jsonpath={.spec.ports[0].nodePort})



# 인터넷 브라우저를 통해 접속할 kiali url을 확인합니다.
echo -e "KIALI UI URL = http://$(curl -s ipinfo.io/ip):$KIALINodePort"


# grafana url도 확인할 수 있습니다.
GRAFANANodePort=$(kubectl get svc -n istio-system grafana -o jsonpath={.spec.ports[0].nodePort})
echo -e "Grafana URL = http://$(curl -s ipinfo.io/ip):$GRAFANANodePort"

kiali의 대시보드 화면입니다. 이 화면에서는 service mesh, istio를 모니터링할 수 있습니다.

kiali에서 일정 기간동안 트래픽 혹은 애플리케이션 정보, 워크로드, 서비스, 메시등의 정보를 모두 확인할 수 있습니다.

물론 prometheus에서도 수집되는 메트릭을 prometheus 서비스의 포트를 통해 브라우저에서 확인할 수 있습니다.

다만 istio, prometheus를 매번 각각의 콘솔에서 확인하는 건 불편합니다. 이를 해결하기 위해 grafana에서 prometheus, istio를 모두 확인할 수 있습니다.

grafana url에 접속하면, istio dashboard를 확인할 수 있습니다.

istio control plane dashboard

istio service dashboard 입니다.

여기까지 istio 모니터링에 대해 살펴보았습니다.

istio 트래픽 흐름

외부 클라이언트로부터 k8s 클러스터 내부의 application 파드로 전달되는 트래픽 흐름은 다음과 같습니다.

1. client 요청은 istio ingress gateway로 전달됩니다.

2. istio ingress gateway로 전달된 요청은 cluster의 node로 전달되고 host namespace로 전달됩니다.

3. host namespace에서 iptables 규칙에 따라 pod namespace로 전달 됩니다.

4. pod namespace내의 iptables 규칙에 따라서 파드 내부의 istio-proxy로 먼저 전달이 됩니다.

5. istio-proxy 컨테이너에서 istio의 iptables 규칙에 따라서 application 컨테이너로 요청이 전달됩니다.

Ambient mode

개요

정환열님의 블로그중 발췌 (https://www.anyflow.net/sw-engineer/istio-ambient-mode)

Ambient mode는 Sidecar mode 하의 Istio 기능을 계승하면서, 더 빠르고 더 적은 리소스를 사용한다. 특히 메모리 사용량 개선은 극적이다.
Ambient mode에서는 Ztunnel(L4)을 데몬셋으로, Waypoint(L7)를 디플로이먼트셋으로 활용하여 istio-proxy의 sidecar를 대체한다.

Waypoint 는 Kubernetes Gateway API의 Gateway 를 통해 Namespace 단위로 생성하는 것이 기본이다. 이는 Waypoint 가 특정 workload 군에 대한 gateway 역할도 함께함을 의미한다.

istio가 없는 구성 (Baseline), Ambient Mode, Sidecar Mode를 비교했을 때 응답 지연차이를 확인할 수 있습니다.

성능은 baseline > ambient > sidecar 순서입니다.

[KANS 3기] 6주차 GatewayAPI

엔지니어-여리 — Sat, 12 Oct 2024 18:37:55 +0900

이전 이야기

앞서, Ingress 에서 Ingress는 더이상 개발이 없다고 언급했습니다. GatewayAPI 리소스가 새롭게 등장하였고, Ingress가 했던 작업을 Gateway API에서 지원되기 때문입니다.

Gateway API

기능

gatewayAPI의 주된 기능은 다음과 같습니다.

개선된 리소스 모델
GatewayClass, Gateway 및 Route(HTTPRoute, TCPRoute 등)와 같은 새로운 사용자 정의(CRD) 리소스를 도입하여 라우팅 규칙을 정의하는 보다 세부적이고 표현력 있는 방법을 제공합니다.
프로토콜 독립적
Gateway API는 TCP, UDP, TLS를 포함한 여러 프로토콜을 지원합니다. (Ingress는 HTTP용으로 설계됨)
강화된 보안
TLS 구성 및 보다 세부적인 액세스 제어에 대한 기본 제공 지원합니다.
교차 네임스페이스 지원
서로 다른 네임스페이스의 서비스로 트래픽을 라우팅하여 보다 유연한 아키텍처를 구축할 수 있는 기능을 제공합니다.
확장성
API는 사용자 정의 리소스 및 정책으로 쉽게 확장할 수 있도록 설계되었습니다.
역할 지향
클러스터 운영자, 애플리케이션 개발자, 보안 팀 간의 우려를 명확하게 분리합니다.

구성요소

API 명세(https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute)

v1 기준 리소스는 4가지 타입이 있습니다. GRPCRoute, Gateway, GatewayClass, HTTPRoute 입니다.

GatewayClass

인프라구성을 제공하는 역할이 구성합니다. 클러스터 수준의 리소스입니다. 게이트웨이 클래스의 변경사항은 기존 게이트웨이 리소스로 전파되지 않습니다. (게이트웨이 클래스 변경으로 인한 문제가 최소한의 장애를 유발하기 위함)

Gateway

클라우드 로드밸런서처럼 인프라스트럭쳐에서 트래픽 핸들링을 정의합니다.

GRPCRoute

게이트웨이 리스너에서 서비스로 gRPC 요청에 대한 라우팅을 위한 Gateway API 유형입니다.

HTTPRoute

게이트웨이 리스너에서 서비스로 HTTP 요청에 대한 라우팅을 위한 Gateway API 유형입니다.

Gloo Gateway

https://docs.solo.io/gateway/latest/about/architecture/

Architecture | Solo.io documentation

Learn more about the components that make up Gloo Gateway. These components work together to provide traffic management, security, and resiliency. Component architecture link The following image shows the different components that make up the Gloo Gateway

docs.solo.io

Architecture

gloo pod의 동작은 다음과 같습니다.

1. The config and secret watcher components in the gloo pod watch the cluster for new Kubernetes Gateway API and Gloo Gateway resources, such as Gateways, HTTPRoutes, or RouteOptions.
2. When the config or secret watcher detect new or updated resources, it sends the resource configuration to the Gloo Gateway translation engine.
3. The translation engine translates Kubernetes Gateway API and Gloo Gateway resources into Envoy configuration. All Envoy configuration is consolidated into an xDS snapshot.
4. The reporter receives a status report for every resource that is processed by the translator.
5. The reporter writes the resource status back to the etcd data store.
6. The xDS snapshot is provided to the Gloo Gateway xDS server component in the gloo pod.
7. Gateway proxies in the cluster pull the latest Envoy configuration from the Gloo Gateway xDS server.
8. Users send a request to the IP address or hostname that the gateway proxy is exposed on.
9. The gateway proxy uses the listener and route-specific configuration that was provided in the xDS snapshot to perform routing decisions and forward requests to destinations in the cluster.

Gloo Gateway control plane

Config watcher

쿠버네티스 게이트웨이 api혹은 (Gateways, HTTPRoutes, and Upstreams)와 같은 글루 게이트웨이 리소스가 신규로 생성되거나 변경됨을 감지하는 역할입니다. 감지한 다음 쿠버네티스 구성을 gloo gateway translate engine을 전달합니다.

Secret watcher

AWS 자격증명과 같은 secret store의 변경을 감지합니다. gloo gateway의 구성을 감지할 수도 있습니다.

Endpoint discovery

쿠버네티스 서비스 등록을 감지합니다. 새 엔드포인트나 업데이트된 엔드포인트를 발견하면 구성을 etcd에 저장합니다.

Translate Engine

사용자가 생성하거나 변경하는 모든 Gateway API, Kubernetes API, Gloo Gateway 리소스 스냅샷을 수신합니다. 이를 적절한 Envoy 구성으로 translate 합니다. envoy 구성을 xDS 스냅샷에 저장합니다.

translate cycle

1. The translation cycle starts by defining Envoy clusters from all configured Upstream and Kubernetes service resources. Clusters in this context are groups of similar hosts. Each Upstream has a type that determines how the Upstream is processed. Correctly configured Upstreams and Kubernetes services are converted into Envoy clusters that match their type, including information like cluster metadata.
2. The next step in the translation cycle is to process all the functions on each Upstream. Function-specific cluster metadata is added and is later processed by function-specific Envoy filters.
3. In the next step, all Envoy routes are generated. Routes are generated for each route rule that is defined on the HTTPRoute and RouteOption resources. When all of the routes are created, the translator processes any VirtualHostOption, ListenerOption, and HttpListenerOption resources, aggregates them into Envoy virtual hosts, and adds them to a new Envoy HTTP Connection Manager configuration.
4. Filter plug-ins are queried for their filter configurations, generating the list of HTTP and TCP Filters that are added to the Envoy listeners.
5. Finally, an xDS snapshot is composed of the all the valid endpoints (EDS), clusters (CDS), route configs (RDS), and listeners (LDS). The snapshot is sent to the Gloo Gateway xDS server. Gateway proxies in your cluster watch the xDS server for new config. When new config is detected, the config is pulled into the gateway proxy.

Reporter

Reporter는 translator로부터 모든 Gloo Gateway 리소스에 대해 validation report를 전달받습니다. 유효하지 않은 구성은 쿠버네티스 스토리지 계층에 저장됩니다. 또한 유효하지 않은 리소스는 rejected 마크가 포함되고, 리소스 구성에 에러 메시지가 포함됩니다.

xDS Server

최종 스냅샷은 xDS 서버로 전달되고, 서버 구성 업데이트의 성공을 envoy에 알립니다. Gloo Gateway에서 원하는 상태와 일치하게 envoy 클러스터 구성을 업데이트합니다.

Discovery architecture

글루 게이트웨이는 쿠버네티스 서비스 및 기능들을 스캔하고 라우팅과 셀프 서비스를 용이하게 하기 위해서 자동으로 글루 게이트웨이 업스트림 리소스를 생성할 수 있는 서비스 디스커버리 기능을 내장하고 있습니다. 업스트림 생성하는 서비스의 제어를 더 강화하기 위해 서비스 디스커버리를 비활성화하고 업스트림을 수동으로 생성할 수 있습니다.

자동으로 discover 하는 리소스는

- 쿠버네티스 서비스

- AWS Lambda Function

- Google Cloud Functions

- OpenAPI-basedd Functions

그밖에...

Gloo Gateway 이외에도 Cilium Gateway 등과 같은 Gateway API는 https://gateway-api.sigs.k8s.io/implementations/여기를 참조 하시면 됩니다.

List - Kubernetes Gateway API

Implementations This document tracks downstream implementations and integrations of Gateway API and provides status and resource references for them. Implementors and integrators of Gateway API are encouraged to update this document with status information

gateway-api.sigs.k8s.io

감사합니다.

[KANS 3기] 6주차 Ingress

엔지니어-여리 — Sat, 12 Oct 2024 17:23:28 +0900

실습환경

구성하기

실습환경은 지난 번과 동일하게 cloudformation으로 구성합니다.

먼저, 실습 template를 입력합니다.

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-6w.yaml

그 뒤에 파라미터를 입력해줍니다.

stack name은 적절히 mylab으로 입력했습니다.

ec2 key-pair 이름은 이전에 만들어 둔 키페어를 재활용했습니다.

t3.medium이 기본 값이지만 필요시 더 큰 사이즈의 인스턴스로 변경하시면 됩니다.

모든 입력을 완료 한 후 submit을 클릭하여 스택을 배포합니다.

잠시 기다리면 모든 배포가 완료된 것을 확인할 수 있습니다.

4대의 인스턴스가 생성되어 있는 걸 알 수 있습니다.

확인하기

cloudformation으로 구성된 실습환경을 확인하겠습니다.

먼저, EC2 서비스에서 k3s-s 인스턴스의 public IP를 확인합니다.

이후, terminal에서 ssh 명령으로 k3s-s 인스턴스에 접속합니다.

노드 정보

 kubectl get nodes -o wide

파드 정보

kubectl get pod -o wide -A

config 정보

# -v 는 verbose 옵션입니다. kubectl 프로그램의 로그 레벨을 더 높인다는 의미입니다.
kubectl get pod -v=6

config 파일의 위치입니다.

/etc/rancher/k3s/k3s.yaml

네트워크 확인

# 인스턴스에 등록된 ip 리스트
ip -c addr

# 인스턴스에 등록된 라우팅 정보
ip -c route

#flannel cni의 서브넷 정보
cat /run/flannel/subnet.env

# 쿠버네티스에 등록된 노드들이 가지고 있는 pod CIDR 정보
kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}' ;echo

# 노드의 annotation 정보. 여기서는 각 노드의 flannel cni 구성 정보 확인
kubectl describe node | grep -A3 Annotations

# 이더넷 브릿지 정보 확인
brctl show

서비스, endpoint 정보

kubectl get svc,ep -A

kubectl 명령어를 활용하여 서비스, 엔드포인트 정보를 확인합니다.

iptables 정보 확인

iptables -t filter -S | wc -l
iptables -t nat -S | wc -l
iptables -t mangle -S | wc -l

각 테이블 (filter, nat, mangle)의 iptables 규칙 확인이 가능합니다.

위와 같이 실습환경을 준비하였고, 구성을 확인하였습니다.

Ingress

소개

오늘 살펴볼 주제는 Ingress 입니다. 인그레스는 클러스터 외부의 요청을 클러스터 내부로 전달해주는 역할을 합니다.

아니 서비스에서 이미 클러스터 외부에 있는 요청을 내부로 전달하지 않았나요 ?

서비스의 노드포트나 로드밸런서 타입도 물론 클러스터 외부의 요청을 내부로 전달할 수 있지만 인그레스는 조금 다르게 동작합니다.

위 도표와 같이 Ingress는 통신 암호화와 L7 계층에서 동작을 지원합니다. 이를 통해 외부로 노출된 인그레스 리소스로부터 적절한 서비스 - 파드로 HTTP, HTTPS 요청이 전달될 수 있습니다. 이를 간단한 구조로 표현하면 다음과 같습니다.

쿠버네티스 인그레스 문서

물론, 인그레스를 어떻게 구성하냐에 따라 인그레스로부터 파드로 직접통신될 수 있습니다.

이러한 인그레스를 사용하기 위해서는 인그레스 컨트롤러를 구성해야합니다. 인그레스 컨트롤러는 실제 인그레스의 동작을 구현하는 구현체라고 생각하면 됩니다. 인그레스 컨트롤러는 https://kubernetes.io/ko/docs/concepts/services-networking/ingress-controllers/ 에서 더 찾아볼 수 있습니다.

결국, 쿠버네티스에서는 인그레스 API만을 정의하고 실제 구현은 Add-on 에 맡기는 구조입니다. ingress 중에서 ingress-nginx에 대해 살펴보겠습니다. nginx-ingress와는 다릅니다. nginx-ingress는 F5에서 관리하는 인그레스 컨트롤러이고 ingress-nginx는 쿠버네티스에서 관리하는 인그레스 컨트롤러입니다. (헷갈리지 말것)

알아두어야할 내용

인그레스는 현재 새로운 기능이 제공되지 않습니다. 인그레스를 대신할 gateway API라는 다른 유형의 리소스가 등장하였습니다.

ingress-nginx 실습

cat <<EOT> ingress-nginx-values.yaml
controller:
  service:
    type: NodePort
    nodePorts:
      http: 30080
      https: 30443
  nodeSelector:
    kubernetes.io/hostname: "k3s-s"
  metrics:
    enabled: true
  serviceMonitor:
      enabled: true
EOT

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

kubectl create ns ingress
helm install ingress-nginx ingress-nginx/ingress-nginx -f ingress-nginx-values.yaml --namespace ingress --version 4.11.2

# externalTrafficPolicy 설정
kubectl patch svc -n ingress ingress-nginx-controller -p '{"spec":{"externalTrafficPolicy": "Local"}}'

위 명령어를 실행해보겠습니다.

1. ingress-nginx controller 매니페스트를 정의합니다.

2. ingress-nginx 헬름을 추가하고 앞서 정의한 컨트롤러 메니페스트를 적용합니다.

설정 확인

리소스가 정상적으로 적용되었는지 확인합니다. configmap 에는 ingress 리소스가 참조하는 label, annotation이 포함되어 있는 것을 확인할 수 있습니다.

 kubectl get configmap ingress-nginx-controller -n ingress -o yaml

kc describe clusterroles ingress-nginx

컨트롤러의 권한을 확인합니다.

인그레스 컨트롤러 파드에서 ingress 컨트롤러의 정보를 확인할 수 있습니다.

POD_NAMESPACE=ingress
POD_NAME=$(kubectl get pods -n $POD_NAMESPACE -l app.kubernetes.io/name=ingress-nginx --field-selector=status.phase=Running -o name)
kubectl exec $POD_NAME -n $POD_NAMESPACE -- /nginx-ingress-controller --version

여기서 웃긴 점은 앞에서 ingress-nginx, nginx-ingress차이를 말했었죠? 우리가 구성한 인그레스 컨트롤러는 ingress-nginx인데 인그레스 컨트롤러 파드에서 컨트롤러 정보를 확인하는 명령어는 nginx-ingress-controller 입니다. 뭔가 여기저기서 마구잡이로 사용되었을 수 있다는 느낌이 듭니다.

Ingress 실습

이제 본격적으로 인그레스 실습을 해보겠습니다. 실습할 구성은 다음과 같습니다.

실습 목표

- 컨트롤플레인 노드에 인그레스 컨트롤러 생성, NodePort 외부 노출

- 인그레스 정책 설정 (Host/Path Routing)

실습내용을 구성해보겠습니다.

아래는 실행되는 매니페스트 상세내용입니다.

매니페스트

svc1-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy1-websrv
spec:
  replicas: 1
  selector:
    matchLabels:
      app: websrv
  template:
    metadata:
      labels:
        app: websrv
    spec:
      containers:
      - name: pod-web
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: svc1-web
spec:
  ports:
    - name: web-port
      port: 9001
      targetPort: 80
  selector:
    app: websrv
  type: ClusterIP

svc2-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy2-guestsrv
spec:
  replicas: 2
  selector:
    matchLabels:
      app: guestsrv
  template:
    metadata:
      labels:
        app: guestsrv
    spec:
      containers:
      - name: pod-guest
        image: gcr.io/google-samples/kubernetes-bootcamp:v1
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc2-guest
spec:
  ports:
    - name: guest-port
      port: 9002
      targetPort: 8080
  selector:
    app: guestsrv
  type: NodePort

svc3-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy3-adminsrv
spec:
  replicas: 3
  selector:
    matchLabels:
      app: adminsrv
  template:
    metadata:
      labels:
        app: adminsrv
    spec:
      containers:
      - name: pod-admin
        image: k8s.gcr.io/echoserver:1.5
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc3-admin
spec:
  ports:
    - name: admin-port
      port: 9003
      targetPort: 8080
  selector:
    app: adminsrv

ingress1.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-1
  annotations:
    #nginx.ingress.kubernetes.io/upstream-hash-by: "true"
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc1-web
            port:
              number: 80
      - path: /guest
        pathType: Prefix
        backend:
          service:
            name: svc2-guest
            port:
              number: 8080
      - path: /admin
        pathType: Prefix
        backend:
          service:
            name: svc3-admin
            port:
              number: 8080

ingress2.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-2
spec:
  ingressClassName: nginx
  rules:
  - host: kans.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc3-admin
            port:
              number: 8080
  - host: "*.kans.com"
    http:
      paths:
      - path: /echo
        pathType: Prefix
        backend:
          service:
            name: svc3-admin
            port:
              number: 8080

canary-svc1-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dp-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: svc-v1
  template:
    metadata:
      labels:
        app: svc-v1
    spec:
      containers:
      - name: pod-v1
        image: k8s.gcr.io/echoserver:1.5
        ports:
        - containerPort: 8080
      terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Service
metadata:
  name: svc-v1
spec:
  ports:
    - name: web-port
      port: 9001
      targetPort: 8080
  selector:
    app: svc-v1

canary-svc2-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dp-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: svc-v2
  template:
    metadata:
      labels:
        app: svc-v2
    spec:
      containers:
      - name: pod-v2
        image: k8s.gcr.io/echoserver:1.6
        ports:
        - containerPort: 8080
      terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Service
metadata:
  name: svc-v2
spec:
  ports:
    - name: web-port
      port: 9001
      targetPort: 8080
  selector:
    app: svc-v2

canary-ingress1.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-canary-v1
spec:
  ingressClassName: nginx
  rules:
  - host: kans.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-v1
            port:
              number: 8080

canary-ingress2.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-canary-v2
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  ingressClassName: nginx
  rules:
  - host: kans.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-v2
            port:
              number: 8080

실습 1. 인그레스 적용 및 리소스 확인

kubectl taint nodes k3s-s role=controlplane:NoSchedule
curl -s -O https://raw.githubusercontent.com/gasida/NDKS/main/7/svc1-pod.yaml
curl -s -O https://raw.githubusercontent.com/gasida/NDKS/main/7/svc2-pod.yaml
curl -s -O https://raw.githubusercontent.com/gasida/NDKS/main/7/svc3-pod.yaml
kubectl apply -f svc1-pod.yaml,svc2-pod.yaml,svc3-pod.yaml

위 코드블럭을 실행시키면 아래 동영상과 같이 pod,ep, svc가 구성됩니다.

위에 설정된 파드, 엔드포인트, 서비스에 인그레스 설정을 추가해보겠습니다. 위에 정의한 ingress1.yaml을 적용해줍니다.

아래 영상과 같이 ingress - svc - pod 구성이 적용됩니다.

인그레스 컨트롤러에 기록된 Rule은 실제로 인그레스 컨트롤러 파드의 nginx.conf에 적용됩니다.

kubectl exec deploy/ingress-nginx-controller -n ingress -it -- cat /etc/nginx/nginx.conf | grep 'location /' -A5 | more

인그레스 컨트롤러를 통해서 접속해보겠습니다.

컨트롤러의 인입 포트(30080)와 Public IP(13.124.30.188)를 확인한 다음 Rule에 맞게 url을 입력하여 접속해보겠습니다.

http://13.124.30.188:30080/

http://13.124.30.188:30080/guest

http://13.124.30.188:30080/admin

접속이 잘 되는 것을 확인할 수 있습니다.

실습 2. 패킷 캡쳐 및 분석

패킷을 캡쳐하여 통신이 어떤식으로 이루어지는지 알아보겠습니다.

아래 명령어를 활용하여 패킷을 저장 해줍니다.

tcpdump -i $(ifconfig  | grep veth | tail -1 | awk '{print $1}' | cut -d ':' -f 1) tcp port 8080 -w /home/ubuntu/ingress-nginx-admin.pcap && chown ubuntu /home/ubuntu/ingress-*

http://13.124.30.188:30080/admin 주소에 1회 접속 후 패킷캡쳐를 종료합니다.

scp -i ~/.ssh/yeoli.pem ubuntu@13.124.30.188:/home/ubuntu/ingress-nginx-admin.pcap .

패킷을 다운로드 받은 다음 Wireshark로 패킷 덤프를 열어보겠습니다.

이 패킷 덤프에서는 172.16.0.4 와 172.16.3.5 사이에 통신이 있는 것으로 보입니다.

이를 cluster에서 리소스를 조회해보면 172.16.0.4는 ingress controller의 ip, 172.16.3.5는 admin pod의 ip로 확인됩니다.

실제로 인그레스 컨트롤러

HTTP 요청에서는 요청자 IP(저의 public ip)와 클러스터의 노드포트 정보가 포함되어 있습니다.

실습 3. 호스트 기반 라우팅

ingress2.yaml 매니페스트를 적용해보겠습니다.

적용시 아래와 같이 ingress-2 가 생성됩니다.

호스트는 kans.com, *.kans.com이 아닌 yeoli.com, *.yeoli.com 로 설정하였습니다.

이후 내 PC에서 host 파일을 수정해야합니다. root 계정에서 아래 명령어를 사용하여 hosts 파일을 수정해줍니다.

K3S_PUBLIC_IP='13.124.30.188' # 구성된 클러스터의 public ip를 기입해주세요.
echo $K3S_PUBLIC_IP yeoli.com >> /etc/hosts

잘 접속되는 것을 확인할 수 있습니다.

실습 4. 카나리 업그레이드

카나리 업그레이드 대상이 될 파드를 배포해줍니다.

kubectl apply -f canary-svc1-pod.yaml,canary-svc2-pod.yaml

마찬가지로 인그레스도 배포해줍니다.

kubectl apply -f canary-ingress1.yaml,canary-ingress2.yaml

여기서 중요한 부분은

canary-ingress2.yaml의 annotation입니다.

canary: true
canary-weight: 10

즉 카나리 설정을 활성화하고 카나리 비율을 10퍼센트로 한다는 설정을 포함합니다.

이 weight은 ingress-canary-v2로 들어오는 요청의 비율을 뜻합니다.

kubectl annotate --overwrite ingress ingress-canary-v2 nginx.ingress.kubernetes.io/canary-weight=50

ingress-canary-v2 로 들어오는 요청을 조절하면 아래 동영상과 같이 실시간으로 버전에 따른 요청량을 조절할 수 있습니다.

개발 사이클에서 사용자 경험을 더욱 높일 수 있는 방법으로 활용될 수 있습니다.

정리

단순히 서비스를 활용하면 쿠버네티스 클러스터 내부에 있는 파드를외부에서 요청할 수 있습니다. 다만 클러스터 내에서 여러 서비스를 다양하게 제어 하기에는 역부족입니다. 이를 해결해주기 위해 인그레스를 도입할 수 있습니다. 인그레스를 통해 더 다양한 요구사항을 처리할 수 있습니다.

인그레스 도입시 활용가능한 기능은 다음과 같습니다.

- 호스트라우팅

- 카나리 배포전략

- 애플리케이션 계층 구성

하지만, 인그레스는 앞으로 추가적인 개발이 없을 예정입니다. 인그레스를 대체할 리소스는 Gateway API 입니다. Ingress를 잘 알고 Gateway API로 잘 migration하여 즐거운 쿠버네티스 삶이 되시길 바랍니다.

감사합니다.

[KANS 3기] 5주차 MetalLB

엔지니어-여리 — Sat, 5 Oct 2024 16:49:01 +0900

LoadBalancer 타입 Service

서비스는 분산된 애플리케이션의 단일 외부 엔드포인트를 노출할 수 있도록 해줍니다. 서비스 유형은 Cluster IP, NodePort, LoadBalancer, ExternalName 등이 있습니다. 이중 ClusterIP는 클러스터 내부에서만 서비스에 접근 가능하고 NodePort는 각 노드와 포트 ip를 통해 외부에서 접근 가능합니다. 클러스터 외부에 노출시키기에 우아한 방법은 아닙니다. LoadBalancer 유형의 서비스는 외부의 로드밸런서를 이용하여 클러스터의 서비스를 외부에 노출시키는 유형입니다. 이번 시간에는 로드밸런서 타입의 서비스에 대해서 살펴보도록 하겠습니다.

실습환경 구성하기

실습환경 구성에서 이전 포스팅과 동일한 부분은 생략하고 차이가 있는 부분만 다루겠습니다.

인스턴스 구성

# in AWS 

# ec2 서비스에서 key-pair 를 생성 후 다운로드 받습니다.
# cloudformation 서비스에서 template를 아래 url로 설정 후 stack을 생성합니다.
 https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-5w.yaml # 실습 cloudformation 파일을 다운로드 받습니다.



# in cli

STACK_NAME=mylab
KEY_PAIR=yeoli
PROFILE=lab

curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-5w.yaml # 실습 cloudformation 파일을 다운로드 받습니다.
 aws cloudformation deploy \
  --template-file kans-5w.yaml \
  --stack-name $STACK_NAME \
  --parameter-overrides \
    KeyName=$KEY_PAIR \
    SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 \
  --region ap-northeast-2 \
  --profile $PROFILE
  
  
# ec2 인스턴스의 userdata에는 다음 항목이 포함되어 있습니다.

# hostname 변경
# ufw 방화벽 해제
# kind 설치
# 도커 엔진 설치
# alias 설정
# kubectl, helm, kubectx, kubens, kubeps
# kubectl 자동완성
# 리소스 제한 상승

클러스터 구성

cat <<EOT> kind-svc-2w.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  "InPlacePodVerticalScaling": true  #실행 중인 파드의 리소스 요청 및 제한을 변경할 수 있게 합니다.
  "MultiCIDRServiceAllocator": true  #서비스에 대해 여러 CIDR 블록을 사용할 수 있게 합니다.
nodes:
- role: control-plane
  labels:
    mynode: control-plane
    topology.kubernetes.io/zone: ap-northeast-2a
  extraPortMappings:  #컨테이너 포트를 호스트 포트에 매핑하여 클러스터 외부에서 서비스에 접근할 수 있도록 합니다.
  - containerPort: 30000
    hostPort: 30000
  - containerPort: 30001
    hostPort: 30001
  - containerPort: 30002
    hostPort: 30002
  - containerPort: 30003
    hostPort: 30003
  - containerPort: 30004
    hostPort: 30004
  kubeadmConfigPatches:
  - |
    kind: ClusterConfiguration
    apiServer:
      extraArgs:  #API 서버에 추가 인수를 제공
        runtime-config: api/all=true  #모든 API 버전을 활성화
    controllerManager:
      extraArgs:
        bind-address: 0.0.0.0
    etcd:
      local:
        extraArgs:
          listen-metrics-urls: http://0.0.0.0:2381
    scheduler:
      extraArgs:
        bind-address: 0.0.0.0
  - |
    kind: KubeProxyConfiguration
    metricsBindAddress: 0.0.0.0
- role: worker
  labels:
    mynode: worker1
    topology.kubernetes.io/zone: ap-northeast-2a
- role: worker
  labels:
    mynode: worker2
    topology.kubernetes.io/zone: ap-northeast-2b
- role: worker
  labels:
    mynode: worker3
    topology.kubernetes.io/zone: ap-northeast-2c
networking:
  podSubnet: 10.10.0.0/16  #파드 IP를 위한 CIDR 범위를 정의합니다. 파드는 이 범위에서 IP를 할당받습니다.
  serviceSubnet: 10.200.1.0/24  #서비스 IP를 위한 CIDR 범위를 정의합니다. 서비스는 이 범위에서 IP를 할당받습니다.
EOT



# k8s 클러스터 설치
kind create cluster --config kind-svc-2w.yaml --name myk8s --image kindest/node:v1.31.0
docker ps



# 노드에 기본 툴 설치
docker exec -it myk8s-control-plane sh -c 'apt update && apt install tree psmisc lsof wget bsdmainutils bridge-utils net-tools dnsutils ipset ipvsadm nfacct tcpdump ngrep iputils-ping arping git vim arp-scan -y'
for i in worker worker2 worker3; do echo ">> node myk8s-$i <<"; docker exec -it myk8s-$i sh -c 'apt update && apt install tree psmisc lsof wget bsdmainutils bridge-utils net-tools dnsutils ipset ipvsadm nfacct tcpdump ngrep iputils-ping arping -y'; echo; done

노드별 네트워크 정보 확인

for i in control-plane worker worker2 worker3; do echo ">> node myk8s-$i <<"; docker exec -it myk8s-$i cat /etc/cni/net.d/10-kindnet.conflist; echo; done
for i in control-plane worker worker2 worker3; do echo ">> node myk8s-$i <<"; docker exec -it myk8s-$i ip -c route; echo; done
for i in control-plane worker worker2 worker3; do echo ">> node myk8s-$i <<"; docker exec -it myk8s-$i ip -c addr; echo; done

1. 클러스터에 포함된 노드들의 CNI 정보를 조회합니다. kindnet을 CNI로 사용합니다.

2. 각 노드의 routing table을 조회합니다.

3. 각노드의 ip 주소 정보를 조회합니다.

iptables 정보 확인

for i in filter nat mangle raw ; do echo ">> IPTables Type : $i <<"; docker exec -it myk8s-control-plane  iptables -t $i -S ; echo; done
for i in filter nat mangle raw ; do echo ">> IPTables Type : $i <<"; docker exec -it myk8s-worker  iptables -t $i -S ; echo; done
for i in filter nat mangle raw ; do echo ">> IPTables Type : $i <<"; docker exec -it myk8s-worker2 iptables -t $i -S ; echo; done
for i in filter nat mangle raw ; do echo ">> IPTables Type : $i <<"; docker exec -it myk8s-worker3 iptables -t $i -S ; echo; done

선택된 노드에 대해서 iptables 프로그램으로 각 테이블(filter, nat, mangle, raw)에 대해 조회해서 확인합니다.

docker ps -q | xargs docker inspect --format '{{.Name}} {{.NetworkSettings.Networks.kind.IPAddress}}'

명령어를 살펴보면 현재 실행중인 파드의 네트워크 정보를 확인하는 명령어 입니다.

그리고, docker network inspect kind 명령어로 kind 네트워크 인터페이스의 정보를 확인해보면 다음과 같습니다.

결국, 4개의 도커 컨테이너 (kind node)는 kind라는 도커 네트워크를 공유하여 네트워크 내에서 ip를 할당받았다는 것을 알 수 있습니다. 이는 각 노드 사이에는 통신이 가능하다는 점을 시사합니다.

로드밸런서 타입

로드밸런서 타입의 서비스는 앞서 설명한 것과 같이 외부의 로드밸런서를 사용하여 서비스를 외부로 노출시킵니다.

쿠버네티스에서는 로드밸런스 타입 서비스를 직접 제공하지는 않습니다. AWS와 같은 CSP에서 제공하는 로드 밸런서 혹은 LoxiLB, MetalLB와 같은 오픈소스를 사용하여 로드밸런서 타입 서비스를 사용할 수 있습니다.

김경보님의 블로그에는 온프레미스 혹은 클라우드 환경에서의 로드밸런서 혹은 클라우드 내에서 로드밸런서 타입의 서비스의 작동 방식에 대해 잘 기술되어 있습니다.

https://kimalarm.tistory.com/102

CSP의 로드밸런서는 2가지 방식으로 동작합니다.

1.NodePort 접근 방식은 로드밸런서로 들어온 요청을 노드포트를 거친 후 목적지 application pod로 전달하는 방식입니다.

2. pod direct 접근 방식은 로드밸런서로 들어온 요청을 목적지 application pod로 직접 전달하는 방식입니다.

MetalLB 에 대하여

MetalLB는 BareMetal LoadBalancer의 약자입니다. 이름에서 보시다시피 MetalLB는 베어메탈 쿠버네티스 클러스터를 위한 로드밸런서입니다. MetalLB는 2가지 모드를 제공합니다. Layer2 모드와 BGP 모드를 제공합니다. 베어메탈 환경이 목적이기 때문에 대부분의 클라우드 환경에서는 호환되지 않을 수 있습니다. 또한, 일부 CNI와 연동에 문제가 있을 수 있습니다.

https://metallb.universe.tf/configuration/calico/

Issues with Calico :: MetalLB, bare metal load-balancer for Kubernetes

The easy way As of Calico 3.18 (from early 2021), Calico now supports limited integration with MetalLB. Calico can be configured to announce the LoadBalancer IPs via BGP. Simply run MetalLB, apply an IPAddressPool without any BGPAdvertisement CR. When usin

metallb.universe.tf

MetalLB 구성시 동작 순서

1. 로드밸런서 서비스 리소스를 생성하면 스피커 파드를 데몬셋 형태로 생성합니다.

2. 스피커 파드중 리더가 선출됩니다.

3. 리더 파드는 External IP를 전파합니다.

4. External IP 전파를 위해 ARP 혹은 BGP 프로토콜을 사용합니다. 여기서 MetalLB의 2가지 모드가 구분됩니다.

Layer2 모드

ARP 프로토콜을 사용하는 모드를 Layer2 모드라고 합니다. Layer2 모드에서는 External IP를 전파할 때 ARP 프로토콜을 통해서 전파합니다. 동일한 내부 네트워크에서 통신을 위해서는 목적지의 MAC 주소를 알아야합니다. ARP 프로토콜을 통하면 목적지 IP에 해당하는 MAC 주소를 요청하여 알수 있습니다.

가시다님 제공

위 그림에서는 노드1의 스피커파드가 리더 파드입니다. SVC1 의 External IP로 접속하게 되면 노드1의 iptables 규칙을 통해 목적지 파드를 찾아 요청이 적절히 전달될 수 있습니다. 이때 1번 노드의 스피커 파드에 장애가 발생하면 나머지 스피커 파드 중에서 다시 리더를 선출합니다.

BGP 모드

BGP 모드로 MetalLB를 구성하게되면, 스피커 파드는 BGP로 External IP를 전파하고, 외부 라우터를 통해 ECMP 라우팅으로 요청을 분산합니다. 앞서 설명한 Layer2 모드에 비해 더 규모가 있고 복잡하고 네트워크 팀 협조가 가능할 때 유용한 모드입니다.

MetalLB 구성하기

https://metallb.universe.tf/installation/ 문서를 참고하였습니다.

Installation :: MetalLB, bare metal load-balancer for Kubernetes

Before starting with installation, make sure you meet all the requirements. In particular, you should pay attention to network addon compatibility. If you’re trying to run MetalLB on a cloud platform, you should also look at the cloud compatibility page

metallb.universe.tf

공식문서에 MetalLB를 구성하는 아주 간단한 방법이 나와있어 인용하였습니다.

# MetalLB native 구성
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/refs/heads/main/config/manifests/metallb-native-prometheus.yaml
 
 
# 리소스 확인
watch -d n 1 'kubectl get all,configmap,secret,ep -n metallb-system  -o wide'

ConfigMap 구성

다음으로 할 작업은 MetalLB가 External IP로 사용할 영역을 지정하고 설정해주는 일입니다.

IPAddress Pool 생성

cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: my-ippool
  namespace: metallb-system
spec:
  addresses:
  - 172.18.255.200-172.18.255.250
EOF

L2advertisements 생성

L2 모드로 LoadBalancer IP로 사용하도록 허용하는 내용을 생성합니다.

kubectl explain l2advertisements.metallb.io

cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: my-l2-advertise
  namespace: metallb-system
spec:
  ipAddressPools:
  - my-ippool
EOF

아래와 같이 구성할 수 있습니다.

서비스 생성

3개의 서비스를 생성해보면 다음과 같이 kubectl get svc 명령어로 확인해볼 수 있습니다. 각 노드의 external IP가 노드의 스피커파드 IP로 구성되어 있습니다.

또한 로드밸런서 서비스 타입은 노드포트 타입을 포함하기 때문에 아래와 같이 allocateLoadBalancerNodePorts 값이 true로 설정되어 있습니다. 이를 false로 변경해 노드포트 32258 (svc1 기준) 를 사용하지 않고 80포트를 통해 요청할 수 있습니다.

서비스를 활용하여 외부에서 접근

각 서비스의 external IP를 변수로 설정합니다.

SVC1EXIP=$(kubectl get svc svc1 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
SVC2EXIP=$(kubectl get svc svc2 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
SVC3EXIP=$(kubectl get svc svc3 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

이후, 테스트 컨테이너에서 각 서비스의 externalIP에 대해 각각 curl 요청을 보내어 확인합니다.

for i in $SVC1EXIP $SVC2EXIP $SVC3EXIP; do docker exec -it mypc curl -s $i | grep Hostname ; done

정보를 더욱 상세하게 표기하도록 코드를 수정하여 테스트 합니다.

for i in $SVC1EXIP $SVC2EXIP $SVC3EXIP; do echo ">> Access Service External-IP : $i <<" ;docker exec -it mypc curl -s $i | egrep 'Hostname|RemoteAddr|Host:' ; echo ; done

External IP로 요청하는 걸 확인하였습니다.

후기

스터디에서 다루는 내용들을 따라가기 위해서 별도로 네트워크 공부를 하지만 부족함이 많은 것 같습니다. 지금 다 이해 못한다면 두번이고 세번이고 보면서 이해해야겠습니다. 항상 알찬 내용을 준비해주시는 분들과 어렵고 복잡한 과제들을 해네는 동료분들이 늘 저를 이끄는 동기부여가 됩니다.

읽어주셔서 감사합니다.

KCD 참석후기 - 쿠버네티스에서 스케줄링 작동 방식

엔지니어-여리 — Sat, 28 Sep 2024 22:47:53 +0900

안녕하세요. 이 글은 2024년 9월 24일 Cloud Native Korea Community Day 2024에 참석한 후기를 담고 있습니다.

가장 인상적이었던 주제는 쿠버네티스 스케줄러에 관한 내용이었습니다. 이번 글에서는 쿠버네티스 scheduling에 대한 내용 및 1.30버전부터 GA된 scheduling gate에 대해 다뤄보고자 합니다.

scheduler가 하는 일

scheduler는 3가지 일을 합니다. scheduling, preemption, eviction 입니다.

- scheduling은 신규 pod 생성을 말합니다.

- preemption은 더 우선순위가 높은 pod를 생성하기 위해 우선순위가 낮은 pod를 삭제하는 것을 말합니다.

- eviction은 리소스가 부족한 노드에서 pod를 삭제하는 것을 말합니다.

이중 오늘은 scheduling이 어떻게 동작하는지 다뤄보고자 합니다.

스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드에 적합한지 확인하는 일을 말합니다.

kube-scheduler

쿠버네티스의 기본 스케줄러이고, 컨트롤 플레인의 일부입니다. 스케줄러는 이름에서 알다시피 스케줄링을 합니다.

스케줄링은 앞에서 말한 것과 같이 새로운 pod를 생성합니다. 물론 pod는 어떤 노드에 배포되어야 합니다. 결국 pod가 어떤 노드에 배포되어야 하는지 결정한다고 볼 수 있습니다. kube-scheduler는 2가지 단계로 파드가 생성될 노드를 선택합니다.

scheduling framework

1. filtering: 필터링은 pod를 스케줄링 할 수 있는 노드 셋을 찾는 작업입니다.

2. scoring: 스코어링은 선택된 노드 셋중에 실제로 pod가 배포될 노드를 찾는 작업입니다.

먼저, 필터링을 하기 전에 클러스터내에서 얼마나 많은 노드에 대해서 필터링 & 스코어링을 해야하는지 결정할 수 있습니다. 이는 스케줄러의 성능 최적화를 말합니다. percentageOfNodesToScore 옵션의 값으로 정의합니다. 0~100 사이의 값으로 설정가능합니다.

percentageOfNodesToScore의 값의 기본 값은 워커노드가 늘어날수록 선형적으로 감소됩니다. 50에서부터 감소되어서 최소 수치는 5입니다.

// WithPercentageOfNodesToScore sets percentageOfNodesToScore for Scheduler.
// The default value of 0 will use an adaptive percentage: 50 - (num of nodes)/125.
func WithPercentageOfNodesToScore(percentageOfNodesToScore *int32) Option {
	return func(o *schedulerOptions) {
		if percentageOfNodesToScore != nil {
			o.percentageOfNodesToScore = *percentageOfNodesToScore
		}
	}
}

https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/scheduler.go

kubernetes/pkg/scheduler/scheduler.go at master · kubernetes/kubernetes

Production-Grade Container Scheduling and Management - kubernetes/kubernetes

github.com

필터링

필터링에서는 어떤 노드를 선택할지를 결정하는 단계라고 이해할 수 있습니다. taint, toleration, affinity, resource availability 등에 따라서 현재 파드가 배포가될 수 있는지 여부를 확인하는 단계입니다. 이를 통해서 선택된 워커노드 목록중 파드가 배포될 수 있는 파드를 (말그대로) 필터링 한다고 생각할 수 있습니다.

만약 필터링 결과로 노드가 1개만 선택된 경우 스코어링을 하지 않고 바로 해당 노드에 pod가 생성됩니다.

스코어링

위 그림을 보기 편하도록 표로 정리해보았습니다.

score는 아래 표와 같이 매겨집니다.

구분	점수
TaintToleration	3
NodeAffinity	2
PodTopologySpread	2
InterPodAffinity	2
NodeResourcesFil	1
VolumeBinding	1
NodeResourcesBalancedAllocation	1
ImageLocality	1

TaintToleration과 NodeAffinity중 TaintToleration이 더 높은 우선순위를 가지고 있음을 알 수 있네요.

만약, 스코어링을 통해서 같은 점수를 가진 노드가 있다면 kube-scheduler가 임의의 노드를 선택하게됩니다.

왜 이렇게 스케줄링이 복잡한 걸까요?

(개인적인 견해입니다.) 이렇게 생각해보겠습니다. 하나의 클러스터에 데이터플레인을 구성하고 있는 워커노드가 3대 있습니다.

여기서 새로운 디플로이먼트셋이 배포되고, 이로 인해 10개의 파드가 생성된다고 했을때 스케줄링은 아주 찰나의 시간만 필요할 것입니다. 이로 인해서 컨트롤 플레인에 큰 부하가 있진 않을 것입니다.

하지만, 워커노드가 2,000대쯤 존재한다고 가정해볼까요? 여기서 동일한 디플로이먼트셋을 배포한다면 스케줄링 과정이 컨트롤 플레인에 얼마나 많은 부하를 가져올까요? 거기다가 파드의 수명 주기에 얼마나 많은 영향을 줄까요? 이로 인해서 파드가 늦게 뜬다면 사용자 경험에 큰 영향을 주지 않을까 합니다.

그래서 현재와 같이 복잡한 스케줄링 방식을 통해 노드가 많더라도 빠른 스케줄링을 제공하지 않는가 합니다.

Pod Scheduling Readiness

이 기능은 v1.26버전부터 베타 기능으로 추가되었고 쿠버네티스 v1.30에서 scheduling gate가 GA 되었습니다. 이 기능은 어떤 용도로 사용될까요 ?

먼저 기존의 scheduling은 이렇게 동작합니다. pod 생성 후 스케줄링, 파드 실행의 단계로 이어집니다.

여기서 발생하는 문제는 없을까요?

모든 노드에 대해서 스케줄링이 되지 않는다면 스케줄링은 완료될 때까지 api 요청을 계속하게 됩니다. 이는 컨트롤 플레인에 큰 영향을 줄 수 있습니다.

scheduling gate라는 기능은 다음과 같이 동작합니다. pod의 .spec.schedulingGates를 정의함으로써 scheduling gate가 부여됩니다. .spec.schedulingGates가 정의되면 파드를 생성하되, 스케줄링될 시기를 제어할 수 있습니다. pod의 .spec.schedulingGates를 삭제하면 다시 스케줄링되어 파드가 생성됩니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
      schedulingGates:
        - name: gate

실행 결과

schedulingGate 삭제 후

deployment set에서 scheduling gate 태그를 삭제하게 되면 새로운 레플리카 셋으로 파드가 실행됩니다.

scheduling gate의 이점

- 동적으로 pod의 수명주기를 제어할 수 있다는 점에서 scheduling gate가 사용될 수 있을 것으로 보입니다.

- 온프레미스 환경과 같이 워커 노드의 사이즈가 유연하게 변경될 수 없는 경우 불필요한 스케줄링이 발생하지 않을 수 있습니다.

scheduling gate 사용 사례

- gpu 머신과 같은 한정적인 자원을 포함하는 클러스터의 경우, gpu 머신에 해당하는 job을 미리 정의한 뒤 이전 job이 종료될 때 생성해둔 job의 schedulingGate를 삭제하여 동적으로 파드를 할당할 수 있습니다.

- 워크로드 정의(yaml)가 동적으로 스케줄링되어, 노드와 스케줄링이 최적화를 고려할 수 있습니다.

참고문헌

쿠버네티스 스케줄링 컨셉 https://kubernetes.io/ko/docs/concepts/scheduling-eviction/

쿠버네티스 스케줄링 준비성 https://kubernetes.io/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness/

쿠버네티스 스케줄링 준비성 개발 티켓 https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/3521-pod-scheduling-readiness

쿠버네티스 스케줄러 소스코드 https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/scheduler.go

[KANS 3기] 3주차 Calico 네트워크 모드와 접근통제(3/3)

엔지니어-여리 — Sat, 21 Sep 2024 23:32:34 +0900

Calico 네트워크 모드

칼리코는 다양한 네트워크 모드를 제공합니다.

IPIP 모드 (기본설정)

이전 글에서 다뤘던 내용인 만큼 생략하도록 하겠습니다.

https://yeoli-tech.tistory.com/44

[KANS 3기] 3주차 Calico CNI (2/3)

Calico(이하 ”칼리코“) 알아보기Calico에 대한 공식 문서의 설명에 따르면, calico는 네트워크, 보안 솔루션으로 이용된다고 합니다.Calico is a networking and security solution that enables Kubernetes workloads and no

yeoli-tech.tistory.com

- 같은 노드 내에서는 파드간 통신시 직접 통신합니다.

- 다른 노드에서 파드간 통신은 tunl0 인터페이스를 사용하고 IPIP 프로토콜로 통신합니다.

- 다른 노드의 ip 대역은 BGP로 전달 받은 다음 호스트의 라우팅테이블에 업데이트 됩니다.

Direct 모드

- IPIP 모드와 달리 파드 통신이 출발지 노드의 라우팅 정보를 확인해 목적지 노드로 원본 그대로 전달합니다.

- AWS에서 이 모드를 사용하려면 다음과 같이 Source/Destination Check 기능을 Disable 해야합니다.

# IPIP 모드 비활성화
calicoctl get ippool default-ipv4-ippool -o yaml | sed -e "s/ipipMode: Always/ipipMode: Never/" | calicoctl apply -f - 

# IPIP 모드 활성화
calicoctl get ippool default-ipv4-ippool -o yaml | sed -e "s/ipipMode: Never/ipipMode: Always/" | calicoctl apply -f -

VXLAN 모드

- Flannel CNI에서 한 번 다뤘습니다. https://yeoli-tech.tistory.com/42#%EB%AA%A8%EB%93%9Cmode

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

쿠버네티스 환경 구성하기스터디에서는 각자 환경 (Window, Mac)에서 쿠버네티스 클러스터를 구성했다. 쿠버네티스 클러스터를 구현하기 위해 KIND를 활용했으나 (kind 내용은 다른 스터디원들이나

yeoli-tech.tistory.com

- BGP를 사용하지 않고, VXLAN L3 라우팅을 통해서 동작 합니다.

Pod 패킷 암호화

- 파드간 통신이 암호화되어야 하는 경우에 사용할 수 있습니다.

- 파드간 통신시 wireguard tunnel을 통해 트래픽이 암호화되어 전달됩니다.

네트워크 접근 통제

- 네트워크 정책은 클러스터 내부에서 파드간 통신에 대해 트래픽 규칙을 정의하는 걸 말합니다.

- 네트워크 정책을 정하지 않는 경우, 모든 파드간에는 서로 통신이 가능합니다.

- 네트워크 정책은 기본적으로 차단입니다.

네트워크 정책 대상

- 네트워크 정책이 적용될 대상은 다음과 같이 결정될 수 있습니다.

- 특정 pod, 특정 namespace, 특정 ip block

네트워크 정책 예시

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sample-networkpolicy
  namespace: default # 보안 정책을 생성할 네임스페이스 지정
spec:
  podSelector:
    # 설정할 대상 파드를 여기에 기입
    # 레이블 셀렉터이므로 복수의 파드를 대상으로 할 수 있음.
  policyTypes:
  - Ingress # 인그레이스 룰을 생성하는 경우 명시
  - Egress # 이그레스 룰을 생성할 경우 명시
  ingress:
  - from:
      # 인그레스 룰을 여기에 기입(이그레스 룰과 형식은 동일）
    ports:
      # 이 인그레스 룰로 허가할 수신 포트 번호와 프로토콜 기입
  egress:
  - to:
      # 이그레스 룰을 여기에 기입(인그레스 룰과 형식은 동일）
    ports:
      # 이 이그레스 룰로 허가할 송신 포트 번호와 프로토콜 기입

리소스 정리

- 다쓴 리소스는 꼭 삭제해주세요.

- cloudformation에서 리소스를 삭제하면 됩니다.

- 다 쓴 리소스는 반드시 삭제 후 삭제되었는지 확인해보세요.