Kubernetes

Argo Rollouts 의 쿨다운에 대한 이야기를 하려고한다. 이글은 Argo Roullouts 의 scaleDownDelaySeconds 옵션부터 preStop terminationGracePeriodSeconds 까지의 과정을 다룬다. Argo Rollouts 는 배포를 도와주는 툴로 블루그린 카나리등과 같은 부분을 도와주는 도구이다. 간략하게 동작을 설명하겠다. 블루그린이 완료된이후 RS는 축소하지 않고 30초간 대기한다. 이 30초간 대기하는 옵션이 scaleDownDelaySeconds다. 혹시나모를 롤백 상황에 대해서 기다리는 옵션인것이다. 이시간이 종료되면 이제 RS는 replicas 를 0으로 수정해서 pod 들은 축소된다. replicas 가 0으로 수정되면 pod는 일반적인 pod 의 lifecycle 를 거친다. pod 는 여러 차례 말했지만 N+1개의 컨테이너의 집합이고 컨테이너는 프로세스이므로 프로세스의 종료 과정이 그대로 pod 의 lifecycle 를 따르나 쿠버네티스는 이 프로세스를 컨트롤하는 고도화된 툴이므로 다양한 과정을 컨트롤 할수있게 만들어져 있다. ...

CKAD를 예약하면서 진짜 공부를 안했다. 정말 안했다. 모든 공부시간을 다 합쳐서도 5시간이 안됐다. 첫번째 시험.. 합격일줄알았는데..떨어졌다.ㅋㅋㅋㅋ 이럴수가ㅋㅋㅋㅋㅋㅋ경악을 금치못했고 공부는 또 안했다. 시험보면서 내가 Docs 에서 원하는 기능이 어디에 있는지 찾는 과정일 뿐 이었기 때문에 그냥 잘 검색하는 방법 yaml 을 좀더 빨리 만들수있게 예제가 있는 위치만 더 찾아봤다. 바로 다시 16일에 시험을 봤고, 합격했다. 고득점일줄 알았는데 나중에 복기해보니 틀린게 좀 있었다. 먼저 Cronjob 은 이제 완전히 옵션을 다 알았다. SecurityContext는 뭐 그럭저럭.. Docker save 명령어는 생각이 안나서 man docker 해서 봤다. Readiness 는 httpget이 Docs엔 안나와있는데 나중에 찾아보니 그냥 공통 구조체더라. ...

In some cases, Cluster RBAC does not work with ArgoCD. Control cluster resources with "CLUSTER RESOURCE ALLOW LIST". When you create a new ArgoCD project, it has no permissions by default, so it can only operate within the namespace to NOT create cluster RBAC.

