Blockchain & Devops

Helm은 쿠버네티스의 service, deployment, configmap과 같은 다양한 오브젝트들을 결합해주는 쿠버네티스용 패키지라고 보면 된다. Helm은 애플리케이션 컨테이너 배포는 물론이고, 이에 필요한 쿠버네티스 리소스를 모두 배포해주는 역할이라고 보면된다. 왜 굳이 Helm을 사용해야할 까? Deployment 히스토리 기능 제공 Helm에서 배포된 어플리케이션은 Helm release로 관리가 된다. 릴리즈된 버전 기록을 자동으로 유지 관리하고 배포 후에 문제 발생시 롤백하는 것이 간편하다. CI/CD 파이프라인 가능 CI/CD 파이프라인을 이용해서 배포 작업을 구성하고 자동화할 수 있다. 멀티스테이징 배포 중에 어플리케이션 구성이 가능하다. 쉽게 말해서, 스테이킹 운영환경에 따라서 Po..

서비스와 인그레스는 같은 네트워크 관련 오브젝트로, 쿠버네티스의 각 컨테이너의 네트워크 포워딩과 설정에 관여한다고 볼 수 있다. 서비스(Service) 위 이미지에서 보는 것처럼, 서비스는 같은 역할과 서비스를 하는 여러 POD를 하나로 묶어서 관리하는 오브젝트라고 볼 수 있다. 파드가 새로 생성될 때마다 동적으로 IP를 할당할 수 있다. 간단히 말해서 서비스는 트래픽을 파드로 전달만하는 역할을 한다. 여기서 서비스는 여러 종류를 가진다. 1) ClusterIP 내부에서만 접근할 수 있는 IP를 할당한다. 그래서 외부에서 접속이 불가능하다. 그러나 kubeproxy를 활용하면 접근할 수 있다 2) NodePort 클러스터의 모든 노드로 외부에서 접근할 수 있는 포트를 개방한다. NodePort가 설정되면..

쿠버네티스의 오브젝트는 컨테이너 워크로드를 처리하는데 사용되는 1) 워크로드용 객체, 네트워크 및 보안을 처리하는 2) 인프라 객체와 구분할 수 있다. 오브젝트 생성을 위해서는 YAML을 활용하고, API 서버를 통해서 요청된다. 그리고 생성전에 유효성 검증이 진행된다. Workload 1) Pod 파드는 작업의 기본 단위면서, k8s에서 생성하고 관리할 수 있는 가장 작은 단위의 유닛이다. 파드는 하나 이상의 컨테이너들의 그룹이며, 모두 스토리지와 네트워크 리소스를 공유한다. 굳이 비유를 하자면 '하나 혹은 여러 컨테이너들을 감싼 얇은 wrapper'다. 2) Deployment 디플로이먼트는 파드와 레플리카셋의 선언적인 설정을 제공한다. Deploy하여 레플리카셋보다 한 단계 높은 관리 오브젝트를 생..

쿠버네티스의 아키텍처는 크게 Control Plane, Node로 나뉜다. 아래 이미지를 보면 클러스터의 아키텍처를 쉽게 파악할 수 있다. Control Plane '마스터노드(Master Node)' 라고 불린다. Control Plane은 클러스터의 Work Node와 Pod를 관리한다. 프로덕션 환경에서, Control Plane은 일반적으로 여러 PC에서 실행되며 하나의 클러스터가 여러 노드들을 관리하여 고가용성과 내결함성을 제공한다. Control Plane CLI와 UI를 통해서 API 서버를 통해 Input 요청받는다. 또한, 마스터 노드에서는 사용자 workload를 사용하지 않는것이 좋다. Node '작업자 노드(Worker Node)'라고 불린다. 컨테이너화된 어플리케이션을 실행하는데 ..

