SK 플랫폼 Architect

Cluster Autoscaler 비교(k8s Autoscaler vs Karpenter)

알 수 없는 사용자 — Mon, 25 Jul 2022 13:56:50 +0900

Cloud 의 장점은 여러 가지가 있지만 그 중 탄력성 및 유연성에 관련된 주제를 다뤄보고자 합니다. 바로 Autoscaling 입니다.

Kubernetes 환경에서 Autosclaing 은 VPA(Vertical Pod Autoscaler), HPA(Horizontal Pod Autoscaler) 그리고 CA(Cluster Autoscaler) 로 구분해서 볼 수 있으며 본 포스트에서는 CA 솔루션을 분석하였습니다.

CA 는 크게 두가지 솔루션이 있습니다.

기존 쿠버네티스 공식 서브 프로젝트 중 하나인 Autoscaler 를 이용하는 것이 첫번째 이고,

AWS 에서 오픈소스 프로젝트로 얼마전 GA 한 Karpenter 가 두번째입니다.

k8s Cluster Autoscaler

k8s Cluster Autoscaler (on AWS) 의 동작 로직입니다.

참고로 k8s Cluster Autoscaler 를 이용한 노드 오토스캐일링은 각 CSP 별로 구현 방식에 차이가 있으니 kubernetes 구성 환경에 맞춰 확인하시길 바랍니다.

간단히 정리하면 Node 리소스 부족으로 Pending 중인 Pod 를 감지하면 ASG(autoscaling group) 에 desired capacity 늘려서 요청하게 되고 그렇게 추가된 신규 노드에 kube-scheduler 가 Pending 중인 Pod 를 배치하게 됩니다.

워크로드가 줄어들어 불필요 노드가 발생한 경우 노드 삭제(Scale-In) 도 가능합니다.

기본적으로 Scan interval 이 10초이며 이때마다 삭제 가능한 노드가 있는지 확인합니다. 만약 지정된 utilization-threshold(defaul : 50%) 보다 수치가 떨어지게 되면 Autoscaler 는 Pod 재배치를 통해 노드를 비우고 삭제하게 됩니다. 참고로 기준값은 Pod 의 Request 값입니다. (실제 리소스 사용률은 관계 없음)

<주요 파라미터>

Parameter	Description	Default
scan-interval	How often cluster is reevaluated for scale up or down	10초
scale-down-delay-after-add	How long after scale up that scale down evaluation resumes	10분
scale-down-unneeded-time	How long a node should be unneeded before it is eligible for scale down	10분
scale-down-utilization-threshold	Node utilization level, defined as sum of requested resources divided by capacity, below which a node can be considered for scale down	0.5

다만 아래 조건이 있다면 Autoscaler 는 파드 재배치 및 노드 삭제를 진행하지 못합니다.

PodDisruptionBudget이 설정되어있을때
kubesystem namespace를 가진 pod가 있을때 ( 단 디폴트로 뜨는 kube-system 의 pod 는 예외. eg) kube-proxy )
pod를 다른 node로 이동할 수 없을 때 (lack of resources, non-matching node selectors or affinity, matching anti-affinity, etc)
Pod 에 "cluster-autoscaler.kubernetes.io/safe-to-evict" : "false" 어노테이션이 설정 되어있는경우.
Pods that are not backed by a controller object (so not created by deployment, replica set, job, stateful set etc). *
로컬 스토리지를 사용하는 파드가 있는 경우

Karpenter

다음은 Karpenter 입니다.

카펜터는 스케줄링 되지 못하는 파드에 대응해 노드를 자동으로 추가해주는 AWS 의 오토스케일링 오픈소스 툴입니다. 물론 불필요한 노드를 줄이는 기능도 포함됩니다. 카펜터는 Pending 된 파드 resoure request의 합을 기반으로 적절한 인스턴스 타입을 결정하는 것이 특징입니다. re:Invent 2021 에서 Karpenter 를 공식 발표하였으며 v0.5 의 정식 버전 오픈했다(GA). 즉 프로덕션 환경에서 사용할 정도의 안정성을 지녔음을 의미하며 또한 구조상 AWS 외 다른 CSP 에서도 동작 가능합니다. (다만 현재 버전에서는 EKS 외 다른 클러스터에서는 지원이 불가)

동작 로직입니다.

가용 노드가 없어 Pod 가 배치되지 못하면 Karpenter 가 해당 사실 인지

Custom Resource 인 Provisioner 가 어떤 instance type 으로 배포할 지 (Spot 사용 여부 등) 결정

노드가 배포 되면 karpenter 가 직접 해당 노드로 바인딩

Karpenter 가 노드 Provisiong 및 Pod scheduling 에 직접 관여하면서 성능(속도)가 많이 개선되었습니다.

Pod pending 후 creating 까지 소요시간을 보면 아래와 같이 3배 정도 빨라진 것을 확인할 수 있습니다.

노드 삭제(deprovisioned) 의 경우 아래와 같은 방법으로 수행됩니다.

Provisioner Deletion : provisiner 가 삭제될 시
Node empty : 노드에 daemonset 을 제외한 파드가 없을 시 ttlSecondsAfterEmpty 값에 따라 삭제
Node expired : 노드가 생성된 후 업데이트 등의 목적으로 ttlSecondsUntilExpired 값에 따라 삭제
manual deleted : kubectl 로 사용자가 임의 삭제

만약 Scale-in 을 원하지 않는 파드(노드) 가 있다면 아래와 같은 조건으로 회피 가능합니다.

Disruption budgets 가 설정된 파드가 있고 해당 노드에서 삭제할 수 없는 상황인 경우
파드에 do-not-evict 어노테이션이 설정된 경우 (karpenter.sh/do-not-evict: true) : 해당 노드 유지

기존 솔루션(k8s autoscaler) 과 신규 솔루션(Karpenter) 를 간단히 비교하면 다음과 같습니다.

운영 환경에 맞춰 솔루션을 선택하는 것은 사용자의 몫입니다.

다만, Karpenter 가 신규 프로젝트이고 계속 버전 업데이트가 되면서 기능이 추가 되는 상황을 생각하면 Autoscaler 첫 도입시 Karpenter 를 고려해볼 만도 합니다.

문의 사항은 fernweh@sk.com 로 보내주시던가 여기 댓글에 남겨주세요.

Kubernetes 백업 및 복구 솔루션 비교 (Velero, Kasten)

알 수 없는 사용자 — Mon, 30 May 2022 17:56:43 +0900

Kuberntes 는 다양한 환경에서 사용되고 있습니다. 보다 많은 Workload 를 수용하고, Mission Critical 서비스를 적용하는 사례가 늘고 있습니다. 그러나 백업/복구 체계가 잘 갖춰진 사이트는 그렇게 많지 않습니다.

이전부터 Legacy 환경에서는 Agent 방식을 사용해 OS,Data 영역을 백업/복구해 왔으며, IaaS 기반 가상화 환경에서는 VM 을 Image 상태로 저장하고 손쉽게 복원할 수 있습니다. 하지만 k8s 환경에서는 앞서 얘기한 두가지 방식으로는 온전히 백업/복구를 수행할 수 없습니다.

쿠버네티스 환경에서는 크게 아래 항목들이 백업 대상에 포함되어야 합니다.

Dockerfile 또는 Container Image
Persistent volume (storage)
etcd (cluster DB)
kubernetes resource (manifest file)

Velero

velero 는 vmware 에서 관리하는 Kubernetes 클러스터 오픈 소스 백업 및 DR 툴입니다(이전 Heptio Ark) . 전체 클러스터 또는 개별 네임스페이스 또는 레이블의 예약된 백업을 실행할 수 있도록 합니다. 다른 툴이 etcd 에 직접 접근하여 백업을 수행하는 반면, velero 는 API 를 사용하여 리소스 상태를 저장하고 복구합니다. 이런 API-Driven 방식 tool 의 이점은 아래와 같습니다 .

namespace, resource type, label selector별로 선택하여 리소스를 캡쳐할 수 있으므로 백업/복구의 유연성이 높습니다.
CSP 의 관리형 k8s 를 사용하는 경우 etcd 를 직접 접근할 수 없지만 API 는 가능합니다.

또한 아래와 같이 구성됩니다.

k8s 클러스터 내 설치되는 Pod 형태의 Server
command-line client (사용자 PC)
Object Stroage (백업 파일 저장)

The Velero client makes a call to the Kubernetes API server to create a Backup object.
The BackupController notices the new Backup object and performs validation.
The BackupController begins the backup process. It collects the data to back up by querying the API server for resources.
The BackupController makes a call to the object storage service – for example, AWS S3 – to upload the backup file.

Install

공식 velero Docs 및 다른 blog 에서도 설치과정은 쉽게 찾을 수 있기에 본 Post 에서는 상세 설치 과정은 생략합니다.

Prerequisites

kubernetes 클러스터가 접근 가능한 Clinet (kubectl 수행 가능)

Install CLI