helm install sentry sentry/sentry coalesce.go:175: warning: skipped value for kafka.config: Not a table. coalesce.go:175: warning: skipped value for kafka.zookeeper.topologySpreadConstraints: Not a table. W1023 08:00:35.276931 15594 warnings.go:70] spec.template.spec.containers[0].env[39]: hides previous definition of "KAFKA_ENABLE_KRAFT" Error: INSTALLATION FAILED: failed post-install: 1 error occurred: * job failed: DeadlineExceeded job failed: DeadlineExceeded 에러가 발생한다. 이 job은 DB가 정상적으로 올라왔는지 확인하는 job이다. k get job NAME COMPLETIONS DURATION AGE sentry-db-check 0/1 5m23s 5m23s 이 Job은 다음을 검증한다. name: sentry-db-check namespace: sentry resourceVersion: "4700657" uid: 12533bba-b35b-4b7d-9007-8c625b389a98 spec: activeDeadlineSeconds: 1000 backoffLimit: 6 completionMode: NonIndexed completions: 1 parallelism: 1 selector: matchLabels: batch.kubernetes.io/controller-uid: 12533bba-b35b-4b7d-9007-8c625b389a98 suspend: false template: metadata: creationTimestamp: null labels: app: sentry batch.kubernetes.io/controller-uid: 12533bba-b35b-4b7d-9007-8c625b389a98 batch.kubernetes.io/job-name: sentry-db-check controller-uid: 12533bba-b35b-4b7d-9007-8c625b389a98 job-name: sentry-db-check release: sentry name: sentry-db-check spec: containers: - command: - /bin/sh - -c - | echo "Checking if clickhouse is up" CLICKHOUSE_STATUS=0 while [ $CLICKHOUSE_STATUS -eq 0 ]; do CLICKHOUSE_STATUS=1 CLICKHOUSE_REPLICAS=3 i=0; while [ $i -lt $CLICKHOUSE_REPLICAS ]; do CLICKHOUSE_HOST=sentry-clickhouse-$i.sentry-clickhouse-headless if ! nc -z "$CLICKHOUSE_HOST" 9000; then CLICKHOUSE_STATUS=0 echo "$CLICKHOUSE_HOST is not available yet" fi i=$((i+1)) done if [ "$CLICKHOUSE_STATUS" -eq 0 ]; then echo "Clickhouse not ready. Sleeping for 10s before trying again" sleep 10; fi done echo "Clickhouse is up" echo "Checking if kafka is up" KAFKA_STATUS=0 while [ $KAFKA_STATUS -eq 0 ]; do KAFKA_STATUS=1 KAFKA_REPLICAS=3 i=0; while [ $i -lt $KAFKA_REPLICAS ]; do KAFKA_HOST=sentry-kafka-$i.sentry-kafka-headless if ! nc -z "$KAFKA_HOST" 9092; then KAFKA_STATUS=0 echo "$KAFKA_HOST is not available yet" fi i=$((i+1)) done if [ "$KAFKA_STATUS" -eq 0 ]; then echo "Kafka not ready. Sleeping for 10s before trying again" sleep 10; fi done echo "Kafka is up" image: subfuzion/netcat:latest imagePullPolicy: IfNotPresent name: db-check resources: limits: memory: 64Mi requests: cpu: 100m memory: 64Mi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst restartPolicy: Never schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 Clickhouse / Kafka 가 실행되어야 job은 정상화 가능하다. 시간이 오래걸리는 작업이므로, hook 의 시간을 늘려주면 job은 더 긴시간 대기한다 helm 의 values.yaml 에서 activeDeadlineSeconds를 늘려주면 된다. ...

topologySpreadConstraints 을 사용한 Karpenter 테스트를 진행하겠다. topologySpreadConstraints 테스트는 Topology Aware Hint 를 예비한 테스트다. https://aws.amazon.com/ko/blogs/tech/amazon-eks-reduce-cross-az-traffic-costs-with-topology-aware-hints/ 참고할 부분이 있다면 이 글을 참고하길 바란다. 간략하게 설명하자면 Kubernetes 에서 Cross Zone Traffic 의 문제로 비용이 막대하게 발생할수 있다. 또한 Cross-AZ로 인하여 약간의 레이턴시가 발생할수도 있기때문에 Topology Aware Hint는 여러 문제점들을 줄여주는 역할을 한다. 조건은 몇가지가 있는데, Service 로 연결되 AZ가 수평적으로 동일하게 노드가 배포되어있고 서비스에 apiVersion: v1 kind: Service metadata: name: service annotations: service.kubernetes.io/topology-aware-hints: auto 다음과 같은 annotations 붙어있어야 한다. ...

이제 카펜터의 CRD를 정리하고 어떻게 사용해야 하는지 이야기를 해보려고 한다. 거의 끝에 다왔다. https://www.linuxer.name/posts/eks-nodeless-05-aws-karpenter-component/ Karpenter Component 를 설명할때 CRD를 설명했었다. 다시 이야기 하자면 provisioners.karpenter.sh - provisioners - / awsnodetemplates.karpenter.k8s.aws -awsnodetemplates - 두가지를 셋팅해야 한다. 먼저 provisioners 를 이야기 해볼까 한다. apiVersion: karpenter.sh/v1alpha5 kind: Provisioner metadata: name: default spec: requirements: - key: karpenter.k8s.aws/instance-category operator: In values: [c, m, r] - key: karpenter.k8s.aws/instance-generation operator: Gt values: ["2"] providerRef: name: default https://karpenter.sh/v0.27.3/concepts/provisioners/ https://github.com/aws/karpenter/tree/main/examples ...

