Cloud Computing On Demand

매일 매일 하지 않으면 다 까먹는게 k8s인 것 같습니다. 
여느 오픈소스들과 마찬가지로 마이너버전 업데이트가 이루어지더라도
여러가지 변경되는 점들이 워낙 많기 때문일 것 같습니다.

그 중에서도! 
ServiceAccount를 생성했을 때 같이 생성되던 Token이 만들어지지 않는 것은
분명 꼼꼼히 이것저것 살피지 않았다면 빠지기 쉬운 함정인 것 같습니다 ㅠㅠ

네, 1.24 버전 이후의 k8s를 사용한 클러스터로 작업중이라면 
ServiceAccount와 함께 수동으로 Token을 위한 Secret을 생성해야 합니다. 
예를 들어 보겠습니다. 

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: default
  name: drone-bot

1.24 버전까지는 위와 같이 ServiceAccount를 생성하면 
`drone-bot-token-j13b7`와 같은 스타일의 토큰이 자동으로 생성되었습니다. 

1.24 이후 버전부터는 보안 강화를 위해 토큰을 자동으로 생성하지 않습니다. 
따라서 아래와 같이 별도로 Secret 오브젝트를 생성해 줘야 합니다. 

apiVersion: v1
kind: Secret
metadata:
  name: drone-bot-secret
  namespace: default
  annotations:
    kubernetes.io/service-account.name: drone-bot
type: kubernetes.io/service-account-token

이렇게 하고나면 ServiceAccount에 대한 Token을 획득할 수 있습니다. 

% k get secret drone-bot-secret -n default
NAME               TYPE                                  DATA   AGE
drone-bot-secret   kubernetes.io/service-account-token   3      15s

% k get secret drone-bot-secret -n default -o yaml
apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTi...
  namespace: ...
  token: ZX...
...

왜 자동으로 Token이 생성되지 않는지 한참 헤메였는데...
알게 모르게 k8s 버전이 1.25로 바뀌었는데 그걸 모르고 클러스터 만들고 삽질을 했었네요...
여러분은 삽질하지 마시라고 공유해 드립니다!

드문드문 k8s를 사용하다보니 매번 반복적으로 쉬운 것들을 잊곤 합니다.
오랜만에 또 새로운 클러스터를 새로운 환경에 만드느라 삽질하는 요즈음,
잊었던 것들을 또 하나씩 적어 볼까 합니다.

ServiceAccount 생성

이번에는 CI/CD 연동 등을 통해 k8s 클러스터에 대한 작업을 같이 수행하고 있습니다. 
빌드 배포시마다 k8s 환경이 잘 구축되어 있는지를 점검하려는 욕심에 그만...
그래서 ServiceAccount 의 생성이 필요해졌습니다.

요약하면... 걍 만들면 됩니다.
그래도 우리는 선언적으로 만드는게 좋겠죠.
네, drone을 쓰려는 중입니다 ㅎㅎ

apiVersion: v1
kind: ServiceAccount
metadata:
  name: drone-bot

Role 선언

이번엔 ServiceAccount에 연결할 Role을 정의해 봅시다.
Role을 정의하려다 보니 apiGroups와 해당되는 resources
그리고 사용 가능한 verbs가 뭐가 있는지 또 헤메기 시작합니다. 

% kubectl api-resources -o wide

kubectl로 위 명령을 입력하면 필요한 모든 것들이 쫘아악~
필요한 권한과 대상 리소스에 대한 내용을 확인하면 됩니다. 
늘 느끼는 거지만 APIVERSION은 왜 이리 아스트랄한지...

