우리는 어떻게 kubernetes(EKS) 인프라 시설의 원가가 50%를 초과하는 것을 최적화할 수 있습니까?

높은 차원에서 볼 때 왜 Kubernetes(K8s)가 인기가 많은지 이해하기 쉽다. 그것은 유연하고 확장성이 있으며 원본을 개설한 편성기로서 용기 관리 임무를 간소화시켰다.
K8s의 장점, 예를 들어 이식성, 유연성, 구름 많은 능력과 커다란 지역사회 지원을 고려하여 우리는 우리의 마이크로서비스를 AWS 플랫폼의 K8s로 이전할 계획이다.
비용 최적화는 우리 조직에서 클라우드 실천의 핵심이다. K8에서 100여 개의 마이크로서비스를 이전한 후에 우리는 우리의 클라우드 원가를 최소화하기 위해 전략을 병행 구축하고 있다.
전체 워크로드를 K8s로 마이그레이션한 후, 우리는 최종적으로 40여 대의 c5.4XL 유형의 서버(작업 노드)(16코어 CPU 및 32GB RAM)를 보유하고 있으며, 이를 위해 매달 약 19600달러의 총 비용을 지불했다(각 사례는 시간당 @0.68달러).

비용을 최적화하기 위해 다음과 같은 전략을 제시합니다.

생각은 사무 시간 후에 환경을 줄이는 것이다(예를 들어qa/staging 환경).우리의 사례에서 집단은 저녁 8시에 축소되고 오전 8시에 확대된다.이외에도 k8s 집단은 주말에 축소될 예정이다.
이렇게 하면 비용은 집단 24*7 운행 시 발생하는 비용의 거의 절반으로 줄어들 것이다.

우리의 초보적인 방법은 다음과 같다.

어플리케이션은 4개의 AZ(가용성 영역)에 배치되며 클러스터의 서버 확장은 4개의 ASG(자동 배율 조정 그룹)가 관리하며 각 AZ에는 각각 1개의 ASG가 배치됩니다.우리는 ASG의 자동 배율 조정 기능을 이용하여 계획 작업을 사용하여 이러한 ASG의 최소값, 최대값 및 필요한 계수를 오후 8시에 0으로 설정하여 실행 중인 모든 POD가 정지된 상태로 다음날 아침, 계획 작업은 ASG의 최소값, 최대값과 필요한 계수를 각각 1, 10, 1로 설정하여 집단을 확장합니다.이것은 즉시 모든 매달린 기중기를 사용 가능한 작업 노드에 배치하려고 시도할 것이다. 이 작업 노드는 수요에 따라 점차적으로 확장하는 데 쓰일 것이다.

이러한 접근 방식이 직면한 과제:

만약 개발자가 퇴근 후나 주말에 일해서 하나의 응용 프로그램을 테스트하고 싶다면 어떻게 해야 합니까?

단지 하나의 응용 프로그램을 테스트하기 위해 전체 집단을 확장할 가치가 있습니까?

앞에서 말한 바와 같이 ASG를 축소하는 동시에 모든 기중기는 매달린 상태이다.따라서 비용을 절약하기 위해 최소값(1개 작업 노드), 최대값(10개 작업 노드), 필요값(1개 작업 노드)을 사용하여 단일 ASG를 확장하려 해도 개발자가 이 작업 노드에 예상한 크레인을 놓을 수 있는 행운이 충분합니까?

상술한 도전은 우리로 하여금 또 다른 해결 방안을 제시하게 했다

우리는 기본적으로 네 가지 상황을 해결할 수 있는 해결 방안을 제시했다.

전체 k8s 집단을 축소한다.

전체 k8s 집단을 확대한다.

사용자가 지정한 응용 프로그램을 확장합니다.

사용자가 지정한 응용 프로그램을 비례적으로 축소합니다.

참고: 코드 세그먼트에 다음과 같은 매개변수를 입력해야 합니다.

활동 – 예: scale\u up, scale\u down.

네임스페이스 - 그룹에 존재하는 모든 다른 네임스페이스, 예를 들어 기본값,kube시스템, 테스트 네임스페이스 등

Application_Name - 이 값은 사용자가 선택한 이름공간에 따라 채워집니다. 예를 들어 사용자가 테스트 이름공간을 선택하면 테스트 이름공간에 존재하는 모든 배치를 채워줍니다

.
"All"은 k8s 클러스터에 존재하는 모든 네임스페이스를 나타냅니다.

1. 전체 k8s 클러스터 축소:

