AWS Fargate

AWS Fargate란?

기본 인프라를 관리할 필요 없이 컨테이너를 배포하고 관리할 수 있는 컴퓨팅 엔진

 

▶ Serverless형 쿠버네티스 서비스

---

Fargate로 Pod 동작시키기

 

먼저 Fargate Profile을 생성해준다.

이 때, 설정된 네임스페이스에서 동작하는 Pod는 모두 Fargate에서 동작한다고 보면 된다.

eksctl create fargateprofile --cluster <cluster_name> --name <fargate_profile_name> --namespace <kubernetes_namespace> --labels <key=value>

 

주의할 점은 Fargate의 프로파일을 생성할 때, Pod가 실행될 VPC의 서브넷을 지정하는데

이 서브넷은 프라이빗 서브넷이어야 한다.

그 이유는 pod는 사설 IP를 할당받기 때문에 인터넷 액세스를 위해선 공인 IP가 필요하고,

이 과정에서 NAT Gateway가 필요하기 때문이다.

 

nginx 파드 2개를 동작시킨다.

$ kubectl apply -f - <<EOF
> apiVersion: apps/v1
> kind: Deployment
> metadata:
>   name: fargate-sample-nginx
>   labels:
>     app: fargate-sample-nginx
> spec:
>   replicas: 2
>   selector:
>     matchLabels:
>       app: fargate-sample-nginx
>   template:
>     metadata:
>       labels:
>         app: fargate-sample-nginx
>     spec:
>       containers:
>         - name: fargate-sample-nginx
>           image: nginx
> EOF

 

동작중인 Pod를 확인하면 각각 다른 Node에서 Pod가 실행 중인 것을 확인할 수 있다.

$ kubectl get pod -o wide
NAME                                    READY   STATUS    RESTARTS   AGE     IP              NODE
         NOMINATED NODE   READINESS GATES
fargate-sample-nginx-597b8765cb-9sgnm   1/1     Running   0          2m56s   192.168.0.21   ip-192-168-0-21.us-west-2.compute.int
ernal    <none>           <none>
fargate-sample-nginx-597b8765cb-pbhdf   1/1     Running   0          2m56s   192.168.1.210   ip-192-168-1-210.us-west-2.compute.in
ternal   <none>           <none>

 

replica 수를 3으로 변경 시 자동으로 새로운 node가 생성되고, pod가 할당되어 동작한다.

이렇게 pod의 요구 용량에 맞추어 node가 동작하는데, 이 뜻은 노드의 Auto Scaling인 Cluster Autoscaler가

필요하지 않다는 뜻이다. (어차피 자동으로 확장되고 축소하니까)

또한 EKS 기반의 Fargate에선 pod와 node가 1:1로 매칭이 이루어진다.

이 뜻은 곧 하나의 격리된 VM 환경 내에 하나의 pod만 실행되는 것이기 때문에 굳이 두 개의 IP를 사용할 필요가 없어진다.

$ kubectl scale deployment fargate-sample-nginx --replicas=3
deployment.apps/fargate-sample-nginx scaled

$ kubectl get pod -o wide
NAME                                    READY   STATUS    RESTARTS   AGE     IP              NODE
  NOMINATED NODE   READINESS GATES
fargate-sample-nginx-597b8765cb-9sgnm   1/1     Running   0          9m14s   192.168.0.21   ip-192-168-0-21.us-west-2.compute.internal
  <none>           <none>
fargate-sample-nginx-597b8765cb-pbhdf   1/1     Running   0          9m14s   192.168.1.210   ip-192-168-1-210.us-west-2.compute.internal
  <none>           <none>
fargate-sample-nginx-597b8765cb-zxv5r   1/1     Running   0          53s     192.168.2.24   ip-192-168-2-24.us-west-2.compute.internal
  <none>           <none>

✅참고사항

Kubernetes에서는 공식적으로 클러스터당 5000개 이상의 Node의 오퍼레이션에 대하여 보장하지 않는다.

 

제약 사항

1. Fargate는 host가 없기 때문에 Host 기준의 옵션 사용이 불가능하다.

• 호스트 네트워크에 직접 연결하는 hostport, hostnetwork 사용 불가능

• Worker node의 호스트 당 pod 하나를 보장해주는 Daemonset 사용 불가능

 

