CKA-15일차

📍 CKA 15일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 174-185

---

174. Network Policy

• Ingress: 입구
• Egress: 퇴장
  
  

이제 쿠버네티스의 네트워크 보안을 살펴보자. 파드와 서비스 세트를 호스팅하는 노드 집합의 클러스터가 있다. 노드마다 IP 주소가 있고 파드마다 서비스도 존재한다.

쿠버네티스 네트워킹의 전제조건
1. 어떤 솔루션을 구현하든 파드가 서로 통신할 수 있어야 한다.

이 네트워크 솔루션에서 모든 파드가 가상 사설 네트워크에 있고 IP나 파드 이름 또는 서비스 이름을 통해 쿠버네티스 클러스터 내 노드를 가로지르며 기본값으로 서로에게 닿을 수 있다.
쿠버네티스는 기본값으로 모든 허용 규칙과 함께 구성된다. 클러스터 내의 어떤 파드나 서비스가 서로에게 접근할 수 있다.

우리는 파드를 통해 앱의 각 구성요소(프론트엔드 웹 서버, 백엔드 API 서버, DB)를 배포한다.
이전 슬라이드에서 논의했듯이 기본적으로 쿠버네티스 클러스터 내에서 세 개의 파드는 서로 통신할 수 있다.
이때, 프론트엔드 웹 서버가 데이터베이스 서버와 직접적으로 통신하는 것을 막기 위해서 Network Policy가 필요하다.

Network Policy은 쿠버네티스 네임스페이스에 있는 또 다른 객체로 파드, 레플리카 셋이나 서비스 처럼 하나 이상의 파드에 네트워크 정책을 연결한다.

이 경우에는 3306 포트 API 파드에서만 Ingress 트래픽을 허용한다. 일단 이 정책이 생성되면 파드의 모든 트래픽을 차단하고 지정된 규칙에 부합하는 트래픽만 허용한다.

replicaset이나 service를 파드와 matchlabels, labels를 통해 링크하는 동일한 기술을 사용한다.

policyTypes에 트래픽이 Ingress인지 Egress인지를 명시하고 규칙을 지정한다.

Network Policy의 정의 파일은 다음과 같다.
이 Network Policy는 진입 트래픽만 격리되고 퇴장 트래픽은 영향이 없다.

네트워크 정책은 네트워크 솔루션에 의해 실행된다. 모든 네트워크 솔루션이 네트워크 정책을 지원하는 것은 아니다.
네트워크 정책을 지원하는지 확인하기 위해 공식 문서를 항상 참조해보길 권한다.
네트워크 정책을 지원하지 않는 솔루션으로 구성된 클러스터에서도 정책을 만들 순 있지만 강요되는 것은 아니다.

---

175. Developing network policies

백엔드 API 파드를 제외한 다른 소스로부터 데이터베이스 파드로의 트래픽을 허용해서는 안된다.

만약 들어오는 트래픽을 허용하면 그 트래픽에 대한 응답이나 회신이 자동으로 허용된다. 그래서 응답, 회신에 대한 것은 따로 규정하지 않아도 된다.

다음과 같이 네트워크 정책 정의 파일을 작성할 수 있다.
이렇게 작성하면 api-pod를 제외하고 DB 파드로 가는 모든 트래픽을 차단할 수 있다.

네트워크 정책은 기본으로 metadata에 지정된 namespace에 있는 파드(지정된 파드와 동일한 네임스페이스에 있는 파드)만 지정할 수 있다.
만약 다른 네임스페이스의 파드에 도달하고 싶다면 namespaceSelector 영역에 네임스페이스를 지정해주면 된다.

podSelector 없이 namespaceSelector만 지정할 수도 있다.
그럴 경우, 지정한 네임스페이스 내의 모든 파드만 데이터베이스 파드에 도달할 수 없다.

