devops

Application ## 먼저 엔드포인트 확인 $ curl endpoint ## 서비스 상태 확인 (Selector와 Endpoint 체크) $ kubectl describe service web-service ## 파드 확인 $ kubectl get pod $ kubectl describe pod web $ kubectl logs web -f --previous Control Plane ## Node & Pod 확인 $ kubectl get nodes $ kubectl get pods ## Controlplane Pod & Service 확인 $ kubectl get pods -n kube-system ## Controlplane Service 확인 $ service kube-apiserver sta..

멀티 컨테이너 파드는 아주 유용하다. 대체로 파드에 하나의 컨테이너만 생성하는 편이지만, 파드에 여러 컨테이너를 추가하면서 얻을 수 있는 장점이 많다. 컨테이너를 동일한 노드에서 관리해야하는 프로세스가 필요하거나, 파드의 컨테이너간 통신이 필요한 경우 멀티컨테이너의 역할이 요구된다. 여기서 멀티컨테이너는 3가지 패턴이 있는데 아래와 같다. 사이드카 패턴(Sidecar) 사이드가 패턴은 어플리케이션에 필수적이지만, 어플리케이션의 일부일 필요가 없는 컨테이너로 구성된다. 대체로 Logging이나 Sync를 맞추거나 혹은 monitoring이 필요한 경우에 많이 사용하는 패턴이다. 이 패턴은 로깅 코드에 결함이 생길 경우에 격리된 컨테이너기 때문에 어플리케이션에 영향을 주지 않는다는 장점이 있다. 어댑터 패턴..

도커를 실행할 때, ENTRYPOINT와 CMD를 활용해서 명령어의 인자값을 컨테이너 실행시에 전달하고 수정할 수 있다. 쿠버네티스에서도 Pod 정의에서 활용이가능하다. Kubernetes Command & args 왼쪽은 Dockerfile에서 선언된 ENTRYPOINT와 CMD다. 오른쪽 POD 정의에서 command는 ENTRYPOINT의 필수 실행 명령을, args를 통해서 인자값을 전달할 수 있게된다. Configmap 환경변수를 미리 선언하고 관리할 수 있는 Kubernetes Configmap을 이용하면 많은 인자값 관리가 편리해진다. 위처럼 ConfigMap을 Key:Vaule 식으로 먼저 정의를 한다. 적용할 Pod에서 spec.containers.envFrom.configMapRef.n..

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을 따로 분리하는 것과 같은 역할을 한다. 그래서 파드에 볼륨을..