개요

이번 주차 마지막으로는 오토모드에 대해 알아본다.
오토모드는 사용자의 편의성을 더 극대화시켜주는 간편 모드라고 생각하면 편한데, 구체적으로 어떤 것들을 지원해주는지 알아보자.

원래 하이브리드 노드도 해보려고 했는데, 스케줄러 가지고 놀다가 시간 다 날아갔다..

사전 지식

오토모드란

오토모드는 EKS에서 자체적으로 데이터플레인에 필요할 만한 핵심적인 세팅들을 직접 관리해주는 모드이다.

기존에 클러스터를 운영할 때는 VPC CNI, ALB Controller, AWS EBS CSI Driver, 등 직접적으로 설치를 하고 관리해야 하는 애드온이 굉장히 많았다.
여기에 클러스터 오토스케일링이나 인스턴스의 버전 관리 등의 요소도 전부 사용자가 관리해야 하는 영역이었다.
그러나 이런 부분들은 실질적으로 eks를 사용하는데 있어 안 쓰는 케이스도 전무하다 싶기도 하고, 사용자가 운영하면서 실수가 날 수 있는 부분들이 종종 있었다.
이에 AWS에서 이런 부분까지도 통합적으로 관리하는 솔루션으로서 오토모드를 출시하게 된 것이다.

보다시피 컨트롤 플레인 관리 영역 뿐만 아니라, 위에서 언급한 다양한 부분들이 전부 aws의 관리 영역으로 들어간 채로 활용하는 것이 오토모드이다.
참고로 aws의 관리 영역이 늘어나는 만큼, 가격은 조금 더 비싸진다.

(가시다님 공유 자료)
오토모드의 노드에는 이미 다양한 것들이 기본 프로세스로 돌아간다.
흔히 클러스터를 운영할 때 파드로 띄우던 것들을 그냥 기본 프로세스로 동작을 시켜서 클러스터를 운영하는 사용자 입장에서는 각각을 신경 쓸 필요가 없게 된다.

기능

그래서 어떤 기능들이 구체적으로 있을까?

인스턴스

일단 사용되는 ami는 Bottlerocket으로, 기본적으로 컨테이너 환경에서 보안과 성능을 최적화한 인스턴스를 사용하게 된다.
(이것 때문에 노드 디버깅이 조금 어려워지는 효과가 있다..)

구성품

그리고 다음의 것들이 추가 세팅되어 aws에서 관리된다.
이것들은 전부 노드의 기본 프로세스로서 동작하기에 클러스터 차원에서 확인할 수는 없다.

• 클러스터 오토스케일링
  • 카펜터가 사용되는데 스펙이 조금 달라지기에 마이그레이션 시 주의가 필요하다.
• 네트워크
  • VPC CNI를 무조건 활용한다.
  • ALB Controller가 활성화된다.
  • Core DNS를 사용한다.(근데 이걸 안 쓰는 곳이 있기는 하냐? 거의 상상 속의 기린 아님?)
• 스토리지
  • AWS EBS CSI Driver가 활성화된다.
• 보안
  • pod identity agent가 활성화된다.

그러고 보니 모니터링 관련은 없네..?

업그레이드

애드온 버전, 인스턴스가 알아서 적당히 업그레이드된다.
클러스터 버전에 맞춰 애드온이 알아서 업데이트되니 이리 편할 수가 없다.
다만 노드가 업그레이드 된다는 것은 달리 말하자면 노드가 교체된다는 것이다.
노드의 교체에 따른 운영 장애 최소화를 위해 PDB 같은 것을 설정해두는 것이 좋다.
오토모드에서는 노드의 만료 기간을 설정해두어 적절한 시간이 지나면 새로운 노드가 뜨고 기존 노드가 없어진다.

유의사항

기본적으로 오토모드에서 안 되는 것들이 있는데, 이것들을 유의할 필요가 있다.

