k8s
-
쿠버네티스 모니터링 : 힙스터(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..
-
쿠버네티스 인증(Authentication)Kubernetes 2018. 8. 13. 09:00
사용자가 쿠버네티스의 API에 접근하기 위해서는 인증(Authentication)을 거쳐야 합니다. apiserver는 테스트 목적으로 로컬호스트의 8080포트에 http 포트를 띄웁니다. 외부에서 접근할 수 있는 기본포트는 6443인데 TLS인증이 적용되어 있습니다. 일반적인 https인증은 접근하는 클라이언트에서는 인증서가 필요없지만, 쿠버네티스의 apiserver에 열려 있는 이 포트에 접근하기위해서는 apiserver에서 가지고 있는 인증서에서 검증 가능한 유효한 인증서를 가지고 접근해야 통신이 가능합니다. 인증되지 않은 클라이언트가 외부에서 apiserver에 접근하는 것을 막기 위해서 입니다. 쿠버네티스에서 인증을 요청하기 위한 사용자는 일반적인 사용자와 서비스어카운트(service accou..