Tag: Kubernetes

K8s IaC 도구들 뭘 쓸까?

목적

  • 인프라 코드화 관리
  • 인프라 반복생성
  • 공개된 인프라 설정 사용
    helm chart, operator

사용 케이스

개인 서버 설치시

helm차트 traefik, coredns, haproxy, mariadb, postgresql, 등등 각각을 여러번 실행시키는게 귀찮아서

  1. helm차트 하나에 넣어보기도 하고
  2. helmsman, helmfile 등 helm여러개 실행시키는 툴을 써보기도 했는데

결국엔 python으로 helm차트를 받아서 실행시키는 방법을 쓰게 됐다.

요구사항이 복잡하면 어떻게 해도 공개된 라이브러리만으로 해결이 안된다.

  1. helm 차트는 특정 templates만 편집하는 기능이 없어서 차트를 로컬에 –untar로 받은 후 deployment.yaml만 덮어씌운다던가 하는 방법을 썼다.
  2. helm 설치 전 후로 secret이나 volume을 관리 해 줘야 하는 경우가 있는데 수동으로 하려면 복잡하고 늘 실수를 한다.

회사 서비스 DevOps 관리시

회사에서는 단순 설치가 아니라 직접 개발한 애플리케이션을 배포하는거라서 공개된 helm차트를 쓰지 않는다. 보통 두세단계로 분리해서 실행하게 된다.

  1. 미들웨어 설치 istio, traefik, gateway, kafka, redis 등 k8s 클러스터 또는 서버에 직접 설치할 것들
    helm, ansible, bash 스크립트 등 활용
    자주 안 하는거라 기록만 해 놓고 노가다로 처리하는 경우가 많다.
    회사에 따라… 기록을 안 해서 할 때 마다 잘못되는 경우가 더 많다.
  2. deployment, service 정도만 정의 해 놓고 dev,
    helm차트 한개로 만들거나 kustomization, 등등을 쓴다.

용도별

템플릿 관리

  • https://github.com/helm/helm 24.7k
  • https://github.com/kubernetes-sigs/kustomize 9.9k
  • https://github.com/grafana/tanka 2k
    https://tanka.dev
  • https://github.com/kapicorp/kapitan 1.7k
    https://kapitan.dev
  • https://github.com/GoogleContainerTools/kpt 1.5k
    https://kpt.dev
  • https://github.com/kubecfg/kubecfg 160
  • https://github.com/boltops-tools/kubes 81
    https://kubes.guru
  • https://jsonnet.org – erb, mustache, freemarker처럼 그냥 템플릿엔진에 가까워보임
  • kssonet – 멈춰

런타임 관리 Operator

operator는 패턴이다.
kube api와 통신하는 서버를 한개 올려놓는걸로 이해하는게 쉽다.
kube클러스터에 definition이 올라가면 이 설정에 따라 인프라를 실행시켜주는 것

요즘은 operator를 많이 쓴다는 것 같은데…(진실???)
여러개의 인프라를 동적으로 관리할게 아니라면 helm을 쓰는게 나을 것 같다.
대부분의 상황에서 operator를 왜 써야하는지 잘 모르겠다.
definition.yaml만 apply하면 되서 사용자 입장에서는 조금 더 쉽게 받아들여지는걸까
helm에서 values.yaml만 편집하는거랑 다를게 없는데
helm이 너무 주먹구구식으로 만들어져 있는데 비해 operator의 설정파일이 조금 더 이해하기 쉬워서 인기가 좋은 것 같다.
복잡하게 사용하려면 어렵거나 직접 만들어야 하는건 비슷하다.

공식 도큐먼트 Operator 소개
https://kubernetes.io/ko/docs/concepts/extend-kubernetes/operator/

Operator 도구 선택

도구의 순위보다는 각각 특성이 있어서 선택이 더 어렵다.
선택 기준을 먼저 적어보면

  • 단순 설치는 helm으로 할거니까 operator는 커스텀 기능 개발이 쉬울 것
  • 템플릿이 많아서 웬만한거 가져다가 쓸 수 있을 것

