이 페이지에서는 쿠버네티스 개요를 설명한다. 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. 쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. 여정 돌아보기 시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자. 전통적인 배포 시..

오늘 다루어볼 내용은 kustomize이다. Kustomize는 kustomization 파일을 이용해 kubernetes 오브젝트를 사용자가 원하는 대로 변경(customize)하는 도구이다. 모든 예제는 아래 깃헙 kube-kustomize 디렉토리에 있다. yoonyeoseong/kubernetes-sample Kubernetes(쿠버네티스) sample. Contribute to yoonyeoseong/kubernetes-sample development by creating an account on GitHub. github.com kustomization 파일을 포함하는 디렉터리 내의 리소스를 보거나 실제 클러스터에 리소스를 적용하려면 다음 명령어를 이용한다. #kustomize가 적용된 설정..

이번 포스팅에서는 쿠버네티스 로깅 파이프라인 구성에 대해 다루어볼 것이다. 저번 포스팅에서는 Fluentd + ES + Kibana 조합으로 클러스터 로깅 시스템을 구성했었는데, 이번 시간에는 Fluentd + kafka + ELK 조합으로 구성해본다. Kubernetes - Kubernetes 로깅 운영(logging), Fluentd 중간에 카프카를 두는 이유는 여러가지가 있을 수 있을 것 같다. 첫번째 버퍼역할을 하기때문에 어느정도 파이프라인의 속도 조절이 가능하다. 두번째 로그를 카프카 큐에 담아두고, 여러 컨슈머 그룹이 각기의 목적으로 로그데이터를 사용가능하다. 바로 실습에 들어가보자. 구성 구성은 위 그림과 같다. fluentd는 컨테이너 로그를 tail하고 있고, tail한 데이터를 카프카로..

오늘은 쿠버네티스의 볼륨에 대해 다루어 볼 것이다. 간단하게 몇가지 볼륨 플러그인에 대해 예제를 다루어보고, 퍼시스턴트 볼륨&볼륨 클레임에 대해 다루어본다. yoonyeoseong/kubernetes-sample Contribute to yoonyeoseong/kubernetes-sample development by creating an account on GitHub. github.com emptyDir 해당 플러그인은 pod가 실행되는 호스트의 디스크를 임시로 컨테이너에 볼륨으로 할당해서 사용하는 방법이다. pod가 사라지면 emptyDir에 마운트해서 사용하는 데이터도 모두 사라진다. 하지만, pod이 종료되지 않고 단순히 container만 재시작된 것이라면 데이터는 유지된다. 주로 대용량 데이..

이번 포스팅에서 다루어볼 내용은 간단하게 쿠버네티스 ingress-nginx를 설치하고, 외부 트래픽을 내부 팟에게 전달해주는 예제이다. 바로 예제로 들어간다. > git clone https://github.com/kubernetes/ingress-nginx.git > cd ./ingress-nginx/deploy/static/provider/baremetal > kubectl apply -f . > kubectl get deploy -n ingress-nginx NAME READY UP-TO-DATE AVAILABLE AGE ingress-nginx-controller 1/1 1 1 60s 여기까지 따라왔다면 설치는 완료되었고, ingress-nginx를 위한 서비스 등이 떴을 것이다. kubectl..

오늘 간단히 다루어볼 내용은 쿠버네티스 리소스(cpu, memory) 할당과 관리에 대한 이야기이다. 리소스 관리 쿠버네티스에서 Pod를 어느 노드에 배포할지 결정하는 것을 스케쥴링이라고 한다. 팟에 대한 스케쥴링시, 노드에 애플리케이션이 동작할 수 있는 충분한자원(CPU, 메모리 등)이 확보되어야 배포가 가능하다. 이때문에 쿠버네티스 manifast 파일에 아주 중요한 설정이 있는데, 그것은 request, limit 에 대한 설정이다. Request&Limit 컨테이너에 적용될 리소스의 양을 정의하는데, request와 limit이라는 설정을 사용한다. request는 컨테이너가 생성될때 최소한 있어야하는 자원 요청이고, limit은 request만큼 할당된 것보다 더 많은 리소스가 필요할때, 해당 ..