Activity=scale\u down 및 Namespace=All (이것은 k8s 클러스터에 존재하는 모든 네임스페이스를 축소하는 것을 의미), 이 경우 Application\u Name=All (이전에 설명한 바와 같이 선택한 네임스페이스에 따라 자신을 채웁니다.
a. 명칭 공간이 모두 선택되었기 때문이다.스크립트는 다음 명령을 사용하여 배열 유형 변수의 모든 이름 공간을 가져옵니다.

 $ kubectl get namespaces

b. 모든 네임스페이스를 교체하고 각 네임스페이스에 배치하여 배포 규모를 0 던전으로 축소합니다.

 $ kubectl get deployment -n <namespace-name>
 $ kubectl scale deployment <deployment-name> -n <namespace-name> --replicas 0

c, 모든 ASG 축소:

 $ aws autoscaling update-auto-scaling-group --auto-scaling-group-name <ASG-name> --min-size 0 --max-size 0 --desired-capacity 0  

주의해야 할 사항:
i, 이런 상황은 전체 k8s 집단과 배치의 축소를 초래할 것이다.
2.현재 기중기는 이미 앞당겨 축소되었다.모든 기중기는 매달린 상태에 있지 않을 것이다.(이것은 우리가 상술한 도전 중의 세 번째 도전을 극복하는 데 도움이 된다)

2, 전체 k8s 클러스터 확장:

Activity=scale\u up 및 Namespace=All 의 경우 이 예제에서 Application\u Name=All (이전에 설명한 바와 같이 선택한 네임스페이스에 따라 자신을 채웁니다.
a, 모든 ASG 확대:

$ aws autoscaling update-auto-scaling-group --auto-scaling-group-name <ASG-name> --min-size 0 --max-size 10 --desired-capacity 1

b. Namespace=All 때문에 변수의 모든 네임스페이스를 다음과 같이 가져옵니다.

 $ kubectl get namespaces

c. 네임스페이스를 교체하여 각 네임스페이스에 배치하고 1개의 복사본으로 축소합니다.

$ kubectl get deployment -n <namespace-name>
$ kubectl scale deployment <deployment-name> -n <namespace-name> --replicas 1

참고 사항:
i, 이것은 전체 k8s 집단과 배치를 확장하는 것을 책임질 것이다.

3. 사용자 지정 어플리케이션 확대:

Activity=scale\u up, Namespace=test Namespace Application\u Name=test deployment(사용자가 선택한 네임스페이스를 사용하여 배포 이름을 가져오는 경우):
a, ASG 2개 확장(고가용성 보장):

    $ aws autoscaling  update-auto-scaling-group --auto-scaling-group-name <ASG-name> --min-size 0 --max-size 6 --desired-capacity 1

b. 사용자가 선택한 네임스페이스와 응용 프로그램을 확대합니다.

    $ kubectl scale deployment test-deployment -n test-namespace --replicas 1

주의해야 할 사항:
i, AWS EC2를 시작하고 실행하는 데 약 3분이 소요됩니다. 확장 배포 전에 180초의 수면 시간을 추가하십시오.
2.이것은 우리가 단일 응용 프로그램을 테스트할 때 인프라 시설을 과도하게 설정하지 않도록 보장한다.(이것은 상술한 첫 번째와 두 번째 도전을 초기 방법에서 극복하는 데 도움이 된다.)

4. 사용자 지정 적용 축소:

Activity=scale\u down, Namespace=test Namespace, Application\u Name=test deployment:
a. 사용자가 선택한 배포 축소:

    $ kubectl scale deployment test-deployment -n test-namespace --replicas 0

b.pod가 다른 이름 공간에서 실행되지 않았는지 확인하십시오 (만약 pod가 다른 이름 공간에서 실행된다면 다른 개발자가 각자의 응용 프로그램을 처리하고 있음을 나타냅니다)

    $ kubectl get namespaces   # get this in array variable and 
      iterate over it.

실행 중인pod를 얻기 위해 이름 공간을 교체합니다.

running_pods=`kubectl get pods --field-selector=status.phase=Running -n <other-namepaces> | grep -v NAME | awk '{print $1}'`

만약 변수 "running_pod"가 emtpy라면, 이것은 결론을 내릴 것입니다. pod가 다른 이름 공간에서 실행되지 않으면, 단계 c를 따르는 것이 좋습니다. 그렇지 않으면 단계 c를 건너뛰는 것이 좋습니다.
c, ASG 2개 축소

    $ aws autoscaling  update-auto-scaling-group --auto-scaling-group-name <ASG-name> --min-size 0 --max-size 0 --desired-capacity 0

주의해야 할 사항:
i. 위에서 언급한 절차 b는 여러 개발자가 업무 시간 후에 각자의 응용 프로그램을 처리할 수 있도록 확보하고 사용 후 집단을 축소함으로써 다른 개발자의 활동을 방해하지 않는다.
2.최종적으로 ASG의 노드 수는 감소할 것이다. 왜냐하면 개발자가 사용한 후에 각자의 응용 프로그램을 축소하기 때문이다.이것은 cpu 이용률을 더욱 낮추고 최종적으로 작업 노드의 규모를 축소시키며 우리가 인프라 시설을 과도하게 제공하지 않도록 할 것이다.

jenkinsfile를 사용하여 클라우드 환경에 특정한 스크립트를 구축하기 위해 이 코드 세션을 실행합니다.
cron을 사용하여 각각 오전 8시와 저녁 8시에 같은 작업을 터치하여 전체 집단을 확대하고 축소하며, 자동으로 팀messenger (마이크로소프트 팀, Slack 등과 유사한 모든 것을 사용할 수 있음) 에서 발생하는 축소 활동을 알립니다.
개발자가 퇴근 후나 주말에 응용 프로그램을 테스트하거나 개발하고 싶다면 같은 일을 할 수 있다.이런 상황에서 상술한 장면 3과 장면 4는 앞에서 정의한 매개 변수를 사용하여 집단 공급을 할 것이다.

우리가 뭘 할 수 있겠어?

상기 전략이 실시됨에 따라 낮은 환경에서 EC2 유형을 스팟 실례로 사용하면 케이크 위의 체리처럼 더욱 좋은 원가 최적화를 얻을 수 있다.

결론:

총결산우리는 기본적으로 퇴근 후에 인프라 시설을 축소하려고 시도한다. 이렇게 하면 개인이 퇴근 후에 일을 하고 싶어도 우리는 테스트가 필요한 응용 프로그램을 충족시키기 위해 충분한 인프라 시설을 제공할 수 있고 같은 k8s 집단에서 응용 프로그램을 테스트하는 다른 개발자들의 업무에 영향을 주지 않을 것이다.
유용한 링크:
https://kubernetes.io/docs/reference/kubectl/cheatsheet/