이번 포스팅은 Karpenter 설치다. 설치하다 막히면 가이드를 보자. https://karpenter.sh/v0.27.3/getting-started/migrating-from-cas/ karpenter 를 설치하기 전에 먼저 셋팅해야 할것들이 있다. CLUSTER_NAME=myeks # your clouster name AWS_PARTITION="aws" # aws or aws-gov or aws-cn AWS_REGION="$(aws configure list | grep region | tr -s " " | cut -d" " -f3)" OIDC_ENDPOINT="$(aws eks describe-cluster --name ${CLUSTER_NAME} \\ --query "cluster.identity.oidc.issuer" --output text)" AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' \\ --output text) export KARPENTER_VERSION=v0.27.3 # latast version 환경 변수 설정이다. ...

이제야 드디어 Karpenter까지 왔다. Karpenter의 구성요소부터 살펴보자! PodDisruptionBudget: PodDisruptionBudget은 클러스터의 안정성을 보장하기 위해 사용된다. 특정 서비스를 중단하지 않고 동시에 종료할 수 있는 Pod의 최대 수를 지정한다. ServiceAccount: Karpenter가 동작하려면 해당 권한을 가진 Kubernetes의 ServiceAccount가 필요하다. ServiceAccount는 Kubernetes 리소스에 대한 API 접근 권한을 제공한다. Secret-webhook-cert: Karpenter의 웹훅에 사용되는 TLS 인증서를 저장하는 Secret이다. 이를 통해 웹훅이 안전하게 통신할 수 있다. ConfigMap-logging: Karpenter의 로깅 설정을 저장하는 ConfigMap이다. 로깅 수준, 출력 형식 등을 지정할 수 있다. ...

AWS LoadBalancer Controller 도 Fargate에 올려야 한다. 비교적 간단한데, Controller Pod에 annotations 한줄만 추가하면된다. 먼저 추가할때 Policy 를 생성한다. VPC_NAME=myeks-VPC // VPC NAME 으로 변경 CLUSTER_NAME=myeks REGION=ap-northeast-2 curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.7/docs/install/iam_policy.json aws iam create-policy \\ --policy-name AWSLoadBalancerControllerIAMPolicy \\ --policy-document file://iam_policy.json POLICY_ARN=`aws iam list-policies | grep Arn | grep AWSLoadBalancerControllerIAMPolicy | awk -F\\" '{print $4}'` VPC_ID=$(aws ec2 describe-vpcs --query 'Vpcs[?contains(Tags[?Key==`Name`].Value[], `'$VPC_NAME'`) == `true`].[VpcId]' --output text) 이 Policy를 이용하여 eksctl에서 사용할거다. POLICY_ARN은 전체 Policy 에서 AWSLoadBalancerControllerIAMPolicy 의 arn을 추출한다. ...

NodeLess 컨셉에서 제일 중요한 역할을 맡고 있는 Karpenter 다. Karpenter 의 기본적인 아키텍처 부터 리뷰해볼까 한다. 그렇다면 그전에 Cluster Autoscaler 부터 설명해야 한다. Cluster Autoscaler 는 보통 CA라 부른다. 간략하게 플로우를 설명하겠다. Kubernetes에 새로운 Pod 가 프로비저닝 되었을때 Pod는 노드그룹에 스케줄링 된다. 노드그룹에 자원이 부족하면 CA가 트리거 된다. CA는 AWS 의 ASG에 새로운 로드를 요청한다. ASG는 새로운노드를 생성하고 노드그룹에 추가한다. 새로 스케줄링된 노드에 Pod가 생성된다. 생략된 단계가 있지만 실제로 이 단계를 모두 거쳐야 인스턴스가 EKS에 연결되고 노드그룹에 인스턴스가 노출된다. 그렇다면 단순히 ASG에서 노드를 제거해본 경험이 있는가? 있다면 알것이다. 이건 가끔 커피한잔하고 와도 제거안된 인스턴스가 있는 경우도 있다. ...