Primes's Infra Tech

이전 학습에서 PVC, PV에 대해 학습했다. PV를 생성하기 위해서는 물리적인 디스크 저장소가 생성되는 것이 먼저이다. App 이 저장소를 요구하게 되면, 가장 먼저 물리 디스크가 프로비저닝 되어야 하고 그 다음 PV 정의파일 을 통해 파드에 할당하여 App 이 사용할 수 있게끔 해야한다. 이렇게 Storage 를 확보하고 PV 정의 파일을 생성하는 과정을 정적 프로비저닝(Static Provisioning) 이라고 한다. App이 용량을 요구할 때, 자동으로 볼륨이 프로비저닝 되도록 돕는 것이 Storage Class 이다. 강의의 예시에서는 PV를 GCP(구글 클라우드 플랫폼) 에서 구성하는 것으로 진행한다. PV를 생성하기 전, 구글 클라우드에서 디스크 리소스를 생성한다. 디스크 생성 후, PV를..

CSI - Container Storage Interface 컨테이너 저장소 인터페이스는 쿠버네티스가 현재 사용하고 있는 런타임 엔진이다. 과거에는 Docker를 통째로 사용했지만, 확장성을 위해 Container Runtime Interface(CRI)를 개발하게 되었다. CRI는 도커와 같은 Container Runtime과 오케스트레이션 솔루션이 어떻게 통신할 지 정의하는 인터페이스이다. CRI가 있음으로써 다른 새로운 컨테이너 런타임 엔진이 도입되어도, 해당 엔진이 CRI 표준을 따른다면 쿠버네티스에 바로 적용을 할 수 있다. Container Networking Interface(CNI) 표준도 있는데, 이를 따르는 네트워킹 솔루션은 쿠버네티스에 바로 적용이 가능하다. 마지막으로, 이번에 학습할..

Storage in Docker 쿠버네티스의 스토리지 구조를 알아보기 전, 그 기초를 이루는 도커의 스토리지 구조에 대해 먼저 학습한다. 도커의 스토리지는 2가지로 나뉜다. Storage Drivers / Volume Drivers 강의에서는 Storage Driver를 다룬다. docker를 처음 설치하면 설치된 경로는 /var/lib/docker 에 저장된다. 해당 경로 하위 폴더들에 도커의 모든 데이터가 저장된다. 도커는 이미지를 구축할 때, Layered architecture로 구축한다. dockerfile 내 각 명령어들은 docker이미지에 새 레이어를 생성한다. (FROM Ubuntu = Layer 1) 각 레이어들은 이전 레이어에서의 변경 사항을 저장해나간다. 이러한 구조로 인해, 비슷한..

네트워크 기본, 기초 부분은 알고있으니 지나간다. 네트워크 트래픽은 인, 아웃 트래픽에 대해 규칙을 설정해둬야 제대로 흐를 수 있음을 인지하면 된다. 쿠버네티스의 네트워크 부분의 보안을 알기 위해서 위 사항을 기억해두자. 쿠버네티스의 네트워킹의 전제조건 중 하나는 "어떤 솔루션을 구현하더라도 파드가 서로 통신할 수 있어야 함" 이다. 경로 설정과 같은 추가적인 설정 없이 통신이 가능해야 한다. 모든 파드는 IP, 파드 이름, 서비스 이름을 가지고 클러스터 내에서 노드에 관계없이 파드간에 통신에 애로사항이 없어야 한다. 하지만 위와 같은 상황을 예로 들면, 웹서버와 DB서버가 직접적으로 통신은 가능하지만 보안상의 요구로 인해 직접 통신은 불가하게 구성하길 원하면 어떻게 해야 하는지 알아본다. 이러한 경우에..

Security in Docker 쿠버네티스의 보안에 대해 알기 전, Docker의 보안에 대해 이해하고 넘어간다. 컨테이너는 호스트 OS와 격리되어 운영되는 구조가 아니다. 컨테이너는 OS에서 namespace를 이용해 격리된다. 컨테이너와 호스트는 같은 커널을 공유한다. 즉, 컨테이너에서 실행되는 프로세스는 호스트에서 실행되지만 고유의 namespace 공간에서 실행된다. 네임스페이스 내 리소스는 다른 네임스페이스에서는 볼 수 없다. ps aux 명령어를 통해 도커 컨테이너 목록을 확인할 수 있다. 여기서 PID 도 확인이 가능한데, 네임스페이스 내에서는 다른 네임스페이스의 프로세스를 확인할 수 없어 PID가 1로 보인다. 하지만 호스트에서 ps aux 명령어를 사용하면 모든 namespace의 컨테..