2. Calico CNI와 같은 네트워크 정책 에이전트의 사용이 불가능하다.

• Calico와 같은 에이전트 또한 데몬셋 사용을 전제로 하기 때문이다.

 

3. ELB / NLB 사용이 불가능하다.

이 부분은 ELB + Ingress / NLB + Ingress 등의 조합으로 사용할 수 있어서, 

불가능하다고 보긴 어렵다.

 

데몬셋은 보통 로그 수집이나 노드 모니터링에 활용된다.

앞선 실습에서 CloudWatch 서비스를 사용하여 모니터링을 할 때의 구조를 보면,

데몬셋으로 fluentd 컨테이너를 동작시켜 로그를 확인했었는데 이러한 방법이 불가능하다는 뜻이다.

 

해결 방법

metricbeat라는 컨테이너를 CloudFormation을 통해 배포한다.

TaskDefinition: 
   Type: AWS::ECS::TaskDefinition 
   ...
   (생략)
   ...
     ContainerDefinitions: 
       - Name: metricbeat-container 
         Image: docker.elastic.co/beats/metricbeat:7.11.0

Elastic Observability로 Amazon ECS를 모니터링하는 방법

 

Fargate 요금

1. 사용한 만큼만 지불한다.

2. 계속해서 요금을 인하하고 있다.

 

Fargate 사용 사례

1. 배치 처리 등 일시적, 혹은 정기적으로 많은 리소스를 사용해야 하는 경우

2. 불규칙적이고 단발적으로 부하가 높아지는 워크로드의 경우

 

---

쿠버네티스의 에코시스템

현 쿠버네티스의 생태계라고도 볼 수 있으며, 아래 모든 환경에서 쿠버네티스가 동작한다.

 

그럼, 이렇게 쿠버네티스와 관련된 도구가 활발히 개발되고 있는 이유를 알아보자.

 

쿠버네티스의 확장성 = 플러거블(Pluggable)

Pluggable Cloud

-> 퍼블릭/프라이빗 클라우드를 교체할 때 기반 애플리케이션의 의존성을 많이 바꾸지 않아도 되는 멀티클라우드 구성

 

Pluggable Kubernetes

-> 새로운 릴리즈가 나오면 쉽게 업그레이드가 가능하고,

    스토리지, 네트워크, 스케쥴러, 컨테이너 런타임 등을 대체 가능하고 개선할 수 있도록 해준다.

---

 

쿠버네티스의 조정 루프(Reconciliation Loop)

 

조정 루프

- 의도한 상태와 실제 상태를 일치시키기 위해 리소스를 조정하는 작업을 반복하는 것

 

쿠버네티스는 이 조정루프를 근거로 리소스를 관리한다.

크게 커스텀 리소스 정의와 커스텀 리소스 컨트롤러로 구현한다.

 

커스텀 리소스 정의

매니페스트의 kind에 리소스 타입을 설정하고 아래에 여러 설정 정보를 정의한다.

이 자체만으로는 리소스를 정의한 틀이기 때문에 아무 작업이 일어나지 않는다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx-app

 

커스텀 리소스 컨트롤러

커스텀 리소스 정의로 등록된 리소스라면 kind 아래에 설정된 각종 속성을 읽어오고,

그 속성을 기반으로 실제 원하는 처리를 설정하여 사용한다.

 

운영 자동화

쿠버네티스 리소스를 관리하는 것에만 그치지 않고, 예를 들어 AWS SDK를 사용하여

실제 서비스를 배포할 수도 있다.

이렇게 하면 쿠버네티스만 이용하여 AWS 리소스까지 관리할 수 있게 된다.

 

이와 같이 커스텀 리소스를 이용해서 운영을 자동화하는 구조를 '오퍼레이터(Operator)'라고 한다.

< OperatorHub.io >

 

---

Helm

헬름은 쿠버네티스 차트를 관리하기 위한 도구이다.

차트는 리소스를 하나로 묶은 패키지인데, 예를 들어 nginx를 설치하기 위한 pod, service, deployment를 위한 YAML 파일 등이 여기에 포함된다.

헬름으로 차트를 관리하는 목적은 자칫 번잡해지기 쉬운 매니페스트 파일을 관리하기 쉽게 하기 위한 것이다.