티스토리

아리수

검색하기

블로그 홈

아리수

arisu1000.tistory.com/m

arisu1000 님의 블로그입니다.

구독자: 10

방명록 방문하기

주요 글 목록

"쿠버네티스 입문 : 90가지 예제로 배우는 컨테이너 관리 자동화 표준" 출간 제가 집필한 쿠버네티스 책이 출간됐습니다. 오랜동안 작업했고 우여곡절도 많았는데 드디어 나와서 감회가 새롭네요. 쿠버네티스에 입문하는 분들께 도움이 되기를 기대합니다. 예스 24 : http://www.yes24.com/Product/Goods/85578606?scode=032&OzSrank=2 쿠버네티스 입문 현업의 운영 경험을 바탕으로 엄선한 쿠버네티스 입문 A~Z현재 다양한 인프라 구축의 핵심 기술은 컨테이너이다. 운영체제, 데이터베이스, 웹 서버 등 인프라 구축에 필요한 컨테이너 이미지 각각을 조합해 인프라 환경을 손쉽게 설정할 수 있다. 그런데 이러한 컨테이너 각각을 사용자가 수동으로 관리하려면 적지 않은 수고를 들여야 한다.쿠... www.yes24.com 교보문고 : http://www.ky.. 공감수 11 댓글수 14 2019. 12. 30.
쿠버네티스 pod 구성 패턴 사이드카 패턴(Sidecar) 사이드카 패턴은 원래 사용하려고 했던 기본컨테이너의 기능을 확장하거나 강화하는 용도의 컨테이너를 추가하는 패턴입니다. 기본 컨테이너에는 원래 목적의 기능에만 충실하고 나머지 부가적인 공통 기능들은 사이드카 컨테이너를 추가해서 사용할 수 있습니다. 일반적인 웹서버의 예를 생각해 보면 다음 그림처럼 웹서버 컨테이너는 웹서버로서의 역할에 충실하고 자신의 로그는 포드의 파일로 남깁니다. 그러면 사이드카 역할인 로그수집 컨테이너가 파일시스템에 쌓이는 로그를 수집해서 외부의 로그수집 시스템으로 보내는 역할을 합니다. 이렇게 구성하게 되면 웹서버 컨테이너만 다른 역할을 하는 컨테이너로 변경하게 되면 로그수집 컨테이너는 그대로 사용할 수 있습니다. 그래서 이런 공통역할을 하는 컨테이너의 .. 공감수 0 댓글수 2 2019. 3. 19.
쿠버네티스 커스텀 리소스(kubernetes Custom Resources) 쿠버네티스는 api 구조 들이 잘 정의되어 있습니다. 그래서 뛰어난 확장성을 가지고 있습니다. 쿠버네티스에서 제공하는 내장된 리소스 뿐만 아니라 사용자가 필요한 리소스를 쿠버네티스 내부에 정의해서 사용할 수 있습니다. 이렇게 커스텀리소스(CustomResource)를 정의해 놓으면 쿠버네티스 시스템 내부에 녹아들어서 kubectl같은 쿠버네티스 기본 명령어들과 함께 사용하는 것이 가능해 집니다. 그리고 그런 리소스들을 이용하는 자신만의 api 컨트롤러들을 만들어서 사용하는 것이 가능합니다. 쿠버네티스에서 사용자가 원하는 모든 기능들을 기본 기능으로 제공하려 하기 보다는 자신들에게 필요한 기능들은 직접 추가해서 사용할 수 있도록 커스텀 리소스 관련 기능들을 제공하고 있습니다. 커스텀 컨트롤러 커스텀 리소스.. 공감수 2 댓글수 0 2019. 1. 11.
helm 차트 사용하기 helm 차트 구조 helm에서 사용하는 차트는 디렉토리 하나에 들어가 있는 파일들의 집합입니다. 디렉토리 이름을 차트이름으로 지정하고 그 안에 필요한 파일들을 넣습니다. 디렉토리안의 파일들은 대략 다음과 같은 구조를 가집니다. wordpress/ Chart.yaml # 차트에 대한 정보를 가지고 있음. LICENSE # 옵션 : 차트 라이센스에 대한 정보를 가지고 있음. README.md # 옵션 : 차트에 대한 설명 파일 requirements.yaml # 옵션 : 차트의 의존성을 명시한 파일 values.yaml # 이 차트에서 사용하는 기본 설정 값 charts/ # 이 차트에 관련되어 있는 차트들 templates/ # 쿠버네티스 매니페스트 파일들로 변환될 YAML템플릿 파일들 templates.. 공감수 2 댓글수 0 2018. 12. 24.
helm 기본 helm 소개 helm은 쿠버네티스 패키지 매니저 입니다. 쿠버네티스를 사용하다보면 결국 수많은 YAML파일들을 관리해야 됩니다. helm에서는 이런 YAML파일들의 집합을 차트(chart)라고하고, 이 차트를 관리할 수 있게 해주는 도구가 helm입니다. helm은 쿠버네티스의 하위 프로젝트로 시작되었다가 2018년 6월에 CNCF재단의 정식 프로젝트로 승격되었습니다. Helm은 차트를 만들고, 차트 압축 파일(tgz)를 만들수 있습니다. 그리고 차트들이 저장되어 있는 차트 저장소(chart repository)와 연계해서 쿠버네티스 클러스터에 차트를 설치하거나 삭제할 수 있습니다. helm으로 설치된 차트들의 배포 주기를 관리할 수도 있습니다. helm을 이용하면 잘 정리된 차트들을 이용해서 필요한 .. 공감수 5 댓글수 0 2018. 12. 21.
쿠버네티스 DNS(kubernetes dns) 쿠버네티스에서는 클러스터 내부에서만 사용가능한 DNS를 설정해 놓고 사용할 수 있습니다. 그래서 포드간 통신을 할때나 IP가 아닌 도메인을 설정해 두고 사용할 수 있습니다. 그렇게해서 한 클러스터에서 사용하던 yaml파일에서 포드간 통신을 도메인으로 설정해 둔다면 그걸 별다른 수정 없기 그대로 다른 클러스터로 가져가서 사용하는 것도 가능합니다. ip로 통신하도록 되어 있다면 한곳에서 세팅해놨던 yaml파일을 다른곳으로 옮겨 가져가서 사용하려고 할때 그 클러스터에서 사용하는 ip 대역이 다른 것이라면 그대로 사용할 수가 없게 됩니다. 이럴때 설정이 도메인을 사용하도록 되어 있다면 별다른 수정없이 그대로 사용할 수가 있습니다. 그 뿐만 아니라 일부의 경우에는 서비스디스커버리(service discovery).. 공감수 14 댓글수 3 2018. 9. 17.
쿠버네티스 오토스케일링(kubernetes autoscaling) 클라우드를 사용하면서 유용한 기능으로 언급하는 것중에 가장 많이이야기하는게 오토스케일링이 아닐까 싶습니다. 컨테이너 오케스트레이션 쪽에서는 컨테이너만 잘 준비되어 있으면 오토스케일링이 더욱 쉬워지게 되었습니다. 쿠버네티스에서도 HPA(Horizontal Pod Autoscaler)라는 기본 오토스케일링 기능이 내장되어 있습니다. HPA는 CPU 사용률 기반으로 디플로이먼트로 실행된 포드의 개수를 개수를 늘리거나 줄이는 역할을 해줍니다. HPA 설정하기 오토스케일링 설정을 해보도록 하겠습니다. 다음 파일을 autoscaling.yaml로 저장한 다음에 kubectl apply -f autosclinging.yaml로 적용시키면 됩니다. apiVersion: autoscaling/v1 kind: Horizo.. 공감수 3 댓글수 0 2018. 9. 12.
쿠버네티스 모니터링 : 프로메테우스(kubernetes monitoring : phrometheus) 모니터링 솔루션으로 최근 가장 많이 주목받고 있는건 프로메테우스(phrometheus)입니다. 프로메테우스는 사우드클라우드(SoundCloud)에서 최초 개발했고 현재는 CNCF에 속한 프로젝트입니다. CNCF에 속한 여러가지 프로젝트들 중에서 쿠버네티스가 첫번째 졸업생이고 프로메테우스가 두번째 졸업생일 정도로 많은 주목을 받고 있는 프로젝트 입니다. 프로메테우스 주요 기능 프로메테우스의 주요 기능으로는 시계열(time series) 데이터를 저장할 수 있는 다차원(multi-dimensional) 데이터 모델과 이 데이터 모델을 효과적으로 활용할 수 있는 PromQL이라는 쿼리 언어가 있습니다. 기본적인 데이터 수집은 pull 구조로 되어 있어서 프로메테우스 서버가 수집하려는 대상에게서 데이터를 가져오.. 공감수 3 댓글수 2 2018. 9. 10.
쿠버네티스 모니터링 : metrics-server (kubernetes monitoring : metrics-server) 메트릭서버(metrics-server) 개념 쿠버네티스의 메트릭 수집 모니터링 아키텍처에서 코어메트릭 파이프라인 쪽을 가볍게 하기 위해서 힙스터를 deprecated시키고 그 다음으로 쿠버네티스에서 모니터링 표준으로 도입하려고 하는건 메트릭서버(metrics-server)입니다. 메트릭서버는 힙스터를 간소화한 버전이라고 생각하면 됩니다. kubelet에서 메트릭데이터를 수집해서 메모리에 저장하고 있습니다. 또한 apiserver를 통해 포드나 노드의 메트릭을 조회하는데 사용되는 메트릭 API(Metrics API)를 제공해 줍니다. 쿠버네티스에서 필요한 핵심 데이터들은 대부분 etcd에 저장되지만 메트릭 데이터들을 etcd에 저장하면 etcd의 부하가 너무 커지기 때문에 그렇게 하지 않고 메모리에 저장하.. 공감수 3 댓글수 1 2018. 9. 7.
쿠버네티스 모니터링 아키텍처(kubernetes monitoring architecture) 메트릭 분류 쿠버네티스에서 수집하는 메트릭은 크게 2개의 메트릭으로 분류됩니다. 시스템 메트릭(system metrics)과 서비스 메트릭(service metrics)으로 나눠집니다. 시스템 메트릭(system metrics) 시스템 메트릭은 노드나 컨테이너의 CPU, 메모리 사용량 같은 일반적인 시스템 관련 메트릭들입니다. 시스템 메트릭은 다시 코어 메트릭(core metrics)과 비코어메트릭(non-core metrics)으로 나뉩니다. 코어 메트릭은 쿠버네티스 내부 컴포넌트들이 사용하는 메트릭들입니다. 현재 클러스터내의 가용자원이 얼마나 되는지 파악하는데도 사용하고 내장된 오토스케일링등에서도 사용합니다. 대시보드에서도 사용하고 “kubectl top” 같은 명령어에서 사용하는 메트릭 데이터도 여.. 공감수 4 댓글수 0 2018. 9. 3.
쿠버네티스 모니터링 : 힙스터(kubernetes monitoring : heapster) 클러스터에서 애플리케이션을 운영하다가 보면 현재 클러스터의 상태는 어떤지 앱의 상태는 어떤지 모니터링하는 것이 중요합니다. 기본적인 시스템 메트릭인 CPU, 메모리부터 시작해서 애플리케이션의 특수한 메트릭 정보까지 많은 것들을 모니터링해야 합니다. 쿠버네티스에서는 기본적으로 사용할 수 있는 모니터링 도구로 힙스터(heapster)를 제공해 왔었습니다. 하지만 힙스터는 쿠버네티스 1.11버전에서 deprecated되었고, 1.13버전에서 완전히 제거될 예정입니다. 그리고 앞으로는 메트릭서버(metrics-server)를 힙스터 대체로 사용하길 권장하고 있습니다. 그외에 추가적으로 더 세세한 모니터링이 필요하면 프로메테우스(Prometheus) 같은 전문 모니터링 도구를 이용할 것을 권장하고 있습니다. 힙스.. 공감수 0 댓글수 0 2018. 9. 3.
쿠버네티스 대시보드(kubernetes dashboard) 쿠버네티스는 일반적으로 커맨드라인 도구인 kubectl을 사용해서 관리합니다. 클러스터의 관리뿐만 아니라 포드의 생성/삭제/업데이트를 모두 kubectl를 통해서 할 수 있습니다. 하지만 이외에도 대시보드(dashboard, https://github.com/kubernetes/dashboard)라는 웹 UI를 제공하기도 합니다. 웹UI배포는 https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard.yaml 이 파일을 사용하면 됩니다. 이 파일의 마지막에 있는 서비스 부분만 다음 처럼 수정해 줍니다. 포트를 사용해서 직접 접근가능하게 노드포트를 사용하도록 변경해줍니다. --- # ------.. 공감수 0 댓글수 3 2018. 8. 31.
쿠버네티스 로깅(kubernetes logging) 클러스터 환경에서 앱을 운영할때 주의해야할 것 중에 하나가 로그를 처리하는 것입니다. 컨테이너 오케스트레이터를 사용하는 환경에서 로그를 수집해야할 때 주의해야 할 점 중에 하나는 로그를 로컬디스크에 파일로 쌓지 않아야 한다는 것입니다. 전통적인 애플리케이션 운영환경에서는 로컬 파일시스템의 지정된 위치에 파일로 로그를 쌓도록 구성합니다. 그리고 로그 양이 너무 많아져서 디스크사용량을 전부 채울때까지 로그가 쌓이는 것을 방지하기 위해서, logrotate를 사용하거나 애플리케이션의 로그관련 라이브러리나 프레임워크에서 옵션을 지정해서 로그가 쌓이기 시작한지 일정 시간이 지나거나 로그양이 일정 크기에 도달하면 오래된 로그들을 자동으로 삭제하도록 처리합니다. 이런 운영방식은 앱들이 항상 지정된 장비에서 실행된다는.. 공감수 3 댓글수 13 2018. 8. 29.
쿠버네티스 네트워킹 : 서비스 네트워킹(kubernetes service networking) 쿠버네티스에서 포드간에 어떻게 통신하는지는 알아봤습니다. 하지만 쿠버네티스에서 실제로 서비스용으로 앱을 올려서 사용한다면 단순히 포드와 포드사이의 통신만 하는 일은 사실 잘 없습니다. 단일 포드보다는 여러개의 포드를 띄우게 되고 그 포드들의 앞에 서비스를 두고 사용하는 것이 일반적인 구성입니다. 그래서 실제로 클러스터 내부에서 통신을 할때는 서비스의 IP를 바라보도록 되어 있습니다. clusterIP나 NodePort로 구성했을때 어떻게 서비스를 거쳐서 실제 포드까지 패킷이 가게 되는지 알아보겠습니다. 쿠버네티스에서는 포드용 CIDR과 서비스용 CIDR을 별도로 지정하게 되어 있습니다. 포드용 CIDR은 마스터용 프로세스들을 실행할 때 --cluster-cidr 옵션을 이용해서 지정해 줍니다. 서비스용 .. 공감수 5 댓글수 2 2018. 8. 27.
쿠버네티스 네트워킹 : 포드 네트워킹(kubernetes pod networking) 쿠버네티스는 일반적인 도커 네트워크와는 다른 구조를 가지고 있습니다. 여러대의 노드를 사용해서 클러스터를 구성하는데 개별 노드에 뜬 포드들이 서로 IP를 통해서 통신을 할 수 있는 구조가 됩니다. 그리고 각 포드는 1개의 컨테이너로 구성되는게 아니라 여러개의 컨테이너로 구성됩니다. 여기서는 포드에 어떻게 IP가 할당되고 어떤 원리로 클러스터 내부에서 그 IP를 통해서 통신이 가능한지 살펴보도록 하겠습니다. 먼저 일반적인 도커 네트워크 구조를 살펴 보겠습니다. 다음 그림처럼 일반적인 도커네트워크는 호스트에 docker0이라는 브릿지가 추가되어서 컨테이너와 호스트간의 네트워크를 연결해 주도록 되어 있습니다. 컨테이너에는 가상의 veth0이라는 네트워크 디바이스가 추가되어서 docker0와 통신을 하게 됩니다.. 공감수 7 댓글수 7 2018. 8. 23.
쿠버네티스 볼륨(kubernetes volume : PersistentVolume, PersistentVolumeClaim) 컨테이너는 기본적으로 상태가 없는(stateless) 앱을 사용합니다. 상태가 없다는건 어떤 이유로건 컨테이너가 죽었을때 현재까지의 데이터가 사라진다는 것입니다. 상태가 없기 때문에 컨테이너에 문제가 있거나 노드에 장애가 발생해서 컨테이너를 새로 띄우거나 다른곳으로 옮기는게 자유롭습니다. 이것이 컨테이너의 장점입니다. 하지만 앱의 특성에 따라서 컨테이너가 죽더라도 데이터가 사라지면 안되고 보존되어야 하는 경우가 있습니다. 대표적으로 정보를 파일로 기록해두는 젠킨스가 있습니다. mysql같은 데이터베이스도 컨테이너가 내려가거나 재시작했다고해서 데이터가 사라지면 안됩니다. 그 때 사용할 수 있는게 볼륨입니다. 볼륨을 사용하게 되면 컨테이너가 재시작을 하더라도 데이터가 사라지지 않고 유지됩니다. 더 나아가서 .. 공감수 4 댓글수 3 2018. 8. 20.
쿠버네티스 권한관리(Authorization) 권한관리 기본 쿠버네티스 클러스터의 api에 접근하기 위해서는 우선 유효한 사용자 인지 인증(authentication)을 거처야 합니다. 인증이 됐으면 그 사용자가 접근하려고하는 api에 권한이 있는지 확인이 된 다음에 api를 사용할 수 있습니다. 하나의 클러스터를 여러명의 사용자가 사용하는 경우에 api나 네임스페이스별로 권한을 구분해서 권한이 있는 곳에만 접근을 가능하게 할 수 있습니다. 특정 자원에 대한 읽기 전용 권한만 추가해서 다른 사람이 관리하는 네임스페이스라고 하더라도 참고용으로 살펴보게 할수도 있습니다. 물론 관리자는 모든 api에 대한 권한을 열어두고 모든 자원에 접근할수가 있습니다. 쿠버네티스에서는 이러한 권한 관리를 위해서 여러가지 방법을 제공하고 있습니다. 크게 ABAC(Attr.. 공감수 7 댓글수 5 2018. 8. 16.
쿠버네티스 인증(Authentication) 사용자가 쿠버네티스의 API에 접근하기 위해서는 인증(Authentication)을 거쳐야 합니다. apiserver는 테스트 목적으로 로컬호스트의 8080포트에 http 포트를 띄웁니다. 외부에서 접근할 수 있는 기본포트는 6443인데 TLS인증이 적용되어 있습니다. 일반적인 https인증은 접근하는 클라이언트에서는 인증서가 필요없지만, 쿠버네티스의 apiserver에 열려 있는 이 포트에 접근하기위해서는 apiserver에서 가지고 있는 인증서에서 검증 가능한 유효한 인증서를 가지고 접근해야 통신이 가능합니다. 인증되지 않은 클라이언트가 외부에서 apiserver에 접근하는 것을 막기 위해서 입니다. 쿠버네티스에서 인증을 요청하기 위한 사용자는 일반적인 사용자와 서비스어카운트(service accou.. 공감수 0 댓글수 2 2018. 8. 13.
쿠버네티스 taint, toleration 쿠버네티스 클러스터의 특정 노드에 taint를 지정할 수 있습니다. taint를 설정한 노드에는 포드들이 스케쥴링 되지 않습니다. taint가 걸린 노드에 포드들을 스케쥴링 하려면 toleration을 이용해서 지정해 주어야합니다. taint는 cordon이나 draint처럼 모든 포드가 스케쥴링 되지 않게 막는건 아니고, toleration을 이용한 특정 포드들만 실행하게 하고 다른 포드들은 들어오지 못하게 하는 역할을 합니다. 주로 노드를 지정된 역할만 하게할 때 사용합니다. DB용 포드를 띄워서 노드 전체의 CPU나 RAM자원을 독점해서 사용하게 할 수 있습니다. GPU가 있는 노드에는 다른 포드들은 실행되지 않고, 실제로 GPU를 사용하는 포드들만 실행시키도록 설정할 수도 있습니다. taint는 .. 공감수 3 댓글수 3 2018. 8. 8.
쿠버네티스 cordon, drain 쿠버네티스 클러스터를 사용하다 보면 특정 노드에 있는 포드들을 모두 다른 곳으로 옮기거나 아니면 특정 노드에는 포드들이 스케쥴링 되지 않도록 제한을 걸어둘 필요가 있습니다. 이런한 기능들을 제공하는 명령어가 kubectl에 있습니다. cordon, drain, taint등이 그런 용도의 명령어 들입니다. cordon 사용방법 kubectl cordon은 지정된 노드에 더이상 포드들이 스케쥴링되서 실행되지 않도록 합니다. cordon을 해보기 위해서 다음처럼 kubectl get nodes로 노드 이름을 확인한 다음에 cordon을 합니다. cordon을 한 다음에 다시 노드를 확인해 보면 노드의 status에 Ready외에 SchedulingDisabled이 추가된걸 확인할 수 있습니다. $ kubect.. 공감수 1 댓글수 0 2018. 8. 6.
쿠버네티스 시크릿(kubernetes secret) 시크릿(secret)은 비밀번호, OAuth 토큰, ssh 키 같은 민감한 정보들을 저장하는 용도로 사용합니다. 이런 정보들은 컨테이너 안에 저장해 두지 않고 별도로 보관해 두었다가 실제 포드가 실행할때 설정을 통해서 컨테이너에 제공해 줍니다. 시크릿 종류 시크릿은 내장 시크릿(built-in)과 사용자 시크릿 2가지 종류가 있습니다. 내장 시크릿은 쿠버네티스 클러스터 내부에서 API에 접근할때 사용됩니다. 클러스터 내부에서 사용되는 계정인 ServiceAccount를 생성하면 자동으로 관련 시크릿이 만들어 집니다. 이렇게 만들어진 시크릿을 이용해서 해당 ServiceAccount가 권한을 가지고 있는 API에 접근할 수 있습니다. 사용자 시크릿은 사용자가 만든 시크릿입니다. 시크릿은 kubectl cr.. 공감수 6 댓글수 0 2018. 8. 3.
쿠버네티스 컨피그맵(kubernetes configmap) 컨피그맵(configmap)은 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능입니다. 클라우드 네이티브 아키텍처에서 컨테이너는 변하지 않는 자원이어야 합니다. 개발할때 사용하는 컨테이너와 실제 서비스용으로 사용되는 컨테이너가 동일해야 한다는 것입니다. 그래야지만 개발과 서비스 사이의 환경 차이에서 오는 잠재적 문제를 제가할 수 있습니다. 그런데 개발용과 서비스용에서는 서로 다른 설정이 필요한 경우가 많습니다. 간단히는 사용하는 DB가 다를수도 있고 실제 개발할때는 로그를 debug모드로 출력하고 서비스용에서는 info 모드로 로그를 출력해야 하는등 여러가지 다른 설정을 해야합니다. 이렇게 다른 설정을 가지고 실행을 해야할때 사용하는 것이 컨피그맵입니다. 컨피그맵을 컨테이너와.. 공감수 7 댓글수 1 2018. 8. 1.
쿠버네티스 라벨을 이용한 카나리(canary) 배포 라벨은 다양하게 활용할 수 있습니다. 그 중에서도 배포에 활용하는 방법을 알아보도록 하겠습니다. 일반적으로 배포를 이야기 할 때는 롤링업데이트, 블루/그린, 카나리등 여러가지 방법이 있습니다. 롤링업데이트는 전체 배포 되어 있는 포드들을 한꺼번에 교체하는 것이 아니라 일정 개수씩 바꿔치기하면서 배포하는 방법으로 디플로이먼트의 기본 배포 방법입니다. 블루/그린은 기존에 띄워져 있는 포드 개수와 동일한 개수 만큼의 신규포드를 모두 띄운 다음에 신규 포드가 이상없이 정상적으로 떴는지 확인한 다음에 들어오는 트래픽을 한번에 신규포드쪽으로 옮기는 방법입니다. 이것역시 디플로이먼트를 이용하면 가능합니다. 카나리 배포는 옛날 광부들이 광산에 유독가스가 있는지 확인하기 위해 가스에 민감한 카나리아를 광산에 가지고 들어.. 공감수 1 댓글수 0 2018. 7. 31.
쿠버네티스 라벨과 애노테이션(kubernetes label, annotation) 라벨과 애노테이션은 쿠버네티스에서 자원들의 메타데이터를 관리하는데 사용합니다. 라벨은 셀렉터와 함께 사용되어서 특정 라벨을 가진 자원들을 선택할때 주로 사용합니다. 애노테이션은 의미 그대로 주석 성격의 메타데이터를 기록해 두는데 사용합니다. 라벨과 애노테이션의 가장 큰 차이는 라벨은 쿠버네티스 클러스터 내부에 사용자가 객체를 생성할때 그 객체를 구분하기 위해서 사용자가 임의로 원하는 값을 지정해서 사용합니다. 애노테이션은 라벨처럼 사용자가 원하는 값을 설정하기 보다는 쿠버네티스 시스템에서 필요한 정보들을 표시해 주기 위해서 사용합니다. 라벨(Label) 라벨은 키/값 쌍으로 구성됩니다. 라벨은 사용자가 클러스터내에 객체를 만들때 메타데이터로 붙일 수 있습니다. 생성된 다음에는 언제든지 수정이 가능합니다... 공감수 2 댓글수 1 2018. 7. 26.
쿠버네티스 인그레스(kubernetes ingress) 인그레스(ingress)는 클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙들의 모음입니다. 외부에서 접근가능한 URL을 사용할 수 있게 하고, 트래픽 로드밸런싱도 해주고, SSL 인증서 처리도 해주고, 도메인 기반으로 가상 호스팅을 제공하기도 합니다. 인그레스 자체는 이런 규칙들을 정의해둔 자원이고 이런 규칙들을 실제로 동작하게 해주는게 인그레스 컨트롤러(ingress controller)입니다. 클라우드 서비스를 사용하게 되면 별다른 설정없이 각 클라우드 서비스에서 자사의 로드밸런서 서비스들과 연동해서 인그레스를 사용할 수 있게 해줍니다. 클라우드 서비스를 사용하지 않고 직접 쿠버네티스 클러스터를 구축해서 사용하는 경우라면 인그레스 컨트롤러를 직접 인그레스와 연동해 주어야 합니.. 공감수 3 댓글수 20 2018. 7. 18.
쿠버네티스 서비스(kubernetes services) (2) kube-proxy 소개 및 종류쿠버네티스에서 서비스를 만들었을 때 나오는 ClusterIP나 NodePort로 접근하게 해주는건 큐브프록시(kube-proxy)입니다. 큐브프록시는 쿠버네티스 클러스터의 각 노드마다 실행되고 있으면서 클러스터 내부 IP로 연결되기 바라는 요청을 적절한 곳으로 전달해 주는 역할을 합니다. 큐브프록시가 네트워크를 관리하는 방법은 userspace, iptables, ipvs 3가지가 있습니다. 초기에는 userspace가 기본 모드였고 현재(2018년 6월)에는 iptables가 기본모드입니다. 그리고 iptables에서 ipvs 모드로 넘어가려고 하고 있습니다. userspace 모드userspace모드로 설정하면 다음 그림같은 구조를 가지게 됩니다. 클라이언트에서 서비스.. 공감수 6 댓글수 3 2018. 7. 13.
쿠버네티스 서비스(kubernetes services) (1) 서비스 소개 쿠버네티스 클러스터안에 컨트롤러를 이용해서 포드를 띄웠다면 이제 그 포드들에 접근하는 방법에 대해 알아봐야할 때입니다. 포드는 컨트롤러에 의해 관리되기 때문에 한군데에 고정되서 떠 있지 않고, 클러스터내를 옮겨다니게 됩니다. 이 과정에서 노드를 옮기면서 실행되기도 하고 클러스터내의 포드 IP가 변경되기도 합니다. 이렇게 동적으로 변하는 포드들에 고정된 방법으로 접근하기 위해서 사용하게는 쿠버네티스의 서비스(service)입니다. 서비스를 사용하게 되면 포드가 클러스터내의 어디에 있는지에 상관없이 고정된 주소를 이용해서 접근이 가능해 집니다. 그리고 클러스터 외부에서 포드에 접근하는것도 서비스를 통해서 가능합니다. 나중에 인그레스(ingress)에 대해 알게 되면 인그레스를 통해서도 가능해 지.. 공감수 1 댓글수 3 2018. 7. 10.
쿠버네티스 컨트롤러 : 크론잡(CronJob) 크론잡은 잡을 시간 기준으로 관리하는 합니다. 지정된 시간에 한번만 잡을 실행하거나 주기적으로 지정된 시간동안 반복하면서 잡을 실행합니다. 시간을 지정하는 형식은 리눅스나 유닉스에서 많이 사용하는 크론 형식으로 지정합니다. 크론잡은 지정된 시간에 잡을 실행하는데 정확하게 한번에 하나의 잡만을 실행하는게 아니라, 2개의 잡이 실행될수도 있고 잡이 실행되지 않을수도 있습니다. startingDeadlineSeconds 옵션을 크게 설정하거나 아니면 따로 설정하지 않고 concurrencyPolicy 옵션을 Allow로 두면 잡은 최소한 한번(at least once)은 실행됩니다. 크론잡은 잡을 생성하는 역할만 하고 잡이 실행되고 나면 일반 잡과 마찬가지로 작동합니다. 다음 내용을 cronjob.yaml로 .. 공감수 0 댓글수 0 2018. 6. 27.
쿠버네티스 컨트롤러 : 잡(Job) 잡 컨트롤러는 계속해서 실행되어야하는 성격이 아니라 실행되고나서 종료되어야하는 성격의 작업을 실행시킬때 사용하는 컨트롤러 입니다. 잡은 특정 개수 만큼의 포드가 성공적으로 완료되는걸 보장해 줍니다. 가장 간단한 경우로는 잡이 포드 하나를 실행하고 포드가 정상적으로 종료됐는지 확인하는 것입니다. 실행한 포드가 실패하거나 하드웨어 장애가 발생하거나 노드가 재부팅 되는등 문제가 발생하면 다시 포드를 실행합니다. 잡 하나가 포드를 여러개 실행하는 것도 가능합니다. 다음 예제 yaml을 job.yaml파일로 만들고 kubectl apply -f job.yaml로 실행해 봅니다. apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: spec: cont.. 공감수 0 댓글수 2 2018. 6. 25.
쿠버네티스 컨트롤러 : 스테이트풀셋(StatefulSets) 앞서 살펴봤던 리플리카컨트롤러, 리플리케이션셋, 디플로이먼트는 모두 상태가 없는(stateless) 포드들을 관리하는 용도 였습니다. 스테이트풀셋(StatefulSets)은 단어의 의미 그대로 상태를 가지고 있는 포드들을 관리하는 컨트롤러 입니다. 스테이트풀셋을 사용하면 볼륨을 사용해서 특정 데이터를 기록해두고 그걸 포드가 재시작했을때도 유지할 수 있습니다. 여러개의 포드를 띄울때 포드 사이에 순서를 지정해서 지정된 순서대로 포드가 실행되게 할수도 있습니다. 이런식으로 어떠한 상태를 가지고 있어야 할때 사용하는게 스테이트풀 셋입니다. 스테이트풀셋을 실행할수 있는 예제 yaml은 다음과 같습니다. apiVersion: v1 kind: Service metadata: name: nginx labels: ap.. 공감수 0 댓글수 0 2018. 6. 22.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.