쿠버네티스의 계정은 두 유형으로 나뉜다. 사용자가 사용하는 사용자 계정과, 컴퓨터가 사용하는 서비스 계정이 있다. 사용자 계정 : 관리 작업을 수행하기 위해 클러스터에 액세스하는 관리자, 프로그램 배포를 위해 클러스터에 액세스하는 개발자가 사용 서비스 계정 : 프로그램이 k8s 클러스터와 상호작용 시 사용하는 계정 서비스 계정의 예로, 프로메테우스와 같은 모니터링 툴과 젠킨스와 같은 자동화 빌드 툴들이 서비스 계정을 활용한다. 어플리케이션이 쿠버네티스 API를 사용하려면 인증이 필요하다. 이 때 요구되어지는 것이 서비스 계정이다. kubectl create serviceaccount dashboard-sa 위 명령어로 서비스 계정 생성이 가능하다. 계정이 생성되면 토큰도 자동으로 생성된다. 해당 토큰은 ..

이제까지 쿠버네티스 내 인증에 대한 부분을 계속 학습하였다. 이제는 클러스터 내에서 인증을 어떻게 활용하는지 알아보자. 클러스터 관리자는 모든 종류의 작업을 수행할 수 있다. 배포 또는 파드 추가 및 삭제, 노드 관리 등의 작업을 모두 할 수 있다. 하지만 다른 관리자들도 모두 클러스터에서 위와같은 작업을 전부 수행할 수 있어서는 안된다. 각 사용자는 업무에 맞는 권한만을 가져야 한다. 각 관리자의 계정마다 접근 권한을 조정하여 제어할 수 있도록 해야한다. 쿠버네티스는 4가지의 인증 메커니즘을 지원한다. Node Authorizer / ABAC (Attribute Based Access Control) / RBAC(Role Based Access Control) / Webhook 하나씩 알아보자. 1. ..

앞서 학습을 하면서, 클러스터 내에서 어떤 작업을 하든 모든 명령은 kube-apiserver를 타고 간다는 것을 알았다. 쿠버네티스 API는 사용 목적에 따라 그룹화된다. /version : 클러스터 버전 확인 /metrics, healthz : 클러스터 상태 모니터링 /logs : 다른 로그와 통합할 때 사용 위 4 그룹을 제외하고, /api, /apis가 중요하기 때문에 별개로 학습한다. 해당 api는 core 그룹과 named 그룹 2가지로 분류된다. 여기서 핵심적인 기능들은 core 그룹에 속한다. namespaces, pods, nodes 등 중요 리소스들이 여기에 들어간다. named 그룹은 좀더 조직화 되어있고, 새로 추가되는 기능들은 named 그룹에 속하게 된다. API Groups >..

앞서 인증 과정을 학습하면서, 클러스터 내에서 인증서 파일이 어떻게 활용되는지 확인하였다. 클러스터 내 접속을 하기 위해서는 매번 인증이 유효한지와 같은 체크를 kubectl 명령어를 사용하여 진행해야 하는데, 이를 매번 입력하는 것은 어려운 일이다. 따라서 kubeconfig 이라는 구성 파일을 통해 명령을 모아 명시해둔다. 기본적으로 kubectl 도구는 아래 경로 내의 config 파일을 찾는다. $HOME/.kube/config 따라서 해당 경로에 kubeconfig 파일이 있기 때문에 kubectl 명령에 대해 별도로 옵션을 지정하지 않아도 되었었다. kubeconfig 파일은 3가지 영역으로 나뉜다. Clusters / Contexts / Users 세 영역으로 나뉜다. Clusters : 액..

이제까지 클러스터 관리자로써, 클러스터 내 통신 시 TLS 보안이 어떻게 적용되고 이 때 인증 과정이 어떻게 이루어지는지 확인하였다. 이 인증서는 CA(Certificate Authority) 기관이 보증한다는 것을 학습하였고, CA 서버가 인증서를 발급해줌을 확인하였다. 또한 앞서 관리자는 클러스터에 접속하기 위해서는 인증서와 개인키가 필요하다는 것을 학습했다. 그렇다면, 새로운 관리자가 클러스터에 접속하기 위해서는 어떻게 해야 하는가? 새로운 인증서와 키 쌍을 발급해서 줘야한다. 새로운 관리자는 개인키를 생성하여 인증서 서명 요청을 작성하여 기존의 관리자에게 보낸다. 기존 관리자는 인증서 서명 요청을 CA 서버로 가져가 CA 서버의 개인키와 루트 인증서를 통해 서명하고, 새로운 관리자에게 다시 돌려보..