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를 늘려주면 된다. ...

보통 개발자의 자리이동은 세개의 의자가 있어야지만 가능하다. 빈의자 = 개발자1 개발자1 = 개발자2 개발자1 = 빈의자 그런데 XOR를 이용하면 두개의 의자 만으로도 이동이 가능하다. 개발자1 ^= 개발자2 개발자2 ^= 개발자1 개발자1 ^= 개발자2 GPT의 답변이다. 나는 이런 방법이 있을거라 생각도 못했었다. 그러던중 현대의 컴파일러에선 XOR가 메모리를 사용하지 않지만 병렬처리에서의 문제로 성능이 떨어진다는 이야기를 들었다. 항상 자세한 설명과 함께 도움주시는 pr0gr4m 님. 느려지는게 맞다고 하셔서 궁금해서 돌려봤다. import timeit # temp 사용 def swap_temp(): a = 5 b = 10 temp = a a = b b = temp return a, b # XOR 사용 def swap_xor(): a = 5 b = 10 a ^= b b ^= a a ^= b return a, b # 성능 테스트 temp_time = timeit.timeit("swap_temp()", setup="from __main__ import swap_temp", number=1000000) xor_time = timeit.timeit("swap_xor()", setup="from __main__ import swap_xor", number=1000000) print(f"Using temp: {temp_time} seconds") print(f"Using XOR: {xor_time} seconds") 코드를 여러번 실행해 봤고 결론을 얻었다. ...

아직 이걸 설정 안했다면 반드시 하길 바란다. 우리는 AWS를 다루면 항상 해킹의 위험에 당면한다. 미리 막는다면 너무좋은 일이겠으나, 그렇지 못한경우가 많다. 해킹을 당한다 하여도 문제들을 간단하게 캐치할수 있는 방법이 있다. 보통 AWS계정이 해킹당하면 해커의 니즈는 컴퓨팅 리소스를 사용하여 채굴을 돌리려고 한다. 이 과정에서 EC2를 만들게 되고, EC2의 생성을 모니터링 할수 있는 방법이 있다면, 조기에 해킹을 진압할수 있을 것이다. 이번에 나온AWS User Notifications 서비스가 그 니즈에 완벽하게 부합하다. 이미지 대로 생성하자, 활성화되지 않은 계정의 리전들은 서비스노티도 안되거나 서비스가 런칭되지 않아서 리전에서 제외해야한다. 초기 한국계정으로 선택되지 않은 리전이다. ...

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을 추출한다. ...

바쁜 와중에 요즘 자격증 추가가 좀 뜸한거 같아서 2022년 말에 도전했다가 떨어진 FOCP를 다시 도전하였다. FOCP의 경우에는 Practitioner 자격이라 난이도가 높지는 않다. 하지만 자격증에서 요구하는 바가 일반적인 IT의 시각이 아니다. FinOps는 재무와의 연결도 포함하고있어서 단순히 DevOps로서의 사일로 뿐만아니라 조직에 대한 사일로 까지 없애려는 노력을 해야하기 때문이다. 시험의 모든내용은 FinOps Foundation 에 공개되어있다. 그렇기에 어느정도 FinOps문화를 이해할 준비가 되었다면 시험을 볼만하다고 생각한다. 문제가 되었던 장벽은 다음과 같다. 시험가격 $300 시험가격 $300 ...