• 파드 별 보안 그룹은 지원하지 않는다.
• VPC CNI의 커스텀 네트워킹, warm IP, 접두사 위임 관련 설정을 지원하지 않는다.
• 네트워크 폴리시의 컨트랙 커스텀을 지원하지 않는다.

마이그레이션 시

기본적으로 설정되는 애드온과 툴들의 api 그룹과 버전이 달라지기 때문에, 마이그레이션에는 주의가 필요하다.
오죽하면 새로 클러스터를 만드는 게 낫다는 말이 나오는 게 아니다.
이렇게 변화를 주어 더 번거롭게 하는 데에는, 사실 마이그레이션 상의 장애를 줄이고자 하는 목적이 크다.
기존에 카펜터를 활용하던 조직에서 갑자기 오토모드를 도입하게 되면 기존 노드들이 새로 깔린 카펜터에 의해 관리되어버리는 불상사가 발생할 수 있다.
오토 모드 도입으로 인해 기존 클러스터에 차질이 생기는 것을 막기 위해, 운영자가 명시적으로 새롭게 양식을 마이그레이션하도록 유도하는 것이다.

실습 진행

테라폼 세팅

  cluster_compute_config = {
    enabled    = true
    node_pools = ["general-purpose"]
  }

테라폼에서 오토 모드를 세팅하는 것은 간단하다.
eks 리소스 블록에 위의 블록을 넣어주면 된다.
노드 풀은 카펜터가 동작할 때 기본으로 세팅할 노드풀을 지정한다.
여기에는 두 가지 방식이 가능한데, general-purpose가 흔히 사용하는 형태이다.
system의 경우에는 CriticalAddonsOnly라는 테인트가 붙는다.
이를 통해 클러스터의 핵심이 되는 애드온들만이 배치되는 노드풀이 된다.

기본 확인

콘솔에서는 eks 콘솔 바로 첫 탭에 오토모드에 대한 활성화여부가 출력된다.

설정한 대로 general-purpose 노드풀이 생성된 것을 확인할 수 있다.

보다시피 아무런 애드온이 없는 상태이다!
그럼에도 coredns, proxy 등 기본으로 활성화된 기능들이 있다는 것을 노드에 들어가면 보게 될 것이다.

액세스 엔트리를 보면 노드들이 기본으로 사용할 엔트리와, 각 애드온들이 수행될 때 필요한 엔트리가 생성되는 것을 볼 수 있다.

kubectl로 클러스터 상태도 관찰해보자.

kube-system 네임스페이스에는 여러 컨트롤러 매니저에 있던 컨트롤러들마다 서비스 어카운트가 만들어지는 것을 확인할 수 있다.

k get nodepools.karpenter.sh -oyaml

기본 노드풀은 이런 식으로 생겼다.
직접 카펜터를 세팅하지 않았음에도, 오토모드에서는 알아서 카펜터가 동작하고 있음을 확인할 수 있다.

k get crd

crd를 보면 여러 crd가 이미 사전에 설치돼있는데, 이미 이전에 각종 애드온들을 설치하고 활용해봤다면 전부 낯이 익을 것이다.

nodediagnostics 보기 - 실패

이 중 nodediagnostics라는 것은 처음 보는데, 이를 확인하기 위해 간단한 파드를 만들어보자.

apiVersion: v1
kind: Pod
metadata:
  name: debug
  namespace: default
spec:
  containers:
  - image: nicolaka/netshoot
    name: debug
    command:
    - sh
    - -c
    - "tail -f /dev/null"
    resources:
      limits:
        cpu: 100m
        memory: 100Mi
  terminationGracePeriodSeconds: 0

기본적으로 노드는 없는 상태였으나, 파드가 배포됨에 따라 카펜터가 알아서 노드를 추가해주었다.

이들은 전부 보틀로켓으로 만들어진다.