Client 운영체제에 따라 설치 (자세한 내용은 https://velero.io/docs/v1.8/basic-install/ 참조. '22년 3월 기준 최신 버전은 v1.8)

MacOS - Homebrew
GitHub release (tar)
Windows - chocloatey

Install and configure the server components

Cluster Provider 환경에 따라 설치 (자세한 내용은 https://velero.io/docs/v1.8/supported-providers/ 참조) - 아래는 AWS 기준

Create S3 buckek ( 백업 파일 저장 용도 )
Set permissions for Velero ( S3 접근 권한 설정 )
Install and start Velero ( 클러스터 내 velero server 배포 )

Use

Case 에 따라 DR, Cluster migration, 정기/임시 백업 등 다양한 목적으로 사용할 수 있으며 아래는 전체 클러스터 백업(PV 포함), 특정 네임스페이스 복구를 테스트해 봤습니다.

현재 클러스터 내 resource 확인

(⎈ |jhs-eks-work-cluster:wordpress-cwi) eks-velero  k get all -A
NAMESPACE       NAME                                             READY   STATUS      RESTARTS   AGE
eks-work        pod/appjs-pbn5q                                  1/1     Running     0          7d22h
eks-work        pod/backend-app-7dccc69568-bxpqm                 1/1     Running     0          7d7h
eks-work        pod/backend-app-7dccc69568-mdxrk                 1/1     Running     0          7d7h
eks-work        pod/batch-app-27475710-tqj7v                     0/1     Completed   0          10m
eks-work        pod/batch-app-27475715-8pc95                     0/1     Completed   0          5m21s
eks-work        pod/batch-app-27475720-trvjk                     0/1     Completed   0          21s
eks-work        pod/centos-64ff4d9b-57ld6                        1/1     Running     0          7d22h
eks-work        pod/network-test                                 1/1     Running     0          8d
eks-work        pod/nginx-pod                                    1/1     Running     0          8d
kube-system     pod/aws-node-jlnqb                               1/1     Running     0          10d
kube-system     pod/aws-node-twzkj                               1/1     Running     0          10d
kube-system     pod/coredns-6dbb778559-2lfg4                     1/1     Running     0          10d
kube-system     pod/coredns-6dbb778559-4zgpr                     1/1     Running     0          10d
kube-system     pod/kube-proxy-96pv5                             1/1     Running     0          10d
kube-system     pod/kube-proxy-mczbt                             1/1     Running     0          10d
kube-system     pod/metrics-server-64cf6869bd-j62vx              1/1     Running     0          10d
velero          pod/velero-879fff5fc-j9prd                       1/1     Running     0          4d2h
wordpress-cwi   pod/understood-zebu-mariadb-0                    1/1     Running     0          4d21h
wordpress-cwi   pod/understood-zebu-wordpress-68fbc786c4-vz65r   1/1     Running     0          4d21h

NAMESPACE       NAME                                TYPE           CLUSTER-IP       EXTERNAL-IP                                                                    PORT(S)                      AGE
default         service/kubernetes                  ClusterIP      10.100.0.1       <none>                                                                         443/TCP                      10d
eks-work        service/backend-app-service         LoadBalancer   10.100.252.166   a7fd24eb308c743f7a7a34962327bb36-1014081366.ap-northeast-2.elb.amazonaws.com   8080:30907/TCP               7d6h
kube-system     service/kube-dns                    ClusterIP      10.100.0.10      <none>                                                                         53/UDP,53/TCP                10d
kube-system     service/metrics-server              ClusterIP      10.100.245.118   <none>                                                                         443/TCP                      10d
wordpress-cwi   service/understood-zebu-mariadb     ClusterIP      10.100.111.97    <none>                                                                         3306/TCP                     4d21h
wordpress-cwi   service/understood-zebu-wordpress   LoadBalancer   10.100.233.186   a12b1077cb2b94cfb92c6b0f8e19e5c6-798956363.ap-northeast-2.elb.amazonaws.com    80:31877/TCP,443:30075/TCP   4d21h

NAMESPACE     NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
kube-system   daemonset.apps/aws-node     2         2         2       2            2           <none>          10d
kube-system   daemonset.apps/kube-proxy   2         2         2       2            2           <none>          10d

NAMESPACE       NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
eks-work        deployment.apps/backend-app                 2/2     2            2           7d7h
eks-work        deployment.apps/centos                      1/1     1            1           7d22h
kube-system     deployment.apps/coredns                     2/2     2            2           10d
kube-system     deployment.apps/metrics-server              1/1     1            1           10d
velero          deployment.apps/velero                      1/1     1            1           4d2h
wordpress-cwi   deployment.apps/understood-zebu-wordpress   1/1     1            1           4d21h

NAMESPACE       NAME                                                   DESIRED   CURRENT   READY   AGE
eks-work        replicaset.apps/appjs                                  1         1         1       7d22h
eks-work        replicaset.apps/backend-app-7dccc69568                 2         2         2       7d7h
eks-work        replicaset.apps/centos-64ff4d9b                        1         1         1       7d22h
kube-system     replicaset.apps/coredns-6dbb778559                     2         2         2       10d
kube-system     replicaset.apps/metrics-server-64cf6869bd              1         1         1       10d
velero          replicaset.apps/velero-879fff5fc                       1         1         1       4d2h
wordpress-cwi   replicaset.apps/understood-zebu-wordpress-68fbc786c4   1         1         1       4d21h

NAMESPACE       NAME                                       READY   AGE
wordpress-cwi   statefulset.apps/understood-zebu-mariadb   1/1     4d21h

NAMESPACE   NAME                      SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
eks-work    cronjob.batch/batch-app   */5 * * * *   False     0        22s             6d23h

NAMESPACE   NAME                           COMPLETIONS   DURATION   AGE
eks-work    job.batch/batch-app-27475710   1/1           10s        10m
eks-work    job.batch/batch-app-27475715   1/1           10s        5m22s
eks-work    job.batch/batch-app-27475720   1/1           10s        22s
(⎈ |jhs-eks-work-cluster:wordpress-cwi) eks-velero 
(⎈ |jhs-eks-work-cluster:wordpress-cwi) eks-velero  k get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                          STORAGECLASS   REASON   AGE
pvc-9f7733ef-2cb3-479c-ad4e-cd16cd1e94d1   8Gi        RWO            Delete           Bound    wordpress-cwi/data-understood-zebu-mariadb-0   gp2                     4d21h
pvc-f555d44a-93e1-4773-9e06-d8aef53142a3   10Gi       RWO            Delete           Bound    wordpress-cwi/understood-zebu-wordpress        gp2                     4d21h

클러스터 전체 백업
- 552 개 item 및 2개 pv (block strage) 에 대해 백업 완료 : 8초 소요
- 보다 많은 workload 가 실행 중인 다른 클러스터도 수분 내에 백업 완료됨

(⎈ |jhs-eks-work-cluster:wordpress-cwi) eks-velero  velero backup create first
Backup request "first" submitted successfully.
Run `velero backup describe first` or `velero backup logs first` for more details.
(⎈ |jhs-eks-work-cluster:wordpress-cwi) eks-velero  velero backup describe first
Name:         first
Namespace:    velero
Labels:       velero.io/storage-location=default
Annotations:  velero.io/source-cluster-k8s-gitversion=v1.21.5-eks-bc4871b
              velero.io/source-cluster-k8s-major-version=1
              velero.io/source-cluster-k8s-minor-version=21+

Phase:  Completed

Errors:    0
Warnings:  0

Namespaces:
  Included:  *
  Excluded:  <none>

Resources:
  Included:        *
  Excluded:        <none>
  Cluster-scoped:  auto

Label selector:  <none>

Storage Location:  default

Velero-Native Snapshot PVs:  auto

TTL:  720h0m0s

Hooks:  <none>

Backup Format Version:  1.1.0

Started:    2022-03-25 15:22:58 +0900 KST
Completed:  2022-03-25 15:23:06 +0900 KST

Expiration:  2022-04-24 15:22:58 +0900 KST

Total items to be backed up:  552
Items backed up:              552

Velero-Native Snapshots:  2 of 2 snapshots completed successfully (specify --details for more information)

워드프레스가 설치된 wordpress-cwi namespace 삭제 ( 실수로 가정 )

### namespace 삭제 (해당 namespace 상 모든 resource 삭제) 
(⎈ |jhs-eks-work-cluster:default) eks-velero  k delete ns wordpress-cwi
namespace "wordpress-cwi" deleted
(⎈ |jhs-eks-work-cluster:default) eks-velero  k get all -n wordpress-cwi
No resources found in wordpress-cwi namespace.
(⎈ |jhs-eks-work-cluster:default) eks-velero  k get pv
No resources found
(⎈ |jhs-eks-work-cluster:default) eks-velero  helm3 list -A
NAME	NAMESPACE	REVISION	UPDATED	STATUS	CHART	APP VERSION
(⎈ |jhs-eks-work-cluster:default) eks-velero 
(⎈ |jhs-eks-work-cluster:default) eks-velero 

### velero 로 해당 namespace 만 복구 ( 26개 Item 에 대해 복구 3초 소요 ) 
(⎈ |jhs-eks-work-cluster:default) eks-velero  velero restore create --from-backup first --include-namespaces wordpress-cwi
Restore request "first-20220329180923" submitted successfully.
Run `velero restore describe first-20220329180923` or `velero restore logs first-20220329180923` for more details.
(⎈ |jhs-eks-work-cluster:default) eks-velero 
(⎈ |jhs-eks-work-cluster:default) eks-velero  velero restore describe first-20220329180923
Name:         first-20220329180923
Namespace:    velero
Labels:       <none>
Annotations:  <none>

Phase:                       Completed
Total items to be restored:  26
Items restored:              26

Started:    2022-03-29 18:09:26 +0900 KST
Completed:  2022-03-29 18:09:29 +0900 KST

Backup:  first

Namespaces:
  Included:  wordpress-cwi
  Excluded:  <none>

Resources:
  Included:        *
  Excluded:        nodes, events, events.events.k8s.io, backups.velero.io, restores.velero.io, resticrepositories.velero.io
  Cluster-scoped:  auto

Namespace mappings:  <none>

Label selector:  <none>

Restore PVs:  auto

Preserve Service NodePorts:  auto

### Pod 기동 중 
(⎈ |jhs-eks-work-cluster:default) eks-velero  k get all -n wordpress-cwi
NAME                                             READY   STATUS              RESTARTS   AGE
pod/understood-zebu-mariadb-0                    0/1     ContainerCreating   0          20s
pod/understood-zebu-wordpress-68fbc786c4-vz65r   0/1     ContainerCreating   0          20s

NAME                                TYPE           CLUSTER-IP      EXTERNAL-IP                                                                    PORT(S)                      AGE
service/understood-zebu-mariadb     ClusterIP      10.100.83.99    <none>                                                                         3306/TCP                     20s
service/understood-zebu-wordpress   LoadBalancer   10.100.15.218   aa74b993bd5b347c693e6e0553e0b7f1-1811961745.ap-northeast-2.elb.amazonaws.com   80:31402/TCP,443:31785/TCP   20s

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/understood-zebu-wordpress   0/1     1            0           20s

NAME                                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/understood-zebu-wordpress-68fbc786c4   1         1         0       20s

NAME                                       READY   AGE
statefulset.apps/understood-zebu-mariadb   0/1     19s

### 모든 Pod 기동 완료 및 helm release 복구 
(⎈ |jhs-eks-work-cluster:default) eks-velero  k get all -n wordpress-cwi
NAME                                             READY   STATUS    RESTARTS   AGE
pod/understood-zebu-mariadb-0                    1/1     Running   0          73s
pod/understood-zebu-wordpress-68fbc786c4-vz65r   1/1     Running   0          73s

NAME                                TYPE           CLUSTER-IP      EXTERNAL-IP                                                                    PORT(S)                      AGE
service/understood-zebu-mariadb     ClusterIP      10.100.83.99    <none>                                                                         3306/TCP                     73s
service/understood-zebu-wordpress   LoadBalancer   10.100.15.218   aa74b993bd5b347c693e6e0553e0b7f1-1811961745.ap-northeast-2.elb.amazonaws.com   80:31402/TCP,443:31785/TCP   73s

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/understood-zebu-wordpress   1/1     1            1           73s

NAME                                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/understood-zebu-wordpress-68fbc786c4   1         1         1       73s

NAME                                       READY   AGE
statefulset.apps/understood-zebu-mariadb   1/1     72s
(⎈ |jhs-eks-work-cluster:default) eks-velero 
(⎈ |jhs-eks-work-cluster:default) eks-velero  helm3 list -A
NAME           	NAMESPACE    	REVISION	UPDATED                             	STATUS  	CHART           	APP VERSION
understood-zebu	wordpress-cwi	1       	2022-03-24 19:47:30.365403 +0900 KST	deployed	wordpress-13.1.4	5.9.2
(⎈ |jhs-eks-work-cluster:default) eks-velero 

CLI 상에서도 모든 Resource 가 정상적으로 기동되었으며 실제 서비스도 문제 없음을 확인할 수 있습니다.

상기 테스트에서는 namespace 단위의 백업/복구를 테스트했으나 velero 에서는 다양한 옵션의 백업/복구 기능을 지원합니다. (labelselector, TTL, Scheduling, incremental backup 등)

Kasten K10

다음은 veeam 의 k8s 백업/복구 솔루션인 Kasten 입니다.

veeam 은 veritas, Dell, commvault 등과 함께 백업/복구 영역에서 손꼽히는 솔루션 기업 중 하나입니다.

k8s 백업 솔루션인 kasten k10은 다양한 고객 및 글로벌 레퍼런스를 가지고 있는만큼 검증된 솔루션으로 볼 수 있습니다.

사용하기 위해선 유료 라이선스가 필요하지만 10 Node 내 Non-product 클러스터를 대상으로 사용할 수 있는 free license 로 세팅해보겠습니다.

구조는 앞서 살펴본 velero 와 유사하지만 GUI 환경 및 편의 기능을 위한 component 가 추가되어 있습니다.

Install

velero 와 마찬가지로 본 Post 에서는 자세한 설치과정은 생략하고 AWS 에서의 개략적인 구성에 대해서만 다룹니다.

2차 백업을 위한 File 또는 Object 스토리지 세팅 및 Export/Import 는 제외합니다.

Prerequisites

Add the Kasten Helm charts repository
volumeSnapshot CRD 생성 ( volumesnapshotclasses, volumesnapshotcontents, volumesnapshots )
snapshot-controller 설치
snapshotclass 생성 (k10.kasten.io/is-snapshot-class: "true" 어노테이션 추가)
Snapshotter 생성 ( AWS CSI driver 호환 )

Install (helm)

helm install k10 kasten/k10 --namespace=kasten-io \
    --set secrets.awsAccessKeyId="${AWS_ACCESS_KEY_ID}" \
    --set secrets.awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"

Use

Dashboard 에서 Backup Policy 생성 후 실행

지정한 Namespace 상의 모든 Resource 백업 현황 확인

백업한 리소스 중 특정 리소스만 선택하여 별도의 namespace (wordpress-hellozcp) 상에서 복구 테스트

복구 완료 후 서비스 확인

(⎈ |jhs-eks-work-cluster:wordpress) work  k get deploy,svc -n wordpress-hellozcp
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/hellozcp   1/1     1            1           20m

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                                   PORT(S)          AGE
service/hellozcp-svc   LoadBalancer   10.100.166.46   a2685b3d652124051a0f64d5263966eb-195969067.ap-northeast-2.elb.amazonaws.com   8080:30152/TCP   20m

(⎈ |jhs-eks-work-cluster:wordpress) work  k exec -it network-test -n eks-work -- curl 10.100.166.46:8080
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>ZCP Sample Application</title>
</head>
<h1>Hello ZCP</h1>
<h2>Update test</h2>
<h2>Update test2</h2>
</body>
</html>%

Velero & K10 비교

두 솔루션은 모두 kubernetes 의 특징을 잘 살려 백업 및 복구가 기존 Legacy 에 비해 신속하고 간편하게 진행됩니다.

가장 큰 차이점이라고 한다면 라이선스 비용과 수행환경(CLI, GUI) 가 가장 큰 사항이라 생각됩니다.

몇몇 테스트 후 정리한 차이점은 다음과 같습니다.

	velero	K10
비용	무료	유료 (worker node 기준)
사용자 Interface	CLI	GUI, CLI
개발 결정권	커뮤니티	벤더
설치 Resource	velero deployment 1ea (restic 사용시 restic daemonset 추가)	16 개 deploy, 18 개 service , 6 개 persistent volume 등
저장공간	Object storage	File, Object storage
편의기능	백업,복구에 충실한 편	백업,복구 외 다양한 솔루션과의 인터페이스 제공 (eco-system)

두 솔루션 모두 백업 및 복구에 대해서는 훌륭한 성능을 보여주고 있다고 생각되며,

어떤 솔루션을 도입할지는 비용, 사용자, 주변 환경 등을 고려해 선택해야 합니다.

이번 포스트에서는 개략적인 내용만을 다뤘으니 혹시 사용 중 문의 사항이 있다면 연락 주시기 바랍니다.

Cloud Assessment Pack (Part 3) - AWS Migration HUB: 수집 데이터 확인

알 수 없는 사용자 — Mon, 9 May 2022 14:16:55 +0900

1. AWS Migration HUB 개념설명

AWS Application Discovery Service는 AWS Migration Hub 서비스에 통합 되어 있습니다. Migration HUB에는 ADS, Right Sizing, Migrate Tool 기능이 포함 되어 있습니다. 이번 섹션 에서는 ADS Console을 사용해서 Agent 관리, 서버 관리, 수집된 데이터를 확인 하는 방법에 대해 알아 보겠습니다.

2. AWS Migration Hub Console 기본

Migration Hub Console은 크게 Servers, Applications, Data Collectors, Tools로 나눠 집니다.

AWS Console 로그인 > AWS Migration Hub 서비스 > ADS Console 포함 되어 있음

Migration Hub 메인 화면

Servers: Connector또는 Agent를 통해 수집된 서버들의 정보
Applications: Migration의 그룹이 되는 Application 으로 사용자가 수작업으로 생성 필요
Data Collectors: Data 수집 도구 (Connectors, Agent) 관리
Tools: Discovery 할 수 있는 Tools 설명 (Import, Discovery Agent, Discovery Connector-Agentless

3. ADS 데이터 수집 도구 (Connectors, Agents)

Agent 또는 Connectors를 통해 등록 된 서버를 관리 합니다. 해당 화면에서 수집 되고 있는 서버들의 기본 정보 (IP, Hostname, 수집 상태, Agent Health……등을 확인 가능 합니다.)

Agents

Agent로 설치된 리스트를 보여줍니다. 설치된 서버 확인 후, 데이터 수집을 시작 합니다.

AWS Migration Hub 서비스 > Discover > Data Collectors > Agents > 설치된 Agent 리스트가 나옴 > Agent 선택 후, ‘Start Data Collection’ 버튼을 누르면 데이터 수집 시작함

Health(상태) 정보
. Healthy: 데이터 수집이 활성화되어 있지 않습니다. Agent는 정상 작동
. Unhealthy: Agent가 오류 상태입니다. 데이터 수집 및 보고가 되지 않습니다.
. Unknown: 한 시간 이상 연결이 수립되지 않았습니다.
. Shutdown: Agent가 시스템 서비스나 데몬 종료 때문에 통신 되지 않습니다.
. Running: 데이터 수집이 활성화되어 있습니다.

Connectors

Connectors로 설치된 리스트를 보여줍니다. 설치된 서버 확인 후, 데이터 수집을 시작 합니다.

AWS Migration Hub 서비스 > Discover > Data Collectors > Connectors > 설치된 Agent 리스트가 나옴 > Agent 선택 후, ‘Start Data Collection’ 버튼을 누르면 데이터 수집 시작함

4. 수집 데이터 확인

Agent 또는 Connector를 통해 수집 된 서버의 데이터를 확인 합니다.
Servers(서버) 페이지는 데이터 수집 도구에 알려진 각 서버 인스턴스에 대한 시스템 구성 및 성능 데이터를 제공합니다. 서버 정보를 보고, 필터로 서버를 정렬하고, 키 값 쌍으로 서버에 태그를 지정하고, 서버 및 시스템에 대한 세부 정보를 내보낼 수 있습니다.

Console 통해 수집된 데이터 확인

AWS Migration Hub 서비스 > Discover > Servers > Server 클릭 > 수집된 Inventory 정보 및 성능 데이터가 나옴

수집 된 데이터 Excel로 Export 하기
AWS Migration Hub 서비스 > Discover > Servers > Server 클릭 > 수집된 Inventory 정보 화면 > 우측 상단의 ‘Actions’ > Export Server Detail > 하단에 Exports 진행 현황이 나옴 > Download를 클릭해 CSV 형태의 데이터를 다운 > csv파일 모음 zip 파일이 다운됨

Export된 데이터

5. Applications Group 생성 및 서버 바인딩

Applications Group을 생성 후 Agent 또는 Connector를 통해 수집 된 서버를 바인딩 시킵니다.

Application 생성

AWS Migration Hub 서비스 > Discover > Applications > Create New Application

Application – 수집된 서버 바인딩

AWS Migration Hub 서비스 > Discover > Applications > Application 선택 후 ‘Action’ > ‘Add Servers to application 선택 > APP 에 서버 바인딩

Cloud Assessment Pack (Part 2) - AWS ADS: Agentless, Import방식 자원 수집

알 수 없는 사용자 — Mon, 7 Mar 2022 10:17:27 +0900

1. AWS ADS: Agentless 방식 자원 수집

Agentless 방식의 검색은 AWS Discovery Connector를 사용합니다. AWS Discovery Connector는 VMware 가상 머신(VM)에 대한 정보만 수집할 수 있는 VMware 애플리케이션입니다. OVA(Open Virtualization Archive) 파일을 사용하여 Discovery Connector를 VMware vCenter Server 환경의 VM(가상 머신)으로 설치합니다.
Discovery Connector는 운영 체제와 상관없이 VMware 메타데이터를 사용해 서버 정보를 수집하기 때문에 최초 온프레미스 인프라 평가에 필요한 시간을 최소화합니다.
Discovery Connector에 대한 배포 및 구성을 완료한 후 Application Discovery Service 엔드포인
트를 사용해 등록하고 구성 정보에 대한 서비스를 정기적으로(약 60분 간격) ping합니다.

작동 방식

커넥터의 데이터 수집 프로세스를 시작하면, 이 어플라이언스는 VMware vCenter Server에 연결하고 특정 vCenter에서 관리하는 모든 VM 및 호스트에 대한 정보를 수집합니다. 수집된 데이터는 Secure Sockets Layer(SSL) 암호화를 사용하여 Application Discovery Service에 전송됩니다. 커넥터는 새 버전의 커넥터를 사용할 수 있을 때 자동으로 업그레이드하도록 구성되어 있습니다. 이 구성 설정은 언제든지 변경할 수 있습니다.

수집 Data

Agentless 방식을 통해 수집되는 서버의 데이터

데이터 필드 | 설명
applicationConfigurationId* VM이 그룹으로 속한 마이그레이션 애플리케이션의 ID
avgCpuUsagePct 폴링 기간의 평균 CPU 사용량(%)
avgDiskBytesReadPerSecond 폴링 기간에 디스크에서 읽은 평균 바이트 수
avgDiskBytesWrittenPerSecond 폴링 기간에 디스크에 쓴 평균 바이트 수
avgDiskReadOpsPerSecond* 초당 평균 읽기 I/O 연산 수 null
avgDiskWriteOpsPerSecond** 초당 평균 쓰기 I/O 연산 수
avgFreeRAM 평균적으로 사용 가능한 RAM(MB)
avgNetworkBytesReadPerSecond 초당 평균 읽기 처리량(바이트)
avgNetworkBytesWrittenPerSecond 초당 평균 쓰기 처리량(바이트)
configId Application Discovery Service가 검색된 VM에 할당한 ID
configType 검색된 리소스의 유형
connectorId 검색 커넥터 가상 어플라이언스의 ID
cpuType VM의 경우 vCPU, 호스트의 경우 실제 모델
datacenterId vCenter ID
hostId VM 호스트 ID
hostName 가상 소프트웨어를 실행하는 호스트의 이름
하이퍼바이저 하이퍼바이저 유형
id 서버 ID
lastModifiedTimeStamp* 데이터를 내보내기 전 마지막으로 데이터를 수집한 날짜와 시간
macAddress VM 제조업체의 MAC
주소 가상 소프트웨어 제조사
maxCpuUsagePct 폴링 기간 동안 CPU 최대 사용량(%)
maxDiskBytesReadPerSecond 폴링 기간에 디스크에서 읽은 최대 바이트 수
maxDiskBytesWrittenPerSecond 폴링 기간에 디스크에 쓴 최대 바이트 수
maxDiskReadOpsPerSecond* 초당 최대 읽기 I/O 연산 수
maxDiskWriteOpsPerSecond** 초당 최대 쓰기 I/O 연산 수
maxNetworkBytesReadPerSecond 초당 최대 읽기 처리량(바이트)
maxNetworkBytesWrittenPerSecond 초당 최대 쓰기 처리량(바이트)
memoryReservation VM에 메모리가 초과 커밋되지 않도록 제한
moRefId 고유한 vCenter 관리 객체 참조 ID
name* 네트워크나 VM의 이름(사용자 지정)
numCores CPU의 독립 처리 유닛 수
numCpus VM의 중앙 처리 유닛 수
numDisks* VM의 디스크 수
numNetworkCards** VM의 네트워크 카드 수
osName VM의 운영 체제 이름
osVersion VM의 운영 체제 버전
portGroupId VLAN의 구성 포트 그룹 ID
portGroupName* VLAN의 구성 포트 그룹 이름

사전 준비 작업

Agentless를 이용한 Discovery Connector 설치 작업 전에, 지원 하는 Hypervisor 및 사전 필요 작업 내용을 확인 합니다.

지원 Hypervisor정보 확인
Discovery Connector는 VMware vCenter 버전 V5.5, V6, V6.5를 지원합니다

Discovery Connector 설치

Discovery Connector 다운로드

vCenter에 VMware 관리자로 로그인한 후 Discovery Connector OVA 파일을 다운로드할 디렉터리로 바꿉니다.
Discovery Connector OVA를 다운로드합니다.
시스템 환경의 해싱 알고리즘에 따라 MD5나 SHA256를 다운로드해서 체크섬 값이 포함된 파일을 얻습니다. 이 값을 사용하여 이전 단계에서 다운로드한 AWSDiscoveryConnector.ova 파일을 확인합니다.

Discovery Connector 배포

다운로드한 Discovery Connector의 OVA 파일을 VMware 환경에 배포합니다. Discovery Connector를 배포하려면 아래 작업을 수행 합니다.

vCenter에 VMware 관리자로 로그인합니다.
파일, OVF 템플릿 배포를 선택한 후 앞 단원에서 다운로드한 ova 파일을 선택하고 마법사를 완료합니다.
[Disk Format] 페이지에서 씩 프로비전 디스크 유형 중 하나를 선택합니다. 성능과 안정성이 가장 뛰어나기 때문에 [Thick Provision Eager Zeroed]를 선택하는 것이 좋습니다. 그러나 디스크를 0으로 초기화하려면 몇 시간이 필요합니다. [Thin Provision]은 선택하지 마십시오. 이 옵션은 더 빠른 배포가 가능하지만 디스크 성능이 크게 저하됩니다. 자세한 내용은 VMware 설명서에서 지원되는 가상 디스크의 유형을 참조하십시오.
vSphere 클라이언트 인벤토리 트리에서 새로 배포된 템플릿의 컨텍스트(오른쪽 클릭) 메뉴를 찾아서 열고 [Power], [Power On]을 차례대로 선택합니다.
템플릿의 컨텍스트(오른쪽 클릭) 메뉴를 다시 열고 [Open Console]을 선택합니다. 콘솔에 커넥터 콘솔의 IP 주소가 표시됩니다. IP 주소를 기록합니다. 연결 설정 프로세스를 완료하는 데 필요합니다.

ADS 포탈 등록 확인

Agent가 서버에 정상적으로 설치가 되었다면, 자동으로 AWS의 Migraiton Hub – ADS 포탈에 Agent가 등록이 됩니다. Portal에서의 Agent 등록 확인 방법은 아래와 같습니다.

AWS Migration Hub 서비스  Discover  Data Collectors  Agents  설치된 Agent 리스트가 나옴

2. AWS ADS: Import 방식 자원 수집

Migration Hub 의 Import를 사용하면 모든 소스에서 데이터를 가져올 수 있습니다. 제공된 데이터는 CSV 파일에 대해 지원되는 형식이어야 하며, 데이터에는 해당 필드에 대해 지원되는 범위가 있는 지원되는 필드만 포함되어야 합니다.

작동방식

사용자가 AWS에서 제공하는 엑셀 양식에 서버 정보를 입력하여, Migration Hub에 업로드 하면, 서버 정보가 자동으로 Import 됩니다.
Migration Hub 사용 법은 다음 post에서 상세히 가이드 합니다.

수집 Data

다음 표에서 별표가 표시된 가져오기 필드는 필수 필드입니다. 가져오기 파일의 각 레코드는 서버 또는 애플리케이션을 고유하게 식별하기 위해 값을 채운 이러한 필수 필드를 한 개 이상 가져야 합니다. 그렇지 않을 경우 필수 필드가 없는 레코드를 가져올 때 실패합니다.

가져오기 필드 이름 |설명
ExternalId* 각 레코드를 고유하게 표시할 수 있는 사용자 정의 식별자입니다.
Ex) ExternalId는 데이터 센터에 있는 서버의 인벤토리 ID
SMBiosId BIOS(SMBIOS) ID
IPAddress* 따옴표로 묶은 서버 IP 주소의 쉼표 구분 목록.
MACAddress* 따옴표로 묶은 서버 MAC 주소의 쉼표 구분 목록.
HostName* 서버의 호스트 이름입니다. 이 값에 정규화된 도메인 이름(FQDN)을
사용할 것을 권장합니다.
VMware.MoRefId* 관리되는 객체 참조 ID. VMware.VCenterId를 제공해야 합니다.
VMware.VCenterId* 가상 머신 고유 식별자.VMware.MoRefId를 제공해야 합니다.
CPU.NumberOfProcessors CPU 수입니다.
CPU.NumberOfCores 물리적 코어 총수
CPU.NumberOfLogicalCores 서버의 모든 CPU에서 동시에 실행할 수 있는 총 스레드 수입니다.
일부 CPU는 단일 CPU 코어에서 동시에 실행할 수 있는 여러 스레드를 지원합니다. 이 경우 이 숫자는 물리적(또는 가상) 코어의 수보다 더 많습니다.
OS.Name 운영 체제 이름.
OS.Version 운영 체제 버전.
VMware.VMName 가상 머신의 이름.
RAM.TotalSizeInMB 서버에서 사용 가능한 총 RAM(MB)
RAM.UsedSizeInMB.Avg 서버에서 사용된 평균 RAM 양 (MB)
RAM.UsedSizeInMB.Max 서버에서 사용 가능한 최대 RAM양(MB)
CPU.UsagePct.Avg 검색 도구가 데이터를 수집할 때 의 평균 CPU 사용률.
CPU.UsagePct.Max 검색 도구가 데이터를 수집할 때의 최대 CPU 사용률.
DiskReadsPerSecondInKB.Avg 초당 평균 디스크 읽기 수(KB).
DiskWritesPerSecondInKB.Avg 초당 평균 디스크 쓰기 수(KB).
DiskReadsPerSecondInKB.Max 초당 최대 디스크 읽기 수(KB).
DiskWritesPerSecondInKB.Max 초당 최대 디스크 쓰기 수(KB).
DiskReadsOpsPerSecond.Avg 초당 평균 디스크 I/O 연산 수.
DiskWritesOpsPerSecond.Avg 초당 평균 디스크 쓰기 연산 수
DiskReadsOpsPerSecond.Max 초당 최대 디스크 읽기 작업 수.
DiskWritesOpsPerSecond.Max 초당 최대 디스크 쓰기 작업 수.
NetworkReadsPerSecondInKB.Avg 초당 평균 네트워크 읽기 작업 수(KB)
NetworkWritesPerSecondInKB.Avg 초당 평균 네트워크 쓰기 작업 수(KB)
NetworkReadsPerSecondInKB.Max 초당 최대 네트워크 읽기 작업 수(KB)
NetworkWritesPerSecondInKB.Max 초당 최대 네트워크 쓰기 작업 수(KB)

지금까지 AWS AWS ADS(Application Discovery Service)의 Agentless, Import 수집방식에 대해서 알아봤습니다.

다음 Post에서는 수집된 자원을 확인하고 관리할 수 잇는, Migration HUB에 대해서 업데이트 하겠습니다.

Docker Desktop 유료화 및 대응방안

뭉기 — Fri, 4 Feb 2022 18:00:02 +0900

Docker Desktop 이란?

Windows와 OSX(Mac)에서 별도의 복잡한 환경 설정없이 간편하게 설치만으로 Docker 및 Kubernetes를 사용할 수 있게 해주는 GUI 관리 툴 입니다.
Docker 자체를 구동해주는 docker-engine이나 관리 명령어를 제공하는 docker cli 가 같이 설치 되기는 하지만, 해당 라이선스 정책과는 별개 입니다.

출처: https://www.docker.com/products/docker-desktop

Docker Desktop 유료화

유료 플랜 적용 기준

무료사용이가능했던 Docker Desktop이 아래 기준을 벗어나면 이제 유료 플랜을 구독해야합니다.
- 개인 사용자
- 회사에서 사용하는 경우
  - 250인 이하의 회사
  - 매출 $1000만 달러 미만의 회사
- 2022년 2월 1일부터 적용

구독 모델

사용자별 월간 또는 연간 플랜으로 구독할수 있습니다.
- 구독 모델별 세부 기능 및 비용은 https://www.docker.com/pricing 에서 확인 가능합니다.
- docker hub 유료 포함되므로, 좀더 docker hub를 편하게 쓰실 수 있습니다.

Docker Desktop 대체 방안

상기 유료 플랜 구독 비용에 부담이 없으면, 그대로 구독해서 쓰는게 가장 편한 방법입니다.
Docker나 Kubernetes를 쓰기 위해서 Docker Desktop이 꼭 필요한지 생각보면 그건 아닙니다.
사실 Container Runtime과 CLI를 설치해주고 관리를 좀 더 편하게 해주는 툴일 뿐이고, 다른 방법들도 있기 때문입니다.
물론 Docker Desktop이 가장 잘 만들어지고 대중화된 툴이기 때문에, 다른 툴을 쓸때 조금 더 불편하긴 합니다.
Docker Engine 이나, Docker CLI는 유료화 대상이 아니기 때문에 Docker Desktop을 삭제하고 Docker Engine 과 Docker CLI를 설치하면 됩니다. 그리고 PC에 Kubernetes가 필요하다면 Minikube, K3s, MicroK8s 등을 설치해서 사용할 수 있습니다.
Docker Engine은 Linux위에서 구동 되므로 Linux를 일단 띄워야 하므로 Hypervisor가 필요하게 됩니다.
로 Windows는 WSL2 를 이용하고, Mac은 VirtualBox 또는 QEMU를 이용하고 Lima나 minikube를 이용해서 Linux를 띄웁니다.
이러한 과정을 한번에 해준것이 Docker Desktop 이였고, SUSE에 인수된 Rancher에서도 대응되는 무료 툴을 발표했습니다.

아래 참조링크의 여러가지 툴을 테스트 해 본 결과 Rancher Desktop을 사용하는 방법이 제일 간단하고 활용성도 높았습니다.
https://rancherdesktop.io/

Rancher Desktop 소개

라이센스는 Apache2.0이고, Electron 기반으로 만들어져 있습니다.
OSX에서는 가상화로 Lima/QEMU 를 사용하고, Windows 10에서는 WSL2를 사용합니다.
경량화된 Kubernetes인 k3s를 설치합니다. PC에서 테스트/개발용으로 쓰기에는 가벼워서 더 좋은 것 같습니다.
업데이트도 지원하며, 간단한 GUI도 역시 제공하며, Kuberenetes를 쉽게 끄고 켤수 있고, K8s Context 변경도 GUI로 지원 합니다.
Container Runtime으로 dockerd와 containerd 둘 다 선택가능합니다. 이를 위한 CLI로 docker와 nerdctl를 지원합니다.
실제 구성 아키텍처는 아래와 같으며, 결국 아래에 별도 설명할 매뉴얼 구성방식과 유사합니다.

Rancher Desktop 아키텍처

Rancehr Desktop 설정 화면 : Runtime 선택과 스펙 변경을 쉽게 할수 있다.

Rancher Desktop 설치 방법 및 주의점

기존 Docker Desktop을 삭제 해야 합니다.
https://rancherdesktop.io/ 에서 환경별(Windows, Mac(Intel,ARM), Linux) 설치 파일을 받아서 실행, 설치하면 끝입니다.
설치시 Container Engine(Runtime)을 선택해야 하는데, containerd를 쓰면 neredctl로 container를 다루어야 합니다.
기존 처럼 docker cli를 쓸려면 dockerd(movy)를 선택해야 합니다.
- kubernetes 아키텍처상 바람직한 지향점은 containerd가 맞지만, 현재는 docker-desktop 대체용의 호환성을 목표로 하므로 dockerd를 선택하도록 합니다. 설정 메뉴를 통해 언제든지 변경 가능합니다.

Mac의 경우 기본 커맨드의 링크를 걸기 위해 권한을 요청하는 아래 팝업이 뜨고, 허용해주기 위해 시스템 비밀번호를 입력해 주어야 합니다.

Supporting Uiilities에서 (삭제된) 기본 docker 커맨드를 기본 패스에 링크 걸수 있습니다.

설치가 완료가 되면 K3s가 떠있으며, 아래 처럼 관련 container 및 Kubernetes Object들을 확인할 수 있습니다.
특이한 점은 ingress로 Traefik을 사용합니다.

docker 커맨드로 노드의 container를 확인 할수 있다.

kubectl 커맨드로 node의 상세 내용 확인

kubectl 커맨드로 k3s의 기본 object 확인

매뉴얼 구성 가이드

매뉴얼로 VM위에 Ubuntu를 설치 한 후 Docker Engine을 설치하고 Host와 연결을 설정하는 방법입니다.

Rancher Desktop를 쓰지 않고, 직접 Docker 환경을 구성 하고 싶을 때 사용 할 수 있습니다.

Windows

기존 Docker Desktop 삭제 : 시작 → 설정 → 앱 → Docker Desktop
WSL2 설치
- 시작 버튼 우클릭 → Windows PowerShell(관리자) 실행 → 실행 된 커맨드 창에 wsl --install 입력 후 엔터 → 리부팅(다시 시작)후 로그인 하면 나머지 설치됨 → ID/PW 설정
- 또는 https://aka.ms/wslstore 접속 → MS Store 열기 → Ubuntu 선택 → 설치
- WSL2의 상세 설치 가이드는 아래 링크를 참고 합니다.
  - https://docs.microsoft.com/ko-kr/windows/wsl/install
Docker 설치
- Ubuntu를 설치 했기 때문에 사실 상 Ubuntu에 Docker를 설치하는 것과 거의 동일합니다.
  - Ubuntu에 Docker Engine 설치 : https://docs.docker.com/engine/install/ubuntu/
  - 스크립트 설치: Ubuntu를 열고 아래 커맨드 실행

# 스크립트에 설치 시작전 대기시간 20초가 있어 기다린다. Docker Desktop 권유는 무시.
curl -fsSL https://get.docker.com | sudo bash

# Windows용 docker client와 tcp로 통신하기 위한 설정
cat <<'EOF' | sudo tee /etc/docker/daemon.json
{
  "features": { 
    "buildkit": true 
  }, 
  "hosts": ["tcp://127.0.0.1:2375", 
  "unix:///var/run/docker.sock"]
}
EOF

# 자동 실행 설정
## Win 10 인 경우 : 셸시작시 자동 실행 설정 (WSL에서는 서비스 자동 실행 기능이 없음)
cat <<'EOF'>>~/.profile
wsl.exe -u root -e sh -c "service docker status || service docker start"
EOF

## Win 11 인 경우 : 부팅시 자동 실행 설정
cat <<'EOF' | sudo tee -a /etc/wsl.conf
[boot]
command="service docker start"
EOF


sudo service docker start
sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker

# Test
docker run --rm -i  hello-world
docker run --rm -it alpine ping -c5 google.com

Windows에서 Docker 환경 설정
- Ubuntu 셸안에서 계속 써도 되겠지만 Windows 에서 CLI를 실행 후 WSL2로 실행된 Docker-Engine에 연결할려면 다음과 같이 수행 합니다.
- 아래 경로에서 CLI 파일을 받고 압축을 푼후 docker.exe 를 PATH가 잡혀있는 곳으로 복사한다.
  - https://download.docker.com/win/static/stable/x86_64/docker-20.10.9.zip
- 이후 파워셸에서 아래 커맨드를 실행해서 docker context를 변경 합니다.

docker.exe context create wsl
docker.exe context update wsl --description "WSL" --docker "host=tcp://127.0.0.1:2375"
docker.exe context use wsl

# Test
docker run --rm -i  hello-world

참고 링크

Cloud Assessment Pack (Part 1) - 소개 및 AWS ADS

알 수 없는 사용자 — Fri, 28 Jan 2022 10:05:33 +0900

목적

Cloud로의 마이그레이션을 생각하고 있는 고객을 위한, AS-IS 인프라 분석, 비용, 마이그레이션 우선순위, CSP 선정 등 빠른 분석이 필요합니다. 이런 작업을 수작업으로 할 경우에 많은 시간과 Resource가 들기 때문에, CSP의 서비스 및 Tool을 최대한 활용하여 자동화 하고 표준화 하는 작업이 필요합니다.

이 문서에서는 Cloud Assessment(평가)를 위한, CSP 서비스의 기술 검증 및 방법론의 표준화 작업 Cloud Quick Assessment Pack를 통해 To-Be Cloud로의 Insight 확보를 쉽게 할 수 있는 방법에 대해 설명 합니다.

아래 Tool에 대해서 사용 방법 및 활용 가이드를 제공하도록 하겠습니다. 아래 Tool들은 AWS 중심으로 되어있지만, Assessment 단계에서는 다른 CSP에 동일하게 적용하여 사용 가능 합니다.

Cloud Assessment Pack 시리즈를 통해서 서버의 Data를 수집하는 방법, 수집 된 Data의 정보 및 활용하는 방법에 대해서 설명 하도록 하겠습니다.

Cloud Assessment Pack 시리즈

1 ADS Introduction

1.1 ADS 개념

AWS에서는 자동 Discovery Tool인 ADS(Application Discovery Service)를 사용하여, On-Premise 서버의 정보를 수집하는 서비스를 제공 하고 있습니다.
ADS서비스에서는 ADS는 Agent 기반 및Agentless 기반(VMware만 지원)의 Data 수집 방법을 제공 합니다. Data는 서버 사양 정보, 성능 데이터 및 실행 중인 프로세스 세부 정보 수집 네트워크 연결 정보 등 입니다.
수집된 데이터를 이용하여 AWS클라우드로의 마이그레이션을 계획할 수 있습니다. ADS는 AWS Migration Hub에 통합되기 때문에 단일 콘솔에 마이그레이션 상태 정보를 집계하여 마이그레이션 프로세스를 간소화 할 수 있습니다. Migration Hub 콘솔에서 검색한 서버를 확인하고 이를 애플리케이션으로 그룹화한 다음, 각 Application의 마이그레이션 상태를 확인 할 수 있습니다.
ADS를 통해 수집된 데이터는 Excel, Right Sizing, MPA(Migration Portfolio Assessment, TCO), Amazon Athena(쿼리 분석), Amazon Quick Sight (시각화)을 통해서 추가 분석 할 수 있습니다.

ADS 데이터 수집 과정

[출처] https://www.slideshare.net/AmazonWebServices/save-money-and-migrate-faster-with-rapid-discovery-and-analysis-ent331-aws-reinvent-2018?from_action=save

1.2 Discovery Tool 비교

AWS에서 SaaS 형식으로 제공하는 ADS 와 Third Party로 제공하는 TSO Logic 및 Risc Networks를 비교 설명 합니다. TSO Logic은 AWS에 의해서 인수 되었으며, AWS Portal에 SaaS 로 포함될 예정에 있습니다.

* AWS의 ADS는 VMware에 대해서만 Agentless 방식의 커넥터 제공
** Agent 방식만 제공
*** 수집 데이터 저장을 위한 S3비용 일부 발생, 툴 사용을 무료

1.3 자원 수집 방법

ADS 자원 수집 방법은 아래와 같이 다양하게 지원하며, 이 글에서는 아래 방식에 대한 방법을 모두 소개 합니다.

Agent 방식
Agentless 방식
서버 Import 방식

2 ADS Agent 방식 자원 수집

AWS Discovery Agent는 검색 및 마이그레이션을 위해 대상으로 지정된 On-premise 서버 및 VM에 설치하는AWS 소프트웨어입니다. 에이전트는 시스템 구성, 시스템 성능, 실행 중인 프로세스 및 시스템 간 네트워크 연결에 대한 세부 정보 등을 캡처합니다. 에이전트는 대부분의 Linux와 Windows 운영 체제를 지원하며, 물리적 온프레미스 서버, Amazon EC2 인스턴스, 가상 머신에 배포할 수 있습니다.

2.1 작동 방식

등록 후에는 구성 정보를 얻기 위해 15분 간격으로 서비스를 ping합니다. 에이전트에 데이터 수집을 시작하 라는 명령을 보내면, 에이전트는 위치한 호스트나 VM(가상 머신)에 대한 데이터를 수집하기 시작합니다.
수집된 데이터에는 시스템 사양, 성능 데이터, 네트워크 연결, 프로세스 데이터가 포함됩니다. 이 정보를 사용하여 IT 자산과 네트워크 종속성을 매핑할 수 있습니다. AWS에서 서버를 실행할 때의 비용을 결정하고 마이그레이션에 대한 계획을 수립하는 데 도움이 되는 데이터 포인트입니다.
Discovery Agent는 TLS(전송 계층 보안) 암호화를 사용해 Application Discovery Service로 안전하게 데이터를 전송합니다.

2.2 수집 Data

Agent를 통해 수집되는 서버의 데이터

2.3 사전 준비 작업

Agent 설치 작업 전에, 지원 하는 OS리스트 및 사전 필요 작업 내용을 확인 합니다. 아래 사전 준비 작업을 진행 후 Agent 설치 작업을 진행해야 오류가 나는 것을 방지 할 수 있습니다.

지원 OS 정보 확인

Linux
Amazon Linux 2012.03, 2015.03
Amazon Linux 2(2018년 9월 25일 업데이트 이후)
Ubuntu 12.04, 14.04, 16.04
Red Hat Enterprise Linux 5.11, 6.9, 7.3
CentOS 5.11, 6.9, 7.3
SUSE 11 SP4, 12 SP2
Windows
Windows Server 2003 R2 SP2
Windows Server 2008 R1 SP2, 2008 R2 SP1
Windows Server 2012 R1, 2012 R2
Windows Server 2016
Windows Server 2019

방화벽 오픈
Agent가 설치될 서버에서 수집 서버로 데이터를 암호화 해서 보내기 위해, 443 Port Outbound Open 작업을 해줘야 합니다. 서버의 OS 방화벽 및 데이터 센터내의 방화벽 장비에서 작업을 해줘야 합니다. Inbound는 별도 작업을 해줄 필요가 없습니다.

AWS Access Key ID 및 Secret Access Key 정보 확인
AWS 계정의 Access Key ID와 Secret Access Key 정보를 AWS에서 포탈에서 확인을 합니다. 해당 정보는 Agent를 서버에 설치할 때 사용 됩니다.

-    AWS Portal(https://console.aws.amazon.com/) 로그인 > Service 검색: IAM > 사용자명 검색 > ‘액세스 키 만들기’ 선택 > 생성된 Access Key ID 및 Secret Access Key 정보를 별도로 저장 (CSV 파일로 다운 로드도 가능)

2.4 Linux Agent 설치

테스트 서버 OS 정보 : Centos 7.7
Agent 설치 파일 다운로드

Agent가 설치될 서버에 접속해서, 아래 명령어를 실행 합니다.

# sudo curl -o ./aws-discovery-agent.tar.gz https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz
# sudo tar -xzf aws-discovery-agent.tar.gz

Agent 설치

# sudo bash install -r Your_Home_Region -k <aws key id> -s <aws key secret> # sudo bash install -r us-west-2 -k AKIxxxxxx -s QFtcE8xxxxxxx`

설치 확인 및 Agent 관리

ADS 포탈 등록 확인

AWS Migration Hub 서비스 > Discover > Data Collectors > Agents > 설치된 Agent 리스트가 나옴

Agent 문제 확인
Agent 관련 문제가 생길 경우, 로그 파일 또는 Config 파일을 확인해서 트러블 슈팅을 진행 합니다. 아래의 위치에서 ADS Agent의 로그 및 Config 파일을 확인 할 수 있습니다.

로그파일 위치

/var/log/aws/discovery/

Config 파일 위치

/var/opt/aws/discovery/

2.5 Windows Agent 설치

Agent 설치

테스트 서버 OS 정보: Windows 2012
사전 설치 필요 파일: Microsoft Visual C++ Redistributable for VS2015 x86

Microsoft Download Center (https://www.microsoft.com/en-us/download/details.aspx?id=48145) 로 이동해 다운로드를 선택하면 다운로드 섹션 페이지로 이동합니다. 이 페이지에서 설치할 머신의 아키텍처와 상관 없이 vc_redist.x86.exe ("x64" 버전을 선택하지 않음)만 선택합니다. 그런 다음 다음을 선택합니다. 그러면 즉시 다운로드가 시작됩니다.

Agent 설치 파일 다운로드
Agent가 설치될 서버에 접속해서, Agent 설치 파일을 다운로드 받습니다. 다운로드 받은 파일을 더블클릭해서 설치하면, 설치 오류가 나며, 다음단계에서 설치 명령어를 실행해야 정상적으로 설치가 됩니다.

Agent 파일 위치: https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/windows/latest/AWSDiscoveryAgentInstaller.msi

Agent 설치

> msiexec.exe /i AWSDiscoveryAgentInstaller.msi REGION="us-west-2" KEY_ID="<AWS key ID>" KEY_SECRET="<AWS key secret>" /q

> msiexec.exe /i AWSDiscoveryAgentInstaller.msi REGION="us-west-2" KEY_ID="AKxxxxxxxx" KEY_SECRET="QFtcE8qUxxxxxxxxxxxxxxxx" /q

설치확인
Windows Server Manager Services 콘솔을 통해 AWS Discovery Agent 실행(Running) 확인

ADS 포탈 등록 확인

Agent가 서버에 정상적으로 설치가 되었다면, 자동으로 AWS의 Migraiton Hub – ADS 포탈에 Agent가 등록이 됩니다. Portal에서의 Agent 등록 확인 방법은 아래와 같습니다

AWS Migration Hub 서비스  Discover  Data Collectors  Agents  설치된 Agent 리스트가 나옴

Agent 문제 확인

Agent 관련 문제가 생길 경우, 로그 파일 또는 Config 파일을 확인해서 트러블 슈팅을 진행 합니다. 아래의 위치에서 ADS Agent의 로그 및 Config 파일을 확인 할 수 있습니다.

로그파일 위치

C:\\ProgramData\\AWS\\AWS Discovery\\Logs

Config 파일 위치

C:\\ProgramData\\AWS\\AWS Discovery\\config

지금까지 AWS 마이그레이션 Quick Assessment Pack 및 AWS ADS(Application Discovery Service)의 Agent 수집방식에 대해서 알아봤습니다.

다음 Post에서는 ADS 자원 수집 방법중에 하나인 Agentless 방식과 Import 자원 수집 방식에 대해서 업데이트 하겠습니다.

감사합니다. :)

* 참고자료
- https://aws.amazon.com/ko/application-discovery/
- https://docs.aws.amazon.com/application-discovery
- https://docs.aws.amazon.com/migrationhub/
- https://mpa-proserve.amazonaws.com/
- https://docs.aws.amazon.com/ko_kr/quicksight/latest/user/amazon-quicksight-user.pdf

- https://www.slideshare.net/AmazonWebServices/save-money-and-migrate-faster-with-rapid-discovery-and-analysis-ent331-aws-reinvent-2018?from_action=save

[Save Money and Migrate Faster with Rapid Discovery and Analysis (ENT3…

In this session, learn how to use AWS Application Discovery Service and AWS Migration Hub to quickly discover your existing infrastructure, calculate the cost …

www.slideshare.net](https://www.slideshare.net/AmazonWebServices/save-money-and-migrate-faster-with-rapid-discovery-and-analysis-ent331-aws-reinvent-2018?from_action=save)

EKS Anywhere (3/3) - EKS Connector를 통한 Cluster 통합 조회

GH_1024 — Tue, 18 Jan 2022 15:51:30 +0900

지난 포스트에서는 AWS EKS Anywhere Local Cluster를 배포하는 방법에 대하여 소개하였습니다. 이번 포스트에서는 배포된 Local Cluster 뿐 아니라 GKE, Kubeadm으로 배포된 Cluster를 EKS Connector를 이용하여 AWS Console에서 통합 조회하는 방법에 대하여 설명합니다. (테스트는 플랫폼 Architect 그룹에서 제공하는 Private Cloud인 DigitalX에서 수행하였습니다.)

EKS Connector를 통한 AWS Console 연결 과정

EKS Connector를 통해 Kubernetes Cluster를 등록할 때는 크게 다음의 과정을 거칩니다.

Console에서 Amazon EKS → 클러스터 → 클러스터 추가 → 등록 선택
클러스터 이름과 공급자정보 선택
연결 구성에서 AmazonEKSconnectorAgentRole 선택
클러스터 등록
생성 된 Yaml 파일을 사용해 등록하려는 Kubernetes Cluster에서 리소스 생성

※ 연결 구성에서 AmazonEKSconnectorAgentRole이 없을 경우 아래의 AmazonEKSconnectorAgentRole 생성을 먼저 수행합니다.

AmazonEKSconnectorAgentRole 생성

Role 생성을 위한 파일(eks-connector-agent-trust-policy.json, eks-connector-agent-policy.json) 생성 후 AWS CLI를 통해 IAM과 정책을 생성합니다.

eks-connector-agent-trust-policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SSMAccess",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "ssm.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

eks-connector-agent-policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SsmControlChannel",
            "Effect": "Allow",
            "Action": [
                "ssmmessages:CreateControlChannel"
            ],
            "Resource": "arn:aws:eks:*:*:cluster/*"
        },
        {
            "Sid": "ssmDataplaneOperations",
            "Effect": "Allow",
            "Action": [
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenDataChannel",
                "ssmmessages:OpenControlChannel"
            ],
            "Resource": "*"
        }
    ]
}

역할 생성(AWS CLI)

aws iam create-role \
     --role-name AmazonEKSConnectorAgentRole \
     --assume-role-policy-document file://eks-connector-agent-trust-policy.json

정책 생성(AWS CLI)

aws iam put-role-policy \
     --role-name AmazonEKSConnectorAgentRole \
     --policy-name AmazonEKSConnectorAgentPolicy \
     --policy-document file://eks-connector-agent-policy.json

권한 수정(AWS Console)

IAM → 역할 → AmazonEKSConnectorAgentRole 선택
권한 → 정책 연결 → AmazonEKSClusterPolicy 정책 연결
신뢰관계 → 신뢰관계 편집 후 하단 정책 포함

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Local Cluster에 Yaml 배포

Console의 클러스터 등록 후 생성된 Yaml 파일 배포

kubectl apply -f ${Cluster_Name}.yaml

Cluster Role binding Yaml 템플릿 다운로드

curl -o eks-connector-clusterrole.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/eks-connector/manifests/eks-connector-console-roles/eks-connector-clusterrole.yaml

해당 파일의 %IAM_ARN% 부분을 실제 사용자의 ARN으로 변경

해당 파일 수정 후 YAML 파일 배포

kubectl apply -f eks-connector-clusterrole.yaml

IAM 사용자와 Cluster 연결 Yaml 템플릿 다운로드

curl -o eks-connector-console-dashboard-full-access-group.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/eks-connector/manifests/eks-connector-console-roles/eks-connector-console-dashboard-full-access-group.yaml

# 상기 템플릿은 전체 네임스페이스에 대한 권한을 주는 것으로, 
# 특정 네임스페이스에 대한 권한만 줄 경우 아래의 템플릿을 활용

# curl -o eks-connector-console-dashboard-restricted-access-group.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/eks-connector/manifests/eks-connector-console-roles/eks-connector-console-dashboard-restricted-access-group.yaml

해당 파일의 %IAM_ARN% 부분을 실제 사용자의 ARN으로 변경

해당 파일 수정 후 YAML 파일 배포

kubectl apply -f eks-connector-console-dashboard-full-access-group.yaml

EKS Connector 연결 결과

EKS Anywhere로 배포한 Cluster

AWS Console에 등록된 Cluster의 Node 정보

Cluster의 Node 정보

미리 배포된 GKE Cluster

AWS Console에 등록된 GKE Cluster의 Node 정보

GCP Console에서 확인한 GKE Cluster의 Node 정보

Kubeadm으로 배포한 Cluster

AWS Console에 등록된 Kubeadm으로 생성한 Cluster의 Node 정보

Kubeadm Master에서 확인한 Cluster의 Node 정보

위와 같이 다양한 Kubernetes 환경을 EKS Connector를 통해 AWS Console에서 통합 조회가 가능하였습니다. 아직은 통합 조회에 그치는 수준이지만 향후 좀 더 다양한 기능을 AWS Console을 통해 수행할 수 있다면 통합관리 측면에서 EKS Connector를 사용하는 점이 확실히 매력적이지 않을까 생각해봅니다.

EKS Anywhere (2/3) - EKS Anywhere Local Cluster 설치

GH_1024 — Mon, 17 Jan 2022 17:46:06 +0900

지난 포스트에서는 AWS EKS Anywhere에 대해 간략하게 소개하였습니다. 이번 포스트에서는 개발 및 테스트의 목적으로 단일 VM위에 EKS Anywhere Local Cluster를 배포하는 방법에 대하여 설명합니다. (테스트는 플랫폼 Architect 그룹에서 제공하는 Private Cloud인 DigitalX에서 수행하였습니다.)

사전 VM 준비

Local Cluster 배포를 위한 VM 사양

도커 20.xx
우분투(20.04.2 LTS)
4 CPU 코어
16GB 메모리
30GB의 디스크 여유 공간

해당 사양에 맞게 VM을 생성하고 이후 Docker, eksctl, EKS Anywhere, kubectl 순으로 설치를 진행하였습니다.

EKS Anywhere 설치 과정

Docker 설치

sudo apt-get update

sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io
#오류 발생시 아래 처럼 특정 버전을 지정
#sudo apt-get install docker-ce=5:20.10.11~3-0~ubuntu-focal docker-ce-cli=5:20.10.11~3-0~ubuntu-focal containerd.io

EKSCTL 설치

#eksctl Download
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

#move to /usr/local/bin
sudo mv /tmp/eksctl /usr/local/bin

#check eksctl version
eksctl version

#eks-anywhere plugin install
export EKSA_RELEASE="0.6.0" OS="$(uname -s | tr A-Z a-z)" RELEASE_NUMBER=2
curl "https://anywhere-assets.eks.amazonaws.com/releases/eks-a/${RELEASE_NUMBER}/artifacts/eks-a/v${EKSA_RELEASE}/${OS}/eksctl-anywhere-v${EKSA_RELEASE}-${OS}-amd64.tar.gz" \
    --silent --location \
    | tar xz ./eksctl-anywhere
sudo mv ./eksctl-anywhere /usr/local/bin/

#check eksctl anywhere version
eksctl anywhere version

EKS Anywhere 설치

#생성될 Cluster Name 지정
CLUSTER_NAME=digitalx-cluster

#Cluster 배포 yaml 생성
eksctl anywhere generate clusterconfig $CLUSTER_NAME \
   --provider docker > $CLUSTER_NAME.yaml

#Cluster 생성
eksctl anywhere create cluster -f $CLUSTER_NAME.yaml

Kubectl 설치 및 Cluster 정보 등록

#kubectl 설치
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list

apt-get update -y
apt-get install kubeadm kubectl -y

#kubeconfig 설정
export KUBECONFIG=${PWD}/${CLUSTER_NAME}/${CLUSTER_NAME}-eks-a-cluster.kubeconfig

설치 확인

kubectl get ns

EKS Anywhere로 설치한 Cluster의 Namespace 상태

배포 테스트

# 테스트 Pod 배포
kubectl apply -f "https://anywhere.eks.amazonaws.com/manifests/hello-eks-a.yaml"

# 테스트를 위한 Port-forwarding
kubectl port-forward deploy/hello-eks-a 8000:80

배포된 테스트 Pod

배포된 테스트 Pod Curl 테스트

EKS Anywhere Local Cluster 배포는 CLI 몇 줄로 편리하게 배포가 가능했습니다. 아쉽게도 현재 테스트 목적으로는 단일 VM에 Local Cluster를 배포하는 것이 한계이지만 AWS는 22년에 EKS Anywhere가 베어메탈에 설치 가능하도록 지원할 계획이 있기 때문에 향후에는 다수의 Worknode를 기반으로 테스트 및 운영 환경 구축이 가능해질 것으로 생각됩니다.

다음 포스트에서는 EKS Connector를 사용하여 이번 포스트에서 배포된 Local Cluster와 GKE, Kubeadm으로 배포된 Cluster를 AWS Console에서 통합 조회하는 방법에 대하여 알아보겠습니다.

EKS Anywhere (1/3) - EKS Anywhere 소개

GH_1024 — Mon, 17 Jan 2022 17:09:17 +0900

작년 말, AWS에서는 고객의 데이터 센터에 직접 Amazon Elastic Kubernetes Service(Amazon EKS)를 배포할 수 있는 배포 옵션인 Amazon Elastic Kubernetes Anywhere를 발표했습니다. 이에 EKS Anywhere Local Cluster를 구성하고 다른 배포 옵션을 통해 배포된 Kubernetes를 EKS Connector를 통해 AWS Console에 등록하는 방법에 대해 테스트해 보았습니다.

EKS Anywhere 란?

Amazon EKS Anywhere는 2021년 출시된 Amazon EKS의 새로운 배포 옵션입니다. 기존의 EKS가 AWS의 자원을 활용하여 서비스 되었다면, EKS Anywhere는 고객이 관리형 인프라에서 Kubernetes 클러스터를 생성 및 운영하도록 지원합니다. 글을 쓰고 있는 2022년 1월 기준으로 EKS Anywhere는 운영 용도로는 VMware vSphere를 사용한 온프레미스 환경만을 지원하고 있지만 2022년 중에 베어메탈 지원을 포함될 것이라고 합니다.

운영 용도가 아닌 테스트, 개발 용도로는 단일 VM에 Local Cluster를 구성할 수 있습니다.

Amazon EKS Anywhere는 Amzon EKS를 구동하는 동일한 Kubernetes 배포인 Amazon EKS Distro를 기반으로 클러스터를 생성합니다. 또한 3rd party 소프트웨어 통합을 포함해 모든 Amazon EKS Anywhere 구성 요소를 AWS가 지원하기 때문에 고객은 지원 비용을 줄이고 중복된 오픈 소스 및 3rd party 도구의 유지 관리 부담을 줄일 수 있습니다. 또한 eksctl 등을 통해 Amazon EKS와 Amazon EKS Anywhere 양 쪽 모두 일관된 운영 도구를 제공하며 EKS Connector를 통해 EKS 콘솔에서 Amazon EKS와 고객의 인프라 자원에서 실행되는 Amazon EKS Anywhere를 함께 확인할 수 있습니다.

이미지 출처 : AWS(https://aws.amazon.com/ko/eks/eks-anywhere/)

EKS Distro는 Amazon EKS에서 배포한 것과 동일한 Kubernetes 배포판 버전으로서, 사용자는 이를 사용하여 원하는 어디서든 자신의 Kubernetes 클러스터를 수동으로 생성할 수 있습니다. EKS Distro는 Amazon EKS에서 사용하는 오픈 소스 Kubernetes의 설치 가능한 빌드 및 코드를 제공합니다. 여기에는 종속성 및 AWS에서 관리하는 패치 등이 포함됩니다.

AWS에서 제공하는 Kuberntes 배포 옵션

AWS에서 제공하는 Kuberentes 배포 옵션은 AWS에서 관리하는 자원에 Kubernetes Cluster를 배포하는 Amazon EKS, EKS on Outpost와 고객의 인프라에 배포하는 EKS Anywhere, EKS Distro가 있습니다. 또한 각 배포 옵션들은 제어 영역의 위치, 지원 여부 등 다양한 옵션을 제공하므로 구성하려는 시스템의 요건에 맞추어 적합한 배포 옵션을 선택하여 Kubernetes Cluster를 구성 할 수 있습니다.

기능	Amazon EKS	EKS on Outpost	EKS Anywhere	EKS Distro
하드웨어	AWS 관리		고객 관리
배포 유형	Amazon EC2, AWS Fargate	EC2 on Outposts	고객 인프라
제어 영역 관리	AWS 관리		고객 관리
제어 영역 위치	AWS 클라우드	고객 측 온프레미스 또는 데이터 센터
클러스터 업데이트	제어 영역 및 데이터 영역의 관리형 현재 위치 업데이트 프로세스		CLI(데이터 영역의 경우 Flux 지원 롤링 업데이트, 제어 영역의 경우 수동 업데이트)
네트워킹 및 보안	Amazon VPC 컨테이너 네트워크 인터페이스(CNI), 여타 호환되는 서드 파티 CNI 플러그인		Cilium CNI	서드 파티 CNI 플러그인
콘솔 지원	Amazon EKS 콘솔		EKS 콘솔, EKS Connector 사용	셀프서비스
지원	AWS Support		EKS Anywhere 지원 구독	셀프서비스

표 출처 : AWS 블로그 (https://aws.amazon.com/ko/blogs/korea/amazon-eks-anywhere-now-generally-available-to-create-and-manage-kubernetes-clusters-on-premises/)

EKS Anywhere의 장점

EKS Anywhere는 Kuberentes Cluster를 구성함에 있어서의 편의성과 안전성, 그리고 향후 운영 시의 지원 등의 부분에서 다른 Kuberntes 배포 옵션에 비해 장점을 가집니다.

Kuberntes Cluser 관리의 편의성 제공
EKS Anywhere는 CLI를 통해 클러스터 관리 자동화 도구를 제공하며 Kubernetes Cluster의 생성과 관리/운영을 간소화하여 제공합니다.
오픈소스 사용에 따른 불안전성 제거
EKS Anywhere는 EKS Distro 기반으로 구축되고, 지속적인 업데이트를 포함하는 오픈 소스 소프트웨어를 제공합니다. 따라서 자체 관리형 Kubernetes Cluster 배포 옵션에 비해 신뢰할 수 있는 Kubernetes Cluster를 구축할 수 있습니다.
Kuberntes 운영 지원
EKS Anywhere 지원 구독을 통해 EKS Anywhere 사용 중 발생하는 이슈들을 기술 지원받을 수 있습니다.
Kuberntes Cluster 통합 조회
EKS Anywhere를 통해 배포된 Kuberentes Cluster 뿐 아니라 AKS, GKE와 같은 타사 Kubernetes Cluster와 Kubeadm, Kubespray 등을 통해 배포된 자체 관리형 Kubernetes Cluster까지 EKS Connector를 사용하여 AWS Console에서 통합 조회할 수 있습니다.

이러한 장점들을 기반으로 EKS Anywhere는 Private Cloud 위에 Kuberentes Cluster를 구축하는 경우나, 데이터의 문제로 인하여 Public 환경의 사용이 어려운 경우 매력적인 배포 옵션으로 선택될 수 있습니다.

다음 포스트에서는 EKS Anywhere의 Local Cluster 구성에 대하여 알아보겠습니다.