클러스터 외부에서 데이터베이스 파드에 접속할 수 있도록 네트워크 정책을 구성할 수 있다.
ipBlock 영역을 통해 IP 주소를 지정하면 해당 IP의 개체가 DB 파드에 접근할 수 있다.

정리하자면 특정한 파드, 네임스페이스, ip 주소를 지정하기 위해 podSelector, namespaceSelector, ipBlock 영역을 사용하면 된다.
이러한 것들은 개별적인 규칙으로 통과될 수도 있고 하나의 규칙의 일부로 함께 통과될 수도 있다.

이 예제에서는 두 가지 규칙이 있다.
podSelector와 namespaceSelector가 함께 적용되어 첫 번째 규칙이 만들어지고 ipBlock을 통해 두번째 규칙이 만들어진다.

만약 namespaceSelector 앞에 대시를 추가해 규칙을 분리할 수 있다.
첫 번째 규칙은 podSelector에 의해 api-pod와 일치하는 모든 파드가 허용된다.
두 번째 규칙은 namespaceSelector에 의해 prod 네임스페이스 내의 어떤 파드에서든 트래픽이 허용된다.
세 번째 규칙은 파드이든 백업 서버이든 특정 IP를 가진 개체를 허용한다.

반대로 DB 파드에서 백업 서버로 푸쉬해야 한다면 데이터베이스 파드에서 외부 백업 서버로 네트워크를 허용해야 한다.
policyTypes에 Egress를 추가하고 데이터베이스 파드에서 외부 백업 서버로 통신을 허용하는 egress 규칙을 추가해야 한다.

---

177. Kubectx and Kubns - Command line Utilities

• kubectx: kubernetes contexts 사이에서 kubectl config 명령어를 사용하지 않아도 된다. 이 도구는 클러스터들 사이의 전환하는데 도움을 준다.
  
  

• kubens: 네임스페이스 간에 빠르게 전환할 수 있도록 돕는 명령어이다.
  

---

178. Solution - Network Policies

network policy 조회

Network Policy 생성하기

---

181. Storage in Docker

도커의 저장소 종류는 2가지가 있다.

---

182. Volume Driver Plugins in Docker

시스템에 docker를 설치하면 /var/lib/docker/에 생성된다. 하위 폴더로 도커와 관련된 여러 개의 폴더들이 생긴다. 여기가 docker가 기본값으로 모든 데이터를 저장하는 곳이다. 여기서 데이터란 docker 호스트에서 실행되는 이미지 및 컨테이너와 관련된 파일들을 말한다.

docker는 Layered architecture로 이미지를 구축한다. Dockerfile의 각 지시사항 줄은 docker 이미지에 새 레이어를 만든다. 각 레이어는 이전 레이어의 변화만 저장한다.
두 번째 응용 프로그램을 빌드 할 때 처음 세 레이어는 같기 때문에 docker는 처음 세 레이어를 빌드하지 않는다. 대신 캐시에 있는 만든 첫 번째 응용 프로그램을 위해 만든 3개의 레이어를 재사용한다. 그래서 두 레이어만 새로 만들면 된다.
도커는 레이어 아키텍쳐를 통해 이미지를 더 빨리만들고 디스크 공간을 효율적으로 절약한다.

이미 빌드한 프로그램을 업데이트하는 경우에도 변경된 레이어만 재빌드하면 되기 때문에 재빨리 프로그램 이미지를 재구축할 수 있다.

이 모든 도커 이미지 계층은 최종 도커 이미지를 형성하기 위해 docker build 명령을 실행할 때 생성된다.
빌드가 완료되면 레이어의 내용물을 수정할 수 없다. 읽기만 할 수 있고 변경하기 위해서는 새로 만들어야(re-build) 한다.