해당 노드에 매칭되는 노드클레임 역시 확인할 수 있다.
https://docs.aws.amazon.com/eks/latest/userguide/auto-get-logs.html
nodediagnostic은 직접 만들어야 하며, 이것을 사용하면 S3에 관련 정보를 저장하게 된다.

import boto3 
from datetime import datetime
import argparse

region = 'ap-northeast-2'
bucket_name = 'aews-eks-zerotay'
s3_client = boto3.client('s3', region_name=region)
key = datetime.now().strftime('%y-%m-%d') + '/logs.tar.gz'

def create_bucket():
    try:
        s3_client.create_bucket(Bucket=bucket_name, CreateBucketConfiguration={'LocationConstraint': region})
        return True
    except Exception as e:
        print(e)
        return False

def delete_bucket():
    response = s3_client.delete_bucket( Bucket=bucket_name)
    print(response)

def list_buckets():
    response = s3_client.list_buckets(BucketRegion=region)
    return map(lambda x: x["Name"], response["Buckets"])

def generate_presigned_url():
    url = s3_client.generate_presigned_url(
       ClientMethod='put_object',
       Params={'Bucket': bucket_name, 'Key': key},
       ExpiresIn=1000
    )
    return url

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="put subcommand")
    parser.add_argument("--delete", type=bool, default=False, help="delete the bucket or not")
    parser.add_argument("--get_list_only", type=bool, default=False, help="list buckets only")
    args = parser.parse_args()
    if args.delete:
        delete_bucket()
    else:
        bucket_lst =  list_buckets()
        print('Current buckects ::')
        print(list(bucket_lst))
        if args.get_list_only:
            exit(0)
        if bucket_name not in bucket_lst:
            print(f' Bucket {bucket_name} needs to be created...')
            if not create_bucket():
                raise Exception

        bucket_lst =  list_buckets()
        print('Current buckects ::')
        print(list(bucket_lst))
        url = generate_presigned_url()
        print('Presigned URL for putting objects')
        print(url)

간단하게 aws cli로도 s3는 만들 수 있는데, 찾아보니 put이 가능한 presigned url을 만드는 방법이 없다.
그래서 어쩔 수 없이 파이썬으로 대충 코드를 만들었다.

이런 식으로 presigned URL이 나오면 성공이다.
이제 이 값을 이용해 직접 nodediagnostic 오브젝를 만들어주면 된다.

apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
    name: 노드 이름
spec:
    logCapture:
        destination: 만들어진 url

제대로 만들었다고 생각했는데, 왜인지 fatal error가 계속 나왔다.
시도했던 방법은 다음과 같다.

• 혹시나? 해서 클라우드 쉘에서 파일 실행
• vpc에 액세스포인트 생성
• 퍼블릭 액세스 권한 열어두기
• put object 관련 허용 정책 설정
• 업로드한 주체에게 소유권 주기

s3 자체를 많이 사용해본 적이 없어 여러 방면으로 시도해봤으나, 전부 실패했다.
정확하진 않으나, 추측으로는 모니터링 정보를 업로드하는 주체는 해당 인스턴스인 것으로 보인다.


노드의 node monitoring agent가 동작하기 때문에 이게 가능하다고 언급됐기 때문이다.^[1][2]
그래서 생각에는 노드가 S3에 접근할 권한이 없는 것이 아닐까 생각한다.

관련한 자료도 일체 없고, 정확히 왜 실패했는지에 대한 정보를 알려주지 않기에 이대로는 제대로 테스트를 진행할 수 없다고 판단하여 nodediagnostic은 여기까지만 하고 포기했다.

debug 컨테이너로 노드 뜯어보기

kubectl debug node/i-009b014f5df4b636c -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023

노드의 정보를 보는데 저 방법만 있는 것은 아니다.
kubectl debug는 임시 컨테이너를 만들어준다는 것은 알고 있었지만, 노드에 대해 사용하면 호스트의 파일시스템을 사용하는 컨테이너가 생긴다는 것은 처음 알았다.

