docker
-
쿠버네티스 모니터링 아키텍처(kubernetes monitoring architecture)Kubernetes 2018. 9. 3. 11:32
메트릭 분류 쿠버네티스에서 수집하는 메트릭은 크게 2개의 메트릭으로 분류됩니다. 시스템 메트릭(system metrics)과 서비스 메트릭(service metrics)으로 나눠집니다. 시스템 메트릭(system metrics) 시스템 메트릭은 노드나 컨테이너의 CPU, 메모리 사용량 같은 일반적인 시스템 관련 메트릭들입니다. 시스템 메트릭은 다시 코어 메트릭(core metrics)과 비코어메트릭(non-core metrics)으로 나뉩니다. 코어 메트릭은 쿠버네티스 내부 컴포넌트들이 사용하는 메트릭들입니다. 현재 클러스터내의 가용자원이 얼마나 되는지 파악하는데도 사용하고 내장된 오토스케일링등에서도 사용합니다. 대시보드에서도 사용하고 “kubectl top” 같은 명령어에서 사용하는 메트릭 데이터도 여..
-
쿠버네티스 모니터링 : 힙스터(kubernetes monitoring : heapster)Kubernetes 2018. 9. 3. 09:00
클러스터에서 애플리케이션을 운영하다가 보면 현재 클러스터의 상태는 어떤지 앱의 상태는 어떤지 모니터링하는 것이 중요합니다. 기본적인 시스템 메트릭인 CPU, 메모리부터 시작해서 애플리케이션의 특수한 메트릭 정보까지 많은 것들을 모니터링해야 합니다. 쿠버네티스에서는 기본적으로 사용할 수 있는 모니터링 도구로 힙스터(heapster)를 제공해 왔었습니다. 하지만 힙스터는 쿠버네티스 1.11버전에서 deprecated되었고, 1.13버전에서 완전히 제거될 예정입니다. 그리고 앞으로는 메트릭서버(metrics-server)를 힙스터 대체로 사용하길 권장하고 있습니다. 그외에 추가적으로 더 세세한 모니터링이 필요하면 프로메테우스(Prometheus) 같은 전문 모니터링 도구를 이용할 것을 권장하고 있습니다. 힙스..
-
쿠버네티스 대시보드(kubernetes dashboard)Kubernetes 2018. 8. 31. 09:00
쿠버네티스는 일반적으로 커맨드라인 도구인 kubectl을 사용해서 관리합니다. 클러스터의 관리뿐만 아니라 포드의 생성/삭제/업데이트를 모두 kubectl를 통해서 할 수 있습니다. 하지만 이외에도 대시보드(dashboard, https://github.com/kubernetes/dashboard)라는 웹 UI를 제공하기도 합니다. 웹UI배포는 https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard.yaml 이 파일을 사용하면 됩니다. 이 파일의 마지막에 있는 서비스 부분만 다음 처럼 수정해 줍니다. 포트를 사용해서 직접 접근가능하게 노드포트를 사용하도록 변경해줍니다. --- # ------..
-
쿠버네티스 로깅(kubernetes logging)Kubernetes 2018. 8. 29. 09:00
클러스터 환경에서 앱을 운영할때 주의해야할 것 중에 하나가 로그를 처리하는 것입니다. 컨테이너 오케스트레이터를 사용하는 환경에서 로그를 수집해야할 때 주의해야 할 점 중에 하나는 로그를 로컬디스크에 파일로 쌓지 않아야 한다는 것입니다. 전통적인 애플리케이션 운영환경에서는 로컬 파일시스템의 지정된 위치에 파일로 로그를 쌓도록 구성합니다. 그리고 로그 양이 너무 많아져서 디스크사용량을 전부 채울때까지 로그가 쌓이는 것을 방지하기 위해서, logrotate를 사용하거나 애플리케이션의 로그관련 라이브러리나 프레임워크에서 옵션을 지정해서 로그가 쌓이기 시작한지 일정 시간이 지나거나 로그양이 일정 크기에 도달하면 오래된 로그들을 자동으로 삭제하도록 처리합니다. 이런 운영방식은 앱들이 항상 지정된 장비에서 실행된다는..
-
쿠버네티스 네트워킹 : 서비스 네트워킹(kubernetes service networking)Kubernetes 2018. 8. 27. 09:00
쿠버네티스에서 포드간에 어떻게 통신하는지는 알아봤습니다. 하지만 쿠버네티스에서 실제로 서비스용으로 앱을 올려서 사용한다면 단순히 포드와 포드사이의 통신만 하는 일은 사실 잘 없습니다. 단일 포드보다는 여러개의 포드를 띄우게 되고 그 포드들의 앞에 서비스를 두고 사용하는 것이 일반적인 구성입니다. 그래서 실제로 클러스터 내부에서 통신을 할때는 서비스의 IP를 바라보도록 되어 있습니다. clusterIP나 NodePort로 구성했을때 어떻게 서비스를 거쳐서 실제 포드까지 패킷이 가게 되는지 알아보겠습니다. 쿠버네티스에서는 포드용 CIDR과 서비스용 CIDR을 별도로 지정하게 되어 있습니다. 포드용 CIDR은 마스터용 프로세스들을 실행할 때 --cluster-cidr 옵션을 이용해서 지정해 줍니다. 서비스용 ..
-
쿠버네티스 네트워킹 : 포드 네트워킹(kubernetes pod networking)Kubernetes 2018. 8. 23. 09:00
쿠버네티스는 일반적인 도커 네트워크와는 다른 구조를 가지고 있습니다. 여러대의 노드를 사용해서 클러스터를 구성하는데 개별 노드에 뜬 포드들이 서로 IP를 통해서 통신을 할 수 있는 구조가 됩니다. 그리고 각 포드는 1개의 컨테이너로 구성되는게 아니라 여러개의 컨테이너로 구성됩니다. 여기서는 포드에 어떻게 IP가 할당되고 어떤 원리로 클러스터 내부에서 그 IP를 통해서 통신이 가능한지 살펴보도록 하겠습니다. 먼저 일반적인 도커 네트워크 구조를 살펴 보겠습니다. 다음 그림처럼 일반적인 도커네트워크는 호스트에 docker0이라는 브릿지가 추가되어서 컨테이너와 호스트간의 네트워크를 연결해 주도록 되어 있습니다. 컨테이너에는 가상의 veth0이라는 네트워크 디바이스가 추가되어서 docker0와 통신을 하게 됩니다..
-
쿠버네티스 볼륨(kubernetes volume : PersistentVolume, PersistentVolumeClaim)Kubernetes 2018. 8. 20. 09:00
컨테이너는 기본적으로 상태가 없는(stateless) 앱을 사용합니다. 상태가 없다는건 어떤 이유로건 컨테이너가 죽었을때 현재까지의 데이터가 사라진다는 것입니다. 상태가 없기 때문에 컨테이너에 문제가 있거나 노드에 장애가 발생해서 컨테이너를 새로 띄우거나 다른곳으로 옮기는게 자유롭습니다. 이것이 컨테이너의 장점입니다. 하지만 앱의 특성에 따라서 컨테이너가 죽더라도 데이터가 사라지면 안되고 보존되어야 하는 경우가 있습니다. 대표적으로 정보를 파일로 기록해두는 젠킨스가 있습니다. mysql같은 데이터베이스도 컨테이너가 내려가거나 재시작했다고해서 데이터가 사라지면 안됩니다. 그 때 사용할 수 있는게 볼륨입니다. 볼륨을 사용하게 되면 컨테이너가 재시작을 하더라도 데이터가 사라지지 않고 유지됩니다. 더 나아가서 ..
-
쿠버네티스 권한관리(Authorization)Kubernetes 2018. 8. 16. 09:00
권한관리 기본 쿠버네티스 클러스터의 api에 접근하기 위해서는 우선 유효한 사용자 인지 인증(authentication)을 거처야 합니다. 인증이 됐으면 그 사용자가 접근하려고하는 api에 권한이 있는지 확인이 된 다음에 api를 사용할 수 있습니다. 하나의 클러스터를 여러명의 사용자가 사용하는 경우에 api나 네임스페이스별로 권한을 구분해서 권한이 있는 곳에만 접근을 가능하게 할 수 있습니다. 특정 자원에 대한 읽기 전용 권한만 추가해서 다른 사람이 관리하는 네임스페이스라고 하더라도 참고용으로 살펴보게 할수도 있습니다. 물론 관리자는 모든 api에 대한 권한을 열어두고 모든 자원에 접근할수가 있습니다. 쿠버네티스에서는 이러한 권한 관리를 위해서 여러가지 방법을 제공하고 있습니다. 크게 ABAC(Attr..