-
쿠버네티스 로깅(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..
-
쿠버네티스 taint, tolerationKubernetes 2018. 8. 8. 09:00
쿠버네티스 클러스터의 특정 노드에 taint를 지정할 수 있습니다. taint를 설정한 노드에는 포드들이 스케쥴링 되지 않습니다. taint가 걸린 노드에 포드들을 스케쥴링 하려면 toleration을 이용해서 지정해 주어야합니다. taint는 cordon이나 draint처럼 모든 포드가 스케쥴링 되지 않게 막는건 아니고, toleration을 이용한 특정 포드들만 실행하게 하고 다른 포드들은 들어오지 못하게 하는 역할을 합니다. 주로 노드를 지정된 역할만 하게할 때 사용합니다. DB용 포드를 띄워서 노드 전체의 CPU나 RAM자원을 독점해서 사용하게 할 수 있습니다. GPU가 있는 노드에는 다른 포드들은 실행되지 않고, 실제로 GPU를 사용하는 포드들만 실행시키도록 설정할 수도 있습니다. taint는 ..
-
쿠버네티스 cordon, drainKubernetes 2018. 8. 6. 09:00
쿠버네티스 클러스터를 사용하다 보면 특정 노드에 있는 포드들을 모두 다른 곳으로 옮기거나 아니면 특정 노드에는 포드들이 스케쥴링 되지 않도록 제한을 걸어둘 필요가 있습니다. 이런한 기능들을 제공하는 명령어가 kubectl에 있습니다. cordon, drain, taint등이 그런 용도의 명령어 들입니다. cordon 사용방법 kubectl cordon은 지정된 노드에 더이상 포드들이 스케쥴링되서 실행되지 않도록 합니다. cordon을 해보기 위해서 다음처럼 kubectl get nodes로 노드 이름을 확인한 다음에 cordon을 합니다. cordon을 한 다음에 다시 노드를 확인해 보면 노드의 status에 Ready외에 SchedulingDisabled이 추가된걸 확인할 수 있습니다. $ kubect..