아무튼 이렇게 현재 노드의 상태를 이걸로도 볼 수 있다.

df를 쳐보면, 실제 노드의 파일시스템은 /host에 들어있는 것을 알 수 있다.

그래서 해당 디렉토리로 들어가면 실제 노드의 파일시스템을 볼 수 있게 된다.
기본적으로는 호스트의 파일시스템을 볼 수 있다고 하나, 아직 모든 호스트의 네임스페이스를 사용하고 있는 것은 아니다.
이를 위해서는 nsenter 명령어가 필요하다.

yum install -y util-linux-core net-tools

이러면 이제부터 nstenter를 쓸 수 있게 되고, 이걸 통해 루트 네임스페이스에 들어가 각종 명령어를 실행할 수 있게 된다.

nsenter -t 1 -m ip addr
nsenter -t 1 -m ps -ef
nsenter -t 1 -m ls -l /proc
nsenter -t 1 -m df -hT 

일단 네트워크 인터페이스에서는 파드 아이덴티티 agent, coredns를 위한 인터페이스가 마련되는 것이 보인다.

프로세스를 보면 오토모드에서 자체적으로 지원해준다던 각종 툴들이 바이너리 파일로 존재하며 이를 그냥 기본 프로세스로 실행하는 것을 볼 수 있다.
각 프로세스가 통신을 위해 참고하는 파일은 위에서 보았듯 /host/etc/kubernetes에 들어있다.
기본 실행되는 프로세스는 다음과 같다.

• eks 헬스체커
• kube proxy
• pod identity agent
• ebs csi driver와 칭구들
• node monitoring agent - 원래 위에서 nodediagnostic를 담당하는 애드온이다.
• vpc cni
• core dns

조금 의외라고 생각하는 것은, core dns가 모든 노드에서 실행된다는 것이다.
그런데 실제로도 core dns의 퍼포먼스 향상을 위해 로컬 dns 캐시를 설치하여 운용하는 경우도 왕왕 있으므로, 어쩌며 노드마다 설치되는 것도 그렇게 이상한 유스 케이스는 아닐 수도 있겠다는 생각도 든다.

또 유의미하게 본 포인트 중 하나는 카펜터와 alb 컨트롤러 프로세스가 존재하지 않는다는 것이다.
아무래도 클러스터를 스케일링하는 카펜터는 데이터 플레인에 상관없이 기동될 필요가 있기 때문에 추측컨대 마스터 노드에 위치해있을 것으로 보인다.
alb 컨트롤러 역시 노드의 존재 유무와 관련 없이 로드밸런서를 만들고 관리하는 작업을 해야 하므로 카펜터와 동일하게 마스터 노드에 있을 것 같다.

더 쉽지만 막힐 것 같은 방법 - hostPath

apiVersion: v1
kind: Pod
metadata:
  name: hostpath
spec:
  containers:
  - image: nicolaka/netshoot
    name: debug
    command:
    - sh
    - -c
    - "tail -f /dev/null"
    securityContext:
      privileged: true
    volumeMounts:
      - mountPath: /opt
        name: host
  hostNetwork: true
  hostPID: true
  hostIPC: true
  terminationGracePeriodSeconds: 0
  volumes:
    - name: host
      hostPath:
        path: /

디버그 컨테이너로 nsenter를 하는 것도 좋지만, 그보다 훨씬 쉬운 방법도 존재한다.
특권 권한으로 시큐리티 컨텍스트를 지정하고, 그냥 노드의 모든 네임스페이스를 공유해버리면 된다.
참고로 디버그 컨테이너를 사용할 때도 미리 템플릿 작성을 해서 적용하면 같은 방식으로 가능할 것이다.

아무튼 이렇게 쉽게 노드의 정보를 파악할 수 있다.

다만 읽기만 가능하고 쓰기는 불가능한 것을 확인할 수 있다.

기본 앱 배포

기본적으로 많은 게 세팅돼있지만, 이들을 직접적으로 사용하기 위해서는 직접 오브젝트를 만들어줘야 한다.

apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
  name: alb
spec:
  scheme: internet-facing
  group:
    name: aews-eks
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: eks.amazonaws.com/alb
  parameters:
    apiGroup: eks.amazonaws.com
    kind: IngressClassParams
    name: alb

일단 alb controller를 쓰기 위해 인그레스 클래스를 만든다.
오토모드에서는 가급적 ingressClassParams로 각종 세팅을 하도록 권장하고 있다.
아무래도 어노테이션을 사용하는 방식은 세팅에 대한 검증을 하기가 불편하기에 도입된 건데, 거의 아무도 안 쓰다 보니까 아예 오토모드에서는 못 박아둔 것 같기도..

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test
  annotations : 
    "alb.ingress.kubernetes.io/success-codes" :  "200-399"
    "alb.ingress.kubernetes.io/target-type" : "ip"
    "alb.ingress.kubernetes.io/load-balancer-name" : "aews"
    "alb.ingress.kubernetes.io/listen-ports" : '[{"HTTPS":443}, {"HTTP":80}]'
    "alb.ingress.kubernetes.io/ssl-redirect" : "443"
spec:
  ingressClassName: alb
  rules:
  - host: test.zerotay.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: test
spec:
  selector:
    app: test
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  labels:
    app: test
spec:
  selector:
    matchLabels:
      app: test
  replicas: 2
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: test
        image: public.ecr.aws/l6m2t8p7/docker-2048:latest
        resources:
          limits:
            cpu: 100m
            memory: 250Mi
        ports:
        - containerPort: 80
          name: test

세팅하고 나면 사용하는 방식은 동일하다.

문제 없이 배포되는 것을 볼 수 있다.

gpu 어플리케이션 배포 - 포기

이번에는 핫하다는 딥시크를 간단하게 배포해본다.^[3]

이 실습 포기 이유는 바로 아래, 사전 준비 때문이었다..

사전 준비

일단 사전 준비를 해줘야 할 게 있는데, 첫번째는 허깅페이스 api 토큰을 발급 받는 것이다.
여기에서 적당한 읽기 권한을 받아서 토큰을 가져온다.^[4]

k create secret generic hf-secret --from-literal hf_api_token=허깅페이스 키

해당 토큰은 바로 시크릿으로 만들어준다.

그리고 G 유형의 인스턴스를 쓸 건데, 서비스 쿼타를 미리 뚫어두지 않았다면 해당 타입의 인스턴스를 만들 수 없다.

You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.

내 경우에는 클라우드 트레일에서 뒤늦게 정보를 확인했다.

콘솔에서 서비스 쿼타를 치고, ec2에 대해 On-Demand G 인스턴스 유형에 대한 값을 올린다.

그럼 알아서 서포트 센터에 요청이 날아간다.

그아아아.. 얼마나 기다려야 하나..

허허.. 대충 4시간 뒤에 완료됐다..
이 글을 보는 당신은 꼭 미리 신청해두십쇼..
이 사진을 올리는 시점에 이미 다른 것들을 할 게 많아서 결국 이 실습은 더 이상 진행하지 못했다..
다만 조금이나마 세팅하려 했던 것들은 마저 정리해둔다.

노드 풀 생성

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: gpu-nodeclass
spec:
  role: terraform-eks-eks-auto-20250321013418751300000006
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "terraform-eks"
        Name: "*Public*"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "terraform-eks"
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-nodepool
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: gpu-nodeclass
      requirements:
        - key: "eks.amazonaws.com/instance-family"
          operator: In
          values: ["g5"]
        - key: "eks.amazonaws.com/instance-size"
          operator: In
          values: [ "2xlarge", "4xlarge", "8xlarge", "12xlarge", "24xlarge", "48xlarge" ]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
      taints:
        - key: "nvidia.com/gpu"
          value: "true"
          effect: NoSchedule
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s