kudo 뭔가 그냥 helm차트 비스무리하게 kafka를 설치 해 버리는데… 오퍼레이터를 관리 해 주는 툴인가?
juju도 좀 그런 느낌이다. lxd컨테이너 기술로 미들웨어 쉽게 설치 해 주는… charm이라는 미리 정의된걸 설치

코딩이 되는 툴은

  • java operator sdk
  • py kops <- 제일 간단해 보임
  • go kubebuilder
  • rust ~
  • dotnet ~

~

  • helm차트와 스크립트 언어로 직접 설치코드 만들기
  • operator는 kops

Helm 2에서 3로 간략

Tiller 없어짐

  • Tiller가 k8s 클러스터에서 에이전트 서버 역할을 했는데 이게 없어지고 단순 클라이언트에서 접속하는 구조로 변경
  • 보안을 사용자가 알아서 하라는거 보니 이거 관련 보안문제가 터졌나봄
  • tiller 초기화하려고 필요했던 helm init, helm home 없어짐

차트 리포지터리 검색

로컬과 helm hub 모두 동작? 항상 웹으로 찾아가지고 몰랐던 부분

의존성관리

Chart.yaml에서 의존성 관리. requirements.yaml을 포함. 용어도 변경 requirements -> dependencies
helm2 하위호환 보장
차트의 type 추가 – application / library

주요 명령어 기능변화

uninstall 하면 기본값이 purge라던가… helm2까지 많이 사용하던 사람 아니면 관심가질 필요 없는 내용.. 어차피 쓰다보면 알게되는

Serverless Architcture 적용 – 기술조사

올해의 핫 키워드 서버리스 아키텍처

갑자기 떠올랐다고 해야되나.. 내가 갑자기 알게된건가

AWS서밋2018 가서 보고 이게 이렇게 핫한 기술이라는걸 알게 됐다.

컨테이너 기반 개발/배포에 어느정도 익숙해져 갈 즈음이라… 이게 왜 필요한지 잘 이해가 안 갔었달까
(뭐 그냥 로그수집 할 때나 쓰면 적당하겠군)

그런데 최근 파일업로드 서버를 만들다가 갑자기 생각이 들었다.

여기다가 쓰면 되는거구나…

한번 생각나고 나니까 여기저기 적용할만한 구석이 보이기 시작한다.

개발환경

테스트 없이 배포까지 한 번에 할 수 있는 사람이 있긴할까?

역시 테스트가 필수적이다. 실서버에 배포를 하면 시간도 오래 걸리고, 돈도 들고, 운영중인 서비스라면 서비스가 중단된다.

로컬에서 빠르게 코딩-테스트할 환경이 필요한데

AWS, GCP 모두 테스트 환경을 제공 해 주고 있다.

로컬에 설치해서 개발이 가능한 솔루션도 많이 있다. 집에다가 한개 설치 해 놓고 개발용으로 써도 될 것 같다.

서버리스 솔루션

https://github.com/kubeless/kubeless
https://fission.io/
https://www.openfaas.com/
https://openwhisk.apache.org/

FAAS

AWS는 다양한 언어를 제공 해 주고 있는 데 반해.
GCP는 아직 걸음마 단계… js만 사용가능하다.

kubernets 기반에 설치해서 사용이 가능한 fission도 있고
다른 서버리스 솔루션들을 kubernetes에 설치해서 써도 될 것 같지만….
그럴거면 그냥 컨테이너를 띄우지…

Serverless가 간편하다고 하지만.. SpringBoot나 다른기술들에 어느정도 익숙하다면 시간차이는 크지 않다.
AWS를 쓰면 구축 난이도가 좀 높은 API게이트웨이까지 사용할 수 있어서 더 좋을 것 같다.
AWS의존적인 시스템을 만들지 않으려고 했지만.. 이건 뭐 답이 없다. 그냥 의존적으로 가다가 문제가 생기면 빼는게 나을 것 같다.

로컬테스트는 이것저것 해보겠지만… 실 서비스는 AWS, API Gateway, DynamoDB/Aurora가 거의 확정.