이 이미지에 기반을 둔 컨테이너를 실행할 때 docker run 명령을 사용하면 docker는 이 레이어들에 기반을 둔 컨테이너를 만들고 이미지 레이어 상단에 글을 쓸 수 있는 새 레이어를 만든다.
쓰기 가능한 레이어는 컨테이너에 의해 생성된 데이터를 저장하는 데 사용된다. 예를 들어 응용 프로그램이 작성한 로그 파일이나 컨테이너에 의해 생성된 임시 파일같은 거이다.

상단의 글을 쓸 수 있는 레이어는 컨테이너가 살아있는 동안만 유지된다. 컨테이너가 파괴되면 이 레이어와 그 안에 저장된 모든 데이터도 파괴된다.

동일한 이미지 레이어는 이 이미지를 이용해 생성된 모든 컨테이너가 공유한다는 것을 기억해야 한다.

만약 컨테이너를 실행한 후 이미지 레이어의 일부인 소스 코드를 수정한다면, 컨테이너는 수정하려는 소스 코드 파일을 저장하기 전에 Read Write 계층(Container Layer)에 파일 복사본을 자동으로 만들고 Read Write 계층의 다른 파일 버전을 수정하게 된다.
이것을 COPY-ON-WRITE 메커니즘이라고 한다.

이미지 레이어를 읽는다는 것은 이미지 레이어의 파일들이 수정되지 않으며 변하지 않는다는 것을 의미한다. 그래서 이미지는 docker build 명령을 통해 이미지를 재구축하기 전까지 항상 동일하다.

컨테이너를 없애면 컨테이너 레이어에 저장된 모든 데이터도 삭제된다.
컨테이너에서 생성된 데이터를 저장하고 싶다면 영구적인 볼륨을 추가하면 된다.

docker volume create 명령어를 통해 볼륨을 생성할 수 있다. 해당 명령어를 실행하면 /var/lib/docker/volumes 폴더에 볼륨이 생성된다.
그런 다음 docker run 명령을 실행할 때 '-v {볼륨 이름}:{컨테이너 내부 경로}' 옵션을 통해 생성한 볼륨과 컨테이너 내부를 마운트할 수 있다.

아래 예시에서는 data_volume 볼륨을 생성하고 생성한 데이터 볼륨을 컨테이너 안의 /var/lib/mysql 경로에 마운트했다. 그래서 데이터베이스가 작성한 모든 데이터는 docker host에 생성된 볼륨에 저장된다. 컨테이너가 파괴되어도 데이터는 살아 있다.

만약 기본 경로인 /var/lib/docker/volumes 대신 docker host 외부 저장소에 데이터를 저장하고 싶다면 docker run 명령어를 실행할 때 '-v {외부 저장소 경로}:{컨테이너 내부 경로}'를 지정하면 된다.

마운팅에는 두 종류가 있다. 볼륨 마운팅,바인드 바운트이다.

• 볼륨 마운팅: 볼륨 디렉터리에서 볼륨 마운트
• 바인드 마운트: 호스트의 어떤 위치에서든 디렉터리 마운트

'-v' 옵션을 사용하는 방식은 옛날 방식이다. 지금은 '--mount' 옵션을 사용한다.
'--mount type={type},source={호스트 경로},target={컨테이너 내 경로}' 이와 같이 사용한다.

Storage Driver는 레이어드 아키텍처를 유지하고 writable 레이어를 생성하고 레이어를 가로질러 파일을 이동해 복사와 쓰기를 가능하게 한다.
스토리지 드라이버를 선택하는 것은 OS 사용에 따라 달라진다. 가령, Ubuntu의 기본 저장소 드라이버는 AUFS이다.
Docker는 운영체제에 근거해 자동으로 사용 가능한 최고의 저장소 드라이버를 선택한다. 스토리지 드라이버마다 다른 성능과 안정성 특성을 제공한다.

---

Volume Driver Plugins in Docker