다음으로는 실제 워크로드의 스펙을 만족하는 노드를 만들 수 있도록 적절한 노드풀과 클래스를 만드는 것이다.

예제로 사용할 인스턴스는 40 cpu에 90 기가, gpu 4개 이상이 있어야 한다..!

워크로드 배포

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vllm-deepseek-ingress
  annotations : 
    "alb.ingress.kubernetes.io/success-codes" :  "200-399"
    "alb.ingress.kubernetes.io/target-type" : "ip"
    "alb.ingress.kubernetes.io/load-balancer-name" : "aews"
    "alb.ingress.kubernetes.io/listen-ports" : '[{"HTTPS":443}, {"HTTP":80}]'
    "alb.ingress.kubernetes.io/ssl-redirect" : "443"
spec:
  ingressClassName: alb
  rules:
  - host: deepseek.zerotay.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: vllm-service
            port:
              number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm-deepseek-server
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-deepseek-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-deepseek-server
  template:
    metadata:
      labels:
        app: vllm-deepseek-server
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      automountServiceAccountToken: false
      containers:
      - name: inference-server
        image: vllm/vllm-openai@sha256:bfb0403010061e61b692e337945fb9694baefb03b0725d62adab9cca6139ea62
        imagePullPolicy: Always
        securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - NET_RAW
            seccompProfile:
              type: RuntimeDefault
        resources:
          requests:
            cpu: "40"
            memory: "90Gi"
            nvidia.com/gpu: 4 # 7B: 1 | 14B: 4 | 32B: 4 | 72B:
          limits:
            cpu: "48"
            memory: "96Gi"
            nvidia.com/gpu: 4 # 7B: 1 | 14B: 4 | 32B: 4 | 72B:
        args:
        - --model=$(MODEL_ID)
        - --dtype=auto
        - --enforce-eager
        - --trust-remote-code
        - --tensor-parallel-size=4 # Set to 8 to use all GPUs
        - --gpu-memory-utilization=0.99
        - --max-model-len=32768
        env:
        - name: MODEL_ID
          value: deepseek-ai/DeepSeek-R1-Distill-Qwen-32B # 7B, 14B, 32B Works --> testing bigger sizes now
        - name: PORT
          value: "8000"
        volumeMounts:
        - mountPath: /dev/shm
          name: dshm
        - mountPath: /secrets
          name: hf-secret-volume
          readOnly: true
      volumes:
      - name: dshm
        emptyDir:
          medium: Memory
      - name: hf-secret-volume
        secret:
          secretName: hf-secret
      tolerations:
        - key: nvidia.com/gpu
          value: "true"
          effect: "NoSchedule"

그다지 추가적인 세팅한 것 없이 정직하게 예제의 코드를 가져왔다.
보다시피 매우 큰 스펙을 요구하므로, 따로 노드풀을 만들어준 것이다.

는 서비스 쿼타가 빨리 안 풀려서 여기까지만 진행했다..

결론

오토모드는 다양한 부분에서 거의 모든 eks를 운영하는 조직이 활용하던 툴들을 aws에서 관리해줌으로서 운영 효율을 높여준다.
만약 운영 팀이 작은 조직이고, eks 도입을 처음으로 고려해보고 있는 조직이라면 오토모드는 매우 매력적인 모드라고 생각한다.
다만 이미 충분히 eks를 잘 다루고 있는 조직에서 굳이 비용을 추가적으로 들이며 오토모드로 마이그레이션을 할 이유는 없다.

만약 내가 일주일짜리 단기 프로젝트를 클러스터 환경에서 해야 하는데(어떤 케이스가 있을 수 있지..?) 운영만 하고 있을 수 없는 입장이라면, 그럴 때는 적극적으로 오토모드를 사용하지 않을까 싶다.

이전 글, 다음 글

• 7W - EKS Fargate: 18
• 8W - 아르고 워크플로우: 20

다른 글 보기

관련 문서

참고