해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 자료로 활용할 예정입니다.
이직을 하고 블로그에 손을 놓고 있다가 페이스북 Kubernetes Korea Group에 올라온 쿠버네티스 네트워킹 스터디 모집 공고를 보게되었다. 이직후에 대부분의 프로젝트가 쿠버네티스 기반으로 진행되다 보니 네트워크 전문가 이신 가시다님의 팀 블로그나 이나 여러 양질의 게시글들을 참고만 하다가 조금더 깊이 학습을 하고 싶어 스터디를 신청했고, 간단한 면접(??)후에 정식으로 스터디에 참여하게 되었다.
본론으로 돌아가서 calico 스터디를 진행하다가 wireguard라는 opensource vpn을 알게 되었고 해당 패키지를 이것저것 테스트하다가 기존에 사용중인 tailscale 과 유사하다는 것을 인지하고 내부 구성을 조금 찾아보기로 했다.
확인해보니 tailscale은 wireguard 기반으로 하는 동일 기술의 상용 솔루션이였고, 이에 몇가지 공부차 정리를 위해 해당 포스트를 작성하게 되었다.
지난글에 이어 이번에는 네트워크 구성하는 방법과 vSphere Cluster에 추가적인 Kubernetes 클러스터를 배포하는 것에 대해 이야기 하고자 한다. 이번 글도 지난글과 동일하게 virtuallyGhetto 블로그 포스팅을 참고하여 그대로 진행한 내용이라고 보면 된다.
스타트업으로 이직후 정신없는 6개월을 보냈고 집에서 하는 사이드 프로젝트나 공부하는 것들이 소홀해지는것 같아 마음을 다잡고자 작성하는 포스팅이다. 최근 몇개월 간은 회사 블로그 글만 작성하다보니 개인 블로그를 거의 못하고 있어서 회사 제품과는 아직까지 거리가 있는 플랫폼 공부차 작성한다. 순수하게 정보공유차 작성하는 것이며, 특정회사의 회사의 제품이나 플랫폼을 홍보하고자 함은 아니다.
이번에는 Knative를 EKS에 구성해보려고 한다. 4월은 발표 및 여러가지 업무로 인해서 포스팅을 할 시간이 부족했지만 5월부터 조금씩 여유가 생겨서 더 바빠지기전에 좀 써보려고 한다. 사실 Facebook @최용호님께서 한번 해보는것도 좋겠다고 하셔서 테스트를 진행하였다.
제목만 보면 Lambda나 ECS, Batch 서비스가 있는데 왜 이걸 써야하지? 라는 생각부터 하는 사람도 있을것 같다. 하지만 이전 포스팅들과 발표에서도 여러번 이야기 한것처럼 Knative는 간단하게 서버리스 워크로드를 빌드, 배포, 관리하기 위한 Kubernetes기반 FaaS플랫폼이고 현재 CNCF Landscape에서 가장 빠른 속도로 개발되고 있는 오픈소스 프로젝트 중 하나이다.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-24-168.ap-northeast-2.compute.internal Ready <none> 2m v1.11.9 ip-192-168-78-204.ap-northeast-2.compute.internal Ready <none> 2m v1.11.9
Istio injection을 하기 위해 배포할 defaults namespace 전체에 Labeling을 한다.
$ kubectl label namespace default istio-injection=enabled namespace/default labeled $ kubectl get namespaces --show-labels NAME STATUS AGE LABELS default Active 43m istio-injection=enabled istio-system Active 27m istio-injection=disabled kube-public Active 43m <none> kube-system Active 43m <none>
미리 Dockerhub에서 hello-python repository(docker.io/ddiiwoong/hello-python)를 생성한다.
그리고 위에서 생성한 build-bot 계정과 image tag hello-python정보를 Build template에 작성하여 배포한다.
아래 Knative Build 과정은 kaniko executor를 사용하여 다음과 같은 과정을 수행한다.
spec.source 에서 Source Clone (git)를 수행하고 이후
spec.steps 에서 Docker Build, Tag, Registry Login, Push를 수행한다.
kubectl get svc istio-ingressgateway --namespace istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.100.208.80 a220723d475df11e980220a02e220b34-2021915778.ap-northeast-2.elb.amazonaws.com 80:31581/TCP,443:31490/TCP,31400:30367/TCP,15011:32495/TCP,8060:31418/TCP,853:30310/TCP,15030:32405/TCP,15031:31410/TCP 13h
위와 같이 AWS LoadBalancer로 배포면 ALB가 자동으로 생성되므로 추후 eksctl로 클러스터를 삭제하기 전에 반드시 LoadBalancer 형태로 배포된 서비스를 삭제하고 진행해야 한다.
Knative Service를 확인한다.
$ kubectl get ksvc NAME DOMAIN LATESTCREATED LATESTREADY READY REASON helloworld-python helloworld-python.default.example.com helloworld-python-4rw95 helloworld-python-4rw95 True
위에서 얻은 두가지 정보(LoadBalancer, Domain)로 생성된 app을 테스트한다.
Knative는 내부적으로 example.com이라고 하는 기본 domain을 사용하므로 내부적으로는 helloworld-python.default.example.com으로 curl을 실행하게 된다.
$ curl -H "Host:helloworld-python.default.example.com" http://a220723d475df11e980220a02e220b34-2021915778.ap-northeast-2.elb.amazonaws.com Hello World: Python Sample v1 with Knative on EKS!
Cold Start(default timeout 5분) 때문에 잠시 응답이 늦어질 수도 있지만(2-5초) 잠시 기다리면 위처럼 결과를 확인할 수 있다.
위에서도 잠깐 언급했지만 Lambda나 ECS, Batch 서비스가 있는데 Knative on EKS 를 구지 왜 하느냐라고 궁금해하는 분들이 계실지도 모른다. 하지만 다들 아래와 같은 고민을 해봤을거라 생각한다.
컨테이너와 Kubernetes가 DevOps도구로서의 표준이 되어가는 시대에 Lambda를 쓸지 오픈소스를 쓸지에 대한 고민은 결국 이식성과 벤더 종속성을 제거하고 운영효율화 측면에서 그 답을 찾을수 있을것 같다.
현재 몸담고 있는 최근 프로젝트에서 Lambda, ECS, Batch 등을 사용하는 경우가 많아졌는데 실제 엔터프라이즈에서 정해진 자원내에서 정해진 일을 할때는 매니지드 서비스가 적합하다고 생각한다. 하지만 On-Premise 또는 그에 준하는 Kubernetes 클러스터를 운영하는 조직에서는 Knative를 사용하여 컨테이너 기반 서비리스 워크로드를 구현하는 것이 향후 Hybrid 관점에서 확장성과 벤더 종속성을 제거하는데 큰 도움이 될것이라 생각한다.
조금씩 Kubernetes 및 생태계 Learning에 대한 피로도가 증가하고 있고 Hype Driven Development(설레발 주도개발)가 되는것 같아서 아쉬운 부분은 있지만 현재 가장 핫한 기술이고 관심도가 높기 때문에 배워두면 언젠가는 써먹게 될거라 확신한다.
다시한번 Conference driven development(architecture)가 되지 않도록 자중하고 Loudest Guy가 되지 않도록 조심해야할 것 같다.