지난 강의에서 배웠듯이 Storage Driver는 이미지와 컨테이너의 저장소를 관리하도록 돕는다. 또한 저장소를 유지하기 위해서는 볼륨을 만들어야 한다.
볼륨은 Storage Driver에 의해 처리되지 않는다. 볼륨은 볼륨 드라이버 플러그인으로 처리된다. default 볼륨 드라이버 플러그인은 Local이다.
로컬 볼륨 플러그인은 docker host에 볼륨 생성을 도와 데이터를 /var/lib/docker/volumes 디렉터리 아래에 저장한다. 타사 솔루션에서 볼륨을 생성할 수 있도록 다양한 볼륨 드라이버 플러그인들이 제공된다.

예를 들어, docker run 명령어를 실행할 때 AWS EBS에서 볼륨을 공급하기 위해 특정 볼륨 드라이버를 선택할 수 있다.
이렇게 하면 컨테이너가 생성되고 AWS 클라우드에서 볼륨을 부착할 수 있다. 컨테이너가 파괴되더라도 데이터는 클라우드에 안전하게 저장된다.

---

183. Container Storage Interface(CSI)

과거 쿠버네티스는 Docker만을 컨테이너 런타임 엔진으로 사용했고 docker와 관련된 모든 코드가 쿠버네티스 소스 코드에 내장되어 있었다.
Rocket과 CRI-O와 같은 다른 컨테이너 런타임 엔진이 도입될 때 쿠버네티스 소스 코드에 의존하지 않고 다양한 컨테이너 런타임에 대한 지원을 확장하는 것이 중요했다.
그래서 Container Runtime Interface(CRI)가 탄생했다.

CRI는 쿠버네티스와 같은 오케스트레이션 솔루션이 도커와 같은 컨테이너 런타임과 어떻게 통신할지 정의하는 표준 인터페이스이다.
앞으로 새로운 컨테이너 런타임 인터페이스(CRI)가 개발되더라도 CRI 표준을 따르기만 한다면 쿠버네티스 소스 코드를 건드리지 않고 쿠버네티스와 통신할 수 있다.

마찬가지로 다양한 네트워킹 솔루션에 대한 지원을 확장하기 위한 컨테이너 네트워킹 인터페이스(CNI)가 존재한다. CNI 표준에 기반하여 네트워크 플러그인을 개발하고 쿠버네티스와 동작하도록 할 수 있다.

컨테이너 저장소 인터페이스(CSI)는 다중 저장소 솔루션을 지원하도록 개발되었다. CSI 덕분에 쿠버네티스에서 작동할 스토리지 드라이버를 직접 선택할 수 있다.

CSI는 쿠버네티스에 한정된 기준이 아니다. CSI 표준에 따라 구현된다면 컨테이너 오케스트레이션 툴에서도 동작 가능하다.
CSI는 원격 프로시저 호출(RPC, Remote Procedure Call)의 집합을 정의한다. CSI 표준에 맞게 스토리지 드라이버가 반드시 구현되어야 하고 오케스트레이터는 CSI 표준을 따른 스토리지 드라이버를 호출할 수 있다.

---

185. Volumes

컨테이너로 처리하는 데이터는 도커의 볼륨에 담겨서 영구적으로 보존된다.

쿠버네티스에서는 어떻게 동작할까?
도커와 마찬가지로 쿠버네티스에서 생성된 파드도 일시적으로 존재한다. 파드가 데이터를 처리하고 삭제되면 파드가 처리한 데이터도 함께 삭제된다.
파드에 볼륨을 부착하면 파드에서 생성된 데이터가 볼륨에 저장된다. 파드가 삭제된 후에도 데이터는 볼륨에 남아있다.

단일 노드에선 다음과 같이 볼륨을 설정할 수 있다.

그러나 호스트의 경로 옵션을 통해 볼륨 스토리지를 설정하는 방식은 권장되지 않는다.
파드는 모든 노드에서 /data 디렉터리를 사용하기 때문에 모두 동일한 데이터를 갖고 있지 않기 때문이다.
이를 보완하기 위해서 쿠버네티스는 다양한 유형의 저장소 솔루션을 지원한다.