오늘 다루어볼 내용은 쿠버네티스 환경에서의 로깅운영 방법이다. 지금까지는 쿠버네티스에 어떻게 팟을 띄우는지에 대해 집중했다면 오늘 포스팅 내용은 운영단계의 내용이 될 것 같다. 사실 어떻게 보면 가장 중요한 내용중에 하나라고 볼 수 있는 것이 로깅이다. 물리머신에 웹을 띄울 때는 파일로 로그를 날짜별로 남기고, 누적 일수이상된 파일은 제거 혹은 다른 곳으로 파일을 옮기는 등의 작업을 했을 것이다. 하지만 쿠버네티스에서는 파일로 로그를 남기지 않으며 조금 다른 방법으로 로깅운영을 진행한다. 컨테이너 환경에서 로그를 운영하는 구체적인 방법을 설명하기 전에 컨테이너 환경에서 로그가 어떻게 생성되는지 알아본다. 비컨테이너 환경의 애플리케이션에서는 보통 로그를 파일로 많이 남기고 한다. 이에 비해 도커에서는 로그..

이전 포스팅에서 쿠버네티스에 대한 용어와 개념을 다루어봤는데, 이번 포스팅에서는 실제 쿠버네티스가 어떤 구조로 되어 있는지 아키텍쳐에 대해 다루어본다. Kubernetes - Kubernetes 용어설명 마스터&노드 쿠버네티스 클러스터는 크게 마스터와 노드로 구성된다. 마스터는 쿠버네티스 클러스터의 전반적인 것을 관리하고 노드는 Pod이나 Service등처럼 쿠버네티스 위에서 동작하는 워크로드를 호스팅하는 역할을 한다. 1) 마스터 클러스터 전체를 관장하는 시스템이며 크게 API 서버, 스케줄러, 컨트롤러 매니저, etcd로 구성되어 있다. -API서버 : 쿠버네티스는 모든 명령과 통신을 API를 통해서 하는데, 그 중심이 되는 서버가 API 서버이다. -Etcd : 쿠버네티스 클러스터의 데이터 베이스 ..

지금까지 쿠버네티스에 대한 포스팅을 여러개 했는데, 더 진행하기 앞서 쿠버네티스에서 사용하는 용어 및 개념들을 정리하면 좋을듯 해서 포스팅한다. 마스터&노드 쿠버네티스의 클러스터의 구조에서 전체 클러스터를 관리하는 마스터 노드가 있고, 도커 컨테이너가 배포되는 노드가 존재한다. Pod Pod는 쿠버네티스에서 가장 기본적인 배포 단위로, 하나 이상의 도커 컨테이너의 묶음이다. 쿠버네티스는 컨테이너 단위로 배포하는 것이 아니라, Pod이라는 하나 이상의 도커 컨테이너로 이루어진 단위로 배포가 된다. 그렇다면 개별적인 컨테이너로 배포하지 않고, Pod이라는 단위로 배포하는 이유는 무엇일까? Pod 내의 컨테이너는 IP와 Port를 공유한다. 즉, 서로 localhost로 통신이 가능한 것이다. Pod 내에 배..

보통 쿠버네티스를 사용하면 단일 클러스터 환경에서 운영하지 않는다. 보통 Phase 별로 클러스터를 구성하기도 하고, 각 Phase의 클러스터는 하나 이상의 노드를 갖는 클러스터 형태인 경우가 많다. 또한 쿠버네티스를 사용하면 하나의 애플리케이션 혹은 미들웨어를 디플로이먼트나 서비스, 컨피그맵 혹은 인그레스 등 여러 종류의 리소스를 조합하는 형태로 배포한다. 그런데 각 Phase마다 배포시 달라지는 정보들이 많다. 예를 들면 개발환경의 데이터베이스 주소와 프로덕환경의 데이터베이스 주소가 다른것처럼 말이다. 그렇다면 모든 환경마다 매니페스트를 작성해야하나? 만약 Phase가 많다면 관리가 쉽지 않을 것이다. 이렇게 배포 환경에 따라 달라지는 설정값만 정의해 둔 다음 이에 따라 배포하는 메커니즘이 필요하게 ..