1. 쿠버네티스 컨테이너를 실행하는 하드웨어 호스트, 즉 노드에 대한 지표 모니터링이 필요하다.
쿠버네티스는 노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링이 필요하다.
2. 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 서비스 디스커버리 (Service discovery)를 사용한다.
모니터링 대상 목록을 유지하고 있고, 대상에 대한 IP나 기타 접속 정보를 설정 파일에 주면, 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보를 읽어온다. 오토스케일링을 많이 사용하는 클라우드 환경이나 쿠버네티스와 같은 컨테이너 환경에서는 모니터링 대상의 IP가 동적으로 변경되는 경우가 많기 때문에 이를 일일이 설정파일에 넣는데 한계가 존재하며 이러한 문제를 해결 하기 위해서 프로메테우스는 서비스 디스커버리 를 사용하는데, 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링 하는 형태이다.
1. 쿠버네티스 컨테이너를 실행하는 하드웨어 호스트, 즉 노드에 대한 지표 모니터링이 필요하다.
쿠버네티스는 노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링이 필요하다.
2. 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 서비스 디스커버리 (Service discovery)를 사용한다.
모니터링 대상 목록을 유지하고 있고, 대상에 대한 IP나 기타 접속 정보를 설정 파일에 주면, 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보를 읽어온다. 오토스케일링을 많이 사용하는 클라우드 환경이나 쿠버네티스와 같은 컨테이너 환경에서는 모니터링 대상의 IP가 동적으로 변경되는 경우가 많기 때문에 이를 일일이 설정파일에 넣는데 한계가 존재하며 이러한 문제를 해결 하기 위해서 프로메테우스는 서비스 디스커버리 를 사용하는데, 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링 하는 형태이다.
1. K8S 모니터링 시스템
- 시스템을 운영하는데 있어서 운영 관점에 있어서 가장 중요한 기능 중의 하나는 시스템에 대한 모니터링
- 시스템 자원의 사용량이나 에러 등에 대한 모니터링을 통해서 시스템을 안정적으로 운영하고 문제 발생시 원인 파악과 대응 가능
- K8S 기반의 시스템 모니터링 대상
가. 리소스: 리소스 모니터링은 클러스터와 어플리캐이션 헬스를 이해하기 위해 필수적
나. 디스크: 임계치는 클러스터 사이즈와 상관이 없기 때문에, 디스크 사용량을 모니터링 하는 것은 디스크 볼륨을 모니터링 하는 것 보다 더 효율적
다. CPU: CPU모니터링은 kube-state-mertics를 통해 가능하며 시스템, 사용자 사용량과 iowait 또한 모니터링 가능
라. 메모리: 메모리 모니터링 또한 kube-state-merics에서 가능하며 메모리 사용량 확인 가능
마. Pod: Pod Deployment의 헬스는 K8S가 제대로 작동하는지 확인
사. 네트워크: 네트워트 대역폭
2. K8S 모니터링 시스템 : 4가지 계층
2-1. 노드(호스트)
- K8S 컨테이너를 실행하는 HW 호스트, 즉 노드에 대한 지표 모니터링이 필요
- 노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링
2-2. 컨테이너
- 노드에서 기동되는 각각의 컨테이너에 대한 정보
- 컨테이너의 CPU, 메모리, 디스크, 네트워크 사용량 등을 모니터링
2-3. 애플리케이션
- 컨테이너 안에서 구동되는 개별 애플리케이션의 지표를 모니터링
- 컨테이너 기동되는 애플리케이션의 응답시간, 에러 빈도 등을 모니터링
2-4. K8S
- 컨테이너를 컨트롤 하는 K8S 자체에 대한 모니터링
- K8S의 자원인 서비스나 Pod, 계정 정보 등
* 모니터링 아키텍처
1. 프로메테우스 기반 모니터링 아키텍처
- 프로메테우스는 SoundCloud에서 개발된 모니터링 툴
- '16년에 CNCF에 오픈소스 프로젝트 기부
- 프로메테우스의 주요 기능으로 시계열 데이터를 저장할 수 있는 다차원 데이터 모델과 이 데이터 모델을 효과적으로 활용할 수 있는 PromQL이라는 쿼리 언어
- 수집대상을 정적으로 설정할 수 있고 Service Discovery 를 통해서 동적으로 설정하는 것도 가능
- 데이터 저장은 디스크에 저장하는 것도 가능하지만 외부 스토리지에 저장하는 것 가능
- (프로메테우스 서버) 시계열 데이터를 수집해와서 저장하는 메인 컴포넌트
- (클라이언트 라이브러리) 애플리케이션을 개발할 때 프로메테우스에서 데이터를 수집
- (pushgateway) 클라이언트에서 직접 프로메테우스로 데이터 전송시 송신
- (exporter) 프로메테우스를 클라이언트 라이브러리를 내장해서 만들어지지 않은 애플리케이션들에서 데이터를 수집
- (AlertManager) 알람을 보낼 때 알람의 중복처리,그룹핑 등과 알람
2. 데이터 수집 부분
- 기본적으로 프로메테우스는 데이터 수집을 Pulling 모델을 사용
- 모니터링 대상이 되는 자원이 지표 정보를 프로메테우스로 보내는 것이 아니라 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽는 모델을 사용
- 모니터링 대상이 프로메테우스의 데이터 포멧을 지원할 경우 바로 읽어올 수 있고 만약에 지원하지 않는다면 별도의 에이전트를 설치해서 지표를 읽어올 수 있는데, 이를 exporter라고 함
- mysql, nginx, redis와 같은 패키지는 미리 개발된 export가 있어서 다양한 서비스의 지표까지 쉽게 수집 가능
- 프로메테우스 클라이언트 라이브러리를 사용하게 되면 바로 지표를 프로메테우스 서버로 전송 가능
- push gateway가 지표를 보관하고 있다가 프로메테우스 서버가 Pulling을 하면 저장된 지표 정보를 리턴
----------------------------------------------------------------------------------------
*모니터링 시스템 구축
1. 서비스 디스커버리 : 모니터링 대상 목록을 유지하고 대상에 대한 ip나 기타 접속 정보를 설정 파일에 주면 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보 수집 / 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링하는 형태 / DNS나 Consul, etcd와 같은 다양한 서비스 디스커버리 서비스와 연동을 통해서 자동으로 모니터링 대상의 목록 수집 가능
2. azure_sd_configs / consul_sd_configs / dns_sd_configs / ec2_sd_configs / openstack_sd_configs / file_sd_configs / gce_sd_configs / kubernetes_sd_configs
3. 저장 및 시각화
- 수집된 지표 정보들은 프로메테우스 내부의 시계열 DB에 저장
- 프로메테우스 웹 콘솔을 이용하여 시각화 되거나 또는 API를 외부에 제공해서 Grafana와 같은 시각화 툴을 통해서 지표를 시각화
4. 알림 서비스
- 부가 기능 중의 하나로 alerting 컴포넌트는 지표에 대한 규칙을 설정하고 규칙을 위반할 경우에는 알림을 보낼 수 있는 기능
- 알림을 보내는 대상은 이메일이나 pagerduty와 같은 notification 서비스 등과 연동 가능
----------------------------------------------------------------------------------------
*K8S 연동 아키텍처
1. 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 Service Discovery 메커니즘 필요
2. K8S API를 호출하고 자원들의 목록(Pod, Node, Service, Ingress, Endpoint 등)의 목록을 Label Selector를 이용하여 수집
3. 수집된 모니터링 대상에 대해서 모니터링 수행
4. K8S는 apiServer에서 /metric 이라는 URL을 통해서 기본적인 지표 정보를 리턴
5. K8S 자원들에 대한 모니터링은 api를 통해서 수집
시스템을 운영하는데 있어서 운영 관점에 있어서 가장 중요한 기능 중의 하나는 시스템에 대한 모니터링이다.
K8S 기반의 시스템 모니터링 대상은 리소스, 디스크, CPU, 메모리, Pod, 네트워크 등이 있다.
K8S 시스템 모니터링 4가지 계층은 노드(호스트), 컨테이너, 애플리케이션, 쿠버네티스로 구성된다.
----------------------------------------------------------------------------------------
*** 쿠버네티스 보안
계정인증
네트워크 정책
Pod Security Policy
Security Context
1. 쿠버네티스는 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템이 없다.
반드시 별도의 외부 계정 시스템을 사용해야 하며 외부계정시스템의 형태로 지원하며 OAuth나 구글 계정(Google Account)이나 오픈스택의 키스톤(keystone)과 같은 계정 연동 방식을 지원한다.
2. 쿠버네티스는 클러스터 내부에 가상네트워크를 구성해서 사용하는데, 이때 kube-proxy 이외에 네트워킹 관련한 애드온을 사용한다.
AWS, 애저, 구글클라우드같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 사용하지 않아도 된다. 쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려고 하려면 네트워킹 관련 애드온을 설치해서 사용해야 한다. 네트워킹 애드온의 종류는 10개가 넘을 정도로 다양하게 있다. ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Falannel, Multus, NSX-T, Nuage, Romana, Weave Net등이 있고, OCI의 CNI(Container Network, Interface) 를 구현하고 있다면 다른 애드온들도 사용할 수 있다.
----------------------------------------------------------------------------------------
*계정인증
- 계정체계를 관리함에 있어서 사람이 사용하는 사용자 어카운트와 시스템이 사용하는 서비스 어카운트 두 가지 개념을 제공
1. 일반적인 사용자
- 일반적인 사용자는 우리가 일반적으로 생각하는 사용자 아이디의 개념
- 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템이 없음
- 반드시 별도의 외부 계정 시스템을 사용해야 하며 계정 시스템 연동을 위해서 OAuth나 구글계정(Google Account)이나 오픈스택의 Keystone과 같은 계정 연동 방식을 지원
2. 서비스 아카운트
- 직접 관리하는 사용자 계정
- 클라이언트가 K8S API를 호출하거나 콘솔이나 기타 클라이언트가 K8S API를 접근하고자 할 때는 이는 실제 사용자가 아니라 시스템
3. 인증(Authentication) 방법
- Basic HTTP Auth : HTTP 요청에 사용자 아이디와 비밀번호를 실어 보내서 인증하는 방식
- Access token via HTTP Header : 일반적인 REST API 인증에 많이 사용되는 방식
- Client cert : 클라이언트의 식별을 인증서(Certification)을 이용해서 인증하는 방식
- Custom made
4. 권한 관리(Authorization)
- 권한 처리 체계는 기본적으로 역할기반의 권한 인가 체계
- ABAC(Attribute-based access control)와 RBAC(Role-based access control) 2가지 방법 제공
4-1. ABAC
- 단어의 의미 그대로 속성 기반의 권한 관리
- 사용가능한 속성으로는 일반적으로 사용자, 그룹, 요청경로, 요청동사 등 외에도 네임스페이스, 자원 등으로 설정
4-2. RBAC
- 역할 기반권한 관리
- 사용자와 역할을 별개로 선언한 다음에 그 2가지를 Binding해서 사용자에게 권한을 부여
- 서버에 접근할 필요없이 kubectl이나 api를 이용해서 관리하는 것이 가능
----------------------------------------------------------------------------------------
*** 네트워크 정책 개념
- Pod그룹에 대해, 서로간 또는 외부 네트워크 엔드포인트와의 통신여부를 결정하는 정책
- 네트워크 정책으로 Pod간 통신, 네임스페이스간 통신, 포트 번호 지정 등을 서술적으로 설정할 수 있음
- NetworkPolicy 리소스들은 Pod들을 선택하고 선택된 Pod들에 허용되는 트래픽을 특정하는 규칙을 정의하기 위해 레이블을 사용함
- 네트워크 정책들은 네트워크 Provider가 제공하는 네트워크 플러그인을 통해 실현됨.
*** 네트워크 정책
1. Ingress 트래픽 컨트롤 정의
- ipBlock : CIDR IP 대역으로, 특정 IP대역에서만 트래픽이 들어오도록 지정
- podSelector : label을 이용하여, 특정 label을 가지고 있는 Pod들에서 들어오는 트래픽만 수신 가능
- namespaceSelector : 특정 namespace로 부터 들어오는 트래픽만 수신 가능
- Protocol & Port : 받을 수 있는 프로토콜과 허용되는 포트를 정의
2. Engress 트래픽 컨트롤 정의
- Engress 트래픽 컨트롤은 ipBlock과 Protocol & Port 두 가지만 지원
- ipBlock : 트래픽이 나갈 수 있는 ip 대역을 정의
- Protocol & Port : 트래픽을 내보낼 수 있는 프로토콜과 포트를 정의
----------------------------------------------------------------------------------------
* 네트워킹 에드온
- K8S는 클러스터 내부에 가상네트워크를 구성해서 사용하는데, 이때 kube-proxy 이외에 네트워킹 관련한 에드온을 사용
- AWS, Azure, Google Cloud 같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 에드온을 사용하지 않더라도 각 클라우드 벤더에서 구현되어 있음
- 쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려고 하려면 네트워킹 관련 에드온을 설치해서 사용해야함
- 네트워킹 애드온의 종류는 ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Flannel, Multus, NSX-t, Nuage, Romana, WeaveNet 등이 있고, OCI의 CNI(Container Network Interface)를 구현하고 있다면 다른 애드온들도 사용 가능
----------------------------------------------------------------------------------------
* Security Context
- Pod나 컨테이너에 대한 접근제어 설정이나 특수 권한을 설정하는 기능을 제공
- Pod 또는 컨테이너의 권한부여, 환경설정 접근을 정의하는 SecurityContext 필드
- Pod 또는 컨테이너 내의 securityContext 필드는 컨테이너 프로세스들이 사용하는 사용자(runAsUser)와 그룹(fsGroup), 가용량, 권한 설정, 보안 정책(SELinux/AppArmor/Seccomp)을 설정하기 위해 사용됨
- 런타임 UID, GID를 포함함
----------------------------------------------------------------------------------------
* Pod Security Policy
- SecurityContext는 컨테이너나 Pod의 보안 기능을 정의
- Pod Security Policy는 보안 기능에 대한 정책을 정의
- Pod 생성/업데이트에 관한 세밀한 권한인증 제공
- Pod 스펙에 대한 보안적 측면을 통제하는 클러스터-수준 리소스
- PodSecurityPolicy 객체는, 관련 필드들에 대한 기본값들을 포함하여, Pod가 시스템 내로 받아들여지기 위해 구동될 때의 조건들 집합을 정의함
- Pod 보안정책 통제는 선택적인 입장 승인 컨트롤러로서 구현됨
----------------------------------------------------------------------------------------
* K8S는 계정 체계를 관리함에 있어서 일반적인 사용자 계정과 시스템이 사용하는 서비스 계정 두 가지 개념을 제공한다.
* 네트워크 정책 정책은 Pod 그룹에 대해 서로간 또는 외부 네트워크 엔드포인트와의 통신여부를 결정하는 정책이다.
* K8S의 Pod나 컨테이너에 대한 접근 제어 설정이나 특수 권한을 설정하는 기능을 제공하는데 이를 Security Context라고 한다.
* SecurityContext는 컨테이너나 Pod의 보안 기능을 정의하고 Pod Security Policy는 보안 기능에 대한 정책을 정의한다.