몇 가지 골라서 일단 때려 넣습니다.
보안 헛점은 일단 고려치 않습니다 ㅎㅎ
필요한 동사들은 조금 더 발라내 봐야겠네요. 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: drone-bot
rules:
  - apiGroups: [""]
    resources: ["configmaps", "secrets", "services", "namespaces"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list","watch", "create", "update", "patch", "delete"]

복수형에 주의하시고, 
엉뚱한 apiGroups에 넣지 않도록 주의합시다!

ServiceAccount와 Role을 연결하는 RoleBinding

이렇게 두개의 k8s 객체를 만들었으니 이제 연결해야겠죠?
RBAC으로 권한 부여를 할 것이기 때문에 RoleBinding을 하면 됩니다. 
이름이 다 drone-bot이라 헷갈릴 수 있지만...

metadata.name 은 RoleBinding의 이름이고
subjects.kind[].name은 생성한 ServieAccount의 이름이며
roleRef.name은 생성한 Role의 이름입니다. 

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: drone-bot
subjects:
  - kind: ServiceAccount
    name: drone-bot
roleRef:
  kind: Role
  name: drone-bot
  apiGroup: rbac.authorization.k8s.io

그럼... 이제 생성해보러...

AWS에서 컴퓨팅 인프라를 운영하려면 머리가 아픕니다. 
늘 쓰던 것을 쓰면 큰 문제도 고민도(가령 묻지도 따지지도 않고 EC2) 없지만
새로운 제품을 써보려고 하면 일단 제품을 이해하는 것부터 허들입니다 ㅎㅎ
물론 한번 쓰기 시작하면 주머니가 탈탈 털릴 정도로 잘 쓰게 되긴 합니다. 

근래에 k8s 쪽을 다룰일이 계속 생기다 보니 AWS의 제품들에도 관심을 갖게 되었고
AWS가 제공하는 컨테이너 오퍼링을 한번 정리해보고 갈 필요가 생겼습니다. 
도대체 제품 설명만으로는 "뭥미?" 하는 경우가 종종 있으니...

그 중, 유명한 4가지 제품들을 한번 정리해 보겠습니다. 
순서대로 ECS, EKS, Fargate 그리고 ECR 입니다.

ECS, EKS vs. EC2, Fargate

ECS, EKS 를 하나로 묶고 EC2, Fargate를 하나로 묶을 수 있습니다. 
ECS는 Elastic Container Service로 Container 기반의 컴퓨팅 플랫폼이라 보면 되고 
EKS는 Elastic Kubernetes Service로 Container 기반이지만 k8s가 환경이라 보면 됩니다. 

이 두가지가 컨테이너에 대한 오케스트레이션을 담당한다고 보면
EC2, Fargate는 ECS, EKS가 동작하는 호스팅에 대한 레이어를 담당하는 제품들입니다. 
즉, EC2와 Fargate 위에 ECS, EKS가 동작한다고 이해하면 됩니다.

한줄 요약 : EC2, Fargate는 컨테이너를 위한 컴퓨팅 리소스이다 

ECS vs. EKS

그렇다면 ECS와 EKS는 어떤 차이가 있을까요?
둘다 컨테이너 오케스트레이션 환경이라는 공통점을 갖고 있지만 
ECS는 AWS 에서만 제공되는 오케스트레이션 환경이라 타플랫폼으로의 이식성이 떨어지지만
EKS는 쿠버네티스 환경이라 플랫폼간 이전이 더 용이합니다. 

한줄 요약 : ECS는 AWS Only, EKS는 범용 k8s

EC2 vs. Fargate

EC2는 워낙 유명하니 다들 잘 아실겁니다. 
쉽게 생각해서 가상머신(VM)이라고 봐도 무방합니다. 
즉, 독립된 환경이 있고 운영체제를 갖고 있는 컴퓨팅 리소스입니다. 

반면 Fargate는 가상머신보다 더 추상화된 컴퓨팅 환경입니다. 
서버 없이 코드를 실행하는 람다 Lambda 를 서버리스 Serverless 라고 부르는 것처럼
Fargate는 EC2의 서버리스 버전이라고 생각할 수 있겠습니다. 
서버가 없는 컴퓨팅 환경이 Fargate 입니다

한줄 요약 : 독립된 운영체제가 있으면 EC2, 서버리스 컴퓨팅 환경은 Fargate

참고 : https://aws.amazon.com/ko/blogs/korea/how-to-choose-aws-container-services/

Considerations

ECS와 EKS를 봤을때 느낌적 느낌으로 EKS가 비용이 더 나올것이라고 예상됩니다.
네, 정확히 그렇고 ECS가 비용적으로는 EKS 보다 저렴합니다. 
하지만 ECS는 k8s가 아니기 때문에 이야기 한 것처럼 이식성이 떨어집니다. 

어떤 플랫폼을 쓰던 비용을 계속 체크하면서 써야 하는 것이 퍼블릭 클라우드입니다. 
ECS, EKS, 그리고 EC2, Fargate...!
여러분의 선택은 무엇입니까? :-)

Amazon Linux 를 쓰는 EC2 인스턴스에서 yum 으로 docker-compose 의 설치가 원활하지 않아 github 에서 릴리즈된 버전을 설치해 보기로 했습니다. 구글링을 통해 잘 정리된 명령어를 찾을 수 있었고 다시 한 번 구글님께 감사의 절을 올리고 설치를 진행해 보았습니다.

Github 저장소에서 최신 릴리즈 태그 찾기

먼저 할일은 Github 의 Docker 프로젝트를 들르는 일입니다. 하위에 만들어져 있는 저장소들 중 compose 저장소가 docker-compose 를 만드는 공장입니다. 해당 저장소에 들어간 뒤 우측 사이드바에서 최신 릴리즈 정보를 확인할 수 있습니다. 

릴리즈 파일 전송받기

<Releases> 텍스트를 누르면 빌드되어 릴리즈 된 파일들의 목록을 볼 수 있습니다. 플랫폼과 운영체제에 따라 서로 다른 빌드를 사용하게 되는데요, Linux 버전을 받으면 되겠습니다. 구글링으로 찾은 curl 명령 예제는 uname -s 와 uname -m 으로 플랫폼 정보를 가져와서 쓰도록 되어 있어 유용했습니다! 

// 최신 릴리즈 버전에 맞게 "1.27.4" 부분을 바꿔줍니다
// Root 권한이 아니라면 sudo 를 사용해야겠죠?
// 보통 기본 Path 로 잡혀 있는 /usr/local/bin 에 파일을 저장했습니다
//
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   651  100   651    0     0  27125      0 --:--:-- --:--:-- --:--:-- 27125
100 11.6M  100 11.6M    0     0  3053k      0  0:00:03  0:00:03 --:--:-- 3630k

// 받은 파일의 퍼미션을 변경하여 실행 가능하게 바꿉니다
//
$ sudo chmod +x /usr/local/bin/docker-compose

// 설치된 docker-compose 의 버전을 확인합니다. 
//
$ docker-compose --version
docker-compose version 1.27.4, build 40524192