500 Internal Server Error 하이퍼텍스트 전송 프로토콜 (HTTP) 500 Internal Server Error 서버 에러 응답 코드는 요청을 처리하는 과정에서 서버가 예상하지 못한 상황에 놓였다는 것을 나타냅니다. 이 에러 응답은 "서버 에러를 총칭하는"(catch-all) 구체적이지 않은 응답입니다. 종종, 서버 관리자들은 미래에 같은 에러를 발생하는 것을 방지하기 위해 500 상태 코드 같은 에러 응답들에 더 많은 자세한 내용을 남겨 둡니다. 어플리케이션 상태검사 liveness probe : 컨테이너 내부의 어플리케이션이 살아있는 지 검사한다. 검사 실패 시 해당 컨테이너는 restartPolicy에 따라 재시작된다. (정상 상태를 유지하고 있는지, 트래픽 전송) readine..

인그레스 인그레스는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API Gateway다. HTTP를 관리하며 로드 밸런서, SSL Termination, 가상 호스팅을 제공한다. 인그레스 필요성 인그레스 리소스는 로드 밸런싱과 더불어 호스트 기반 라우팅을 지원한다. Cluster IP는 인그레스가 로드 밸런서의 역할을 수행한다. 단순한 어플리케이션도 서비스는 두 개 이상의 HTTP 요청을 가진다. 보통 Web Server와 WAS인데, 이러한 서비스의 접근을 별도의 포트로 구분해서 접속하게 할 수 있다. 그러나 하나의 호스트 상에서 라우팅으로 구분하면 보다 유연한 서비스를 만들 수 있다. * Web server는 ' / ' , WAS는 ' /api ' 로 라우팅할 수 있다. * YAML 파일에서 s..

Pod(파드) 파드는 일시적이며, 언제나 삭제될 수 있따. 그래서 Stateless하다는 특징이 있다. 이 파드의 교체와 배치를 담당하는 것은 deployment다. deployment는 replicaset을 통해서 파드를 scale out하고 이 때 만들어지는 파드들은 상호 대체가 가능하다. 파드가 사라져도 데이터를 남기고 싶을 수 있다. 대표적인 Stateful 어플리케이션으로 MySQL, MongoDB, Redis같은 DB가 있다. DB 어플리케이션이 담긴 파드가 사라질때, 데이터가 함께 사라져선 안된다. 그래서 쿠버네티스는 영속적인 데이터를 저장하기 위해 볼륨(Volume)을 연결할 수 있다. 이 볼륨은 클라우드 서비스에서 Volume을 따로 분리하는 것과 같은 역할을 한다. 그래서 파드에 볼륨을..

갑자기 파드, 디플로이먼트 등 생성과 삭제 모든 작업에 아래와 같은 오류가 뜰 수 있다. Unable to connect to the server: dial tcp 192.168.49.5:8443: connect: no route to host 이는 클러스터에서 문제가 발생했을 가능성이 높으니 클러스터를 다시 삭제하고 생성하면 된다. $ minikube stop $ minikube delete $ minikube start

서비스 쿠버네티스 환경에서 서비스(Service)는 파드들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출(expose)시키는 가상의 컴포넌트다. 쿠버네티스 내부의 다양한 객체들이 애플리케이션과, 그리고 애플리케이션이 다른 외부의 애플리케이션이나 사용자와 연결될 수 있도록 도와주는 역할을 한다. 클러스터 안에서 애플리케이션을 구동시키는 데에 쓰이는 파드들의 반영속적인(ephemeral) 특성 때문이다.쿠버네티스에서의 파드는 무언가가 구동 중인 상태를 유지하기 위해 동원되는 일회성 자원으로 언제든 다른 노드로 옮겨지거나 삭제될 수 있다. 또한 파드는 생성될 때마다 새로운 내부 IP를 받게 되므로, 이것만으로 클러스터 내/외부와 통신을 계속 유지하기는 어렵다. 따라서 쿠버네티스에서는 파드가 외부와 통신할..

블루/그린 배포 기존 버전을 교체할 최신 버전 디플로이먼트 세트를 생성하고 service의 spec.selector를 이용하여 이미 생성된 파드를 교체하는 작업을 하면된다. 이 후 최신 버전에서 문제 발생시 재교체하며 롤백한다. https://www.cncf.io/wp-content/uploads/2020/08/CNCF-Presentation-Template-K8s-Deployment.pdf https://semaphoreci.com/blog/continuous-blue-green-deployments-with-kubernetes Continuous Blue-Green Deployments With Kubernetes - Semaphore Learn how to create a CI/CD pipeline..