GOORM: Kubernetes-46

1. Facts 
   : 배운것 - 클러스터 네트워킹 구성 / 쿠버네티스 DNS
   
   
2. Findings
   :
   도커 컨테이너의 네트워킹 이해
    - 호스트 네트워크 네임스페이스/디폴트 네트워크 네임스페이스 : 호스트의 기본 네트워크 생성
    - 컨테이너 네트워크 네임스페이스 : 컨테이너를 생성할 때마다 만들어지고 컨테이너마다 별도의 네트워크를 사용할 수 있도록 함
    - 네트워크 네임스페이스 : 서로 연결되기 전까지는 독립적으로 동작
    - 베스 : 컨테이너, 호스트의 브리시에 연결해서 호스트 네임스페이스와 컨테이너 네트워크 사이를 통신
    - 브릿지 타입 : 호스트에 브리지를 만들고 컨테이너와 호스트는 베스를 이용해서 연결
    -  오버레이 타입 : 여러 대 호스트가 있을 때 각 호스트에 있는 컨테이너 네트워크를 오버레이 네트워크로 연결
    - 맥브이랜 타입 : 컨테이너에 MAC 주소와 IP 주소를 할당
    - 호스트 타입 : 호스트의 네트워크 네임스페이스를 직접 사용
    - 링크 타입 : 이미 생성되어 있는 네트워크 네임스페이스에 컨테이너를 연결
   
   쿠버네티스 DNS
    - 클러스터 안에서만 사용하는 DNS 설정 가능
    - 클라이언트나 API 게이트웨이가 호출할 서비스를 찾는 서비스 디스커버리 용도로 사용 가능
   
   kube-dns의 질의 구조
    - kubedns 컨테이너 : 쿠버네티스 마스터를 바라보다가 서비스나 엔드포인트의 변경 사항이 있으면 메모리에 저장 중인 DNS 데이터 변경
    - sidecar 컨테이너 : kubedns와 dnsmasq 컨테이너에 헬스 체크를 실행
    - dnsmasq : kube-dns 파드에 도메인 이ㅡㅁ을 질의했을 떄 원하는 결과를 찾을 수 없으면 사용자 정의 DNS에 질의
   
   CoreDNS의 질의 구조
    - 모듈 형식으로 파드 안에 coredns라는 컨테이너 하나만 있다.
    - 플러그인으로 새롱누 기능을 추가할 수 있는 유연한 구조
    - Corefile이라는 CoreDNS 자체의 형식에 맞춰서 DNS 설정
   
   

<수업 메모>

 

쿠버네티스에서의 데이터 저장
- 컨테이너가 유지되는 동안만 유지

볼륨의 필요성
- 데이터를 유지
- 데이터를 공유
 
볼륨의 종류
- emptyDir : 데이터 공유가 목적 ( 동일한 파드의 컨테이너 끼리 )
	    디스크 / 메모리 선택
	    데이터는 따로 저장되지 않음
	    git-repo 볼륨의 기능을 구현할 수 있음
	    ( initContainer 를 사용해서 데이터 복제 후 볼륨으로 공유해서 사용 )

- hostPath : 도커의 볼륨과 유사
	   호스트의 특정 디렉토리를 지정해서 마운트
	   데이터를 저장 / 공유 가능
	   동일한 호스트에서만 사용 가능
	   설정하는 타입에 따라 디렉토리/파일 자동 생성 (데이터 공유 불가)
		-> 노드셀렉터 / 노드어피니티 등의 설정 필요

- NFS : 파드 자체에 nfs서버를 구성하거나 별도의 nfs 서버를 구성
	-> 실제 사용할 파드에서 네트워크를 통해 마운트해서 사용하는 방식
	모든 파드에서 동일한 데이터 공유 가능

- PV / PVC : 사용자의 편의성을 위해 볼륨 설정과 요청 설정을 구분
	    파드/컨트롤러 에서 설정하는 마운트 대상을 PVC 로 지정
	    파드와 별개의 라이프사이클
	    프로비저닝 -> 바인딩 -> 사용 -> 반환
	    별개의 스토리지에 데이터를 저장
		-> 노드 이동 또는 파드 재생성 등에 영향 X
	    PV / PVC 는 1대1 연결이므로 PVC 삭제 시 해당 PV는 사용 불가 ( PV 재생성 후 데이터 재사용 가능 )

- 동적 볼륨 : 기존의 방식들은 수동으로 볼륨을 생성
	     개발자(사용자)들이 요청할 때마다 관리자가 직접 볼륨 생성 후 전달
	     스토리지 클래스(sc) 리소스를 정의
	     개발자가 PVC 를 생성해서 스토리지 요청 시 SC 에 의해 자동으로 PV 배포
	     사용자 입장에서 스토리지에 대한 지식이 없어도 상관없이 사용 가능
		-> PVC 에서 SC 이름만 지정해주면 PV 까지 자동 생성 

실습 가이드
1. NFS 서버 구성
2. 해당 공유 디렉토리에 파일 생성
3. 스토리지 클래스 작성
	https://kubernetes.io/ko/docs/concepts/storage/storage-classes/#nfs 참고
4. PVC 작성 ( 위 SC 호출 )
5. PV 생성 확인
6. 파드 배포 후 파드에 볼륨 연결상태 및 데이터 확인



클러스터 네트워킹 구성
1. 도커 컨테이너의 네트워크
- 브릿지 (기본) : 	컨테이너와 호스트를 브릿지 인터페이스를 통해 연결(veth)
		컨터이너끼리 통신 및 외부와의 통신까지 가능
- 오버레이 : 호스트가 여러 대 일 경우 사용
- 맥브이랜 : 인터페이스에 MAC주소를 추가 설정 ( 컨테이너 )
	    시스템 성능 저하 및 보안에 취약
	    대신에 브릿지타입 보다는 전달 속도가 빠름 
- 호스트 : 호스트의 네트워크 스택을 그대로 사용



2. 쿠버네티스의 네트워크
- 파드에 IP 주소를 할당해서 접근성을 높였다.
- 컨테이너의 포트 관리가 용이해졌다.
- 파드 하나에 여러 컨테이너 동작
- 여러 노드에서 파드가 동작
- 파드에서 기본적으로 링크 타입의 네트워크 사용
- 파드 내의 컨테이너들이 공통적인 인터페이스를 사용
- pause 컨테이너에서 해당 인터페이스를 제공
	( -> pause 컨테이너 문제 발생 시 네트워크 연결 문제 발생 )
	내부에 컨테이너가 여러 개 라도 하나의 변하지않는 IP 주소가 할당

- 멀티노드 방식의 쿠버네티스 환경에서의 네트워크
- 각각의 노드에서 동작하는 파드들이 사용하는 주소(veth) 가 다르게 구성
- 서로 다른 주소 정보를 라우팅 규칙으로 정의
- CNI 를 통해 이러한 기능을 제공
- CNI : 	Container Network Interface 의 약자
	컨테이너 상의 네트워크 연결 표준
	사용하는 플러그인의 통칭
	대표적인 종류로 플라넬 / 칼리코 / 실리엄 등

쿠버네티스 서비스 네트워크
- 실질적으로 파드 접근 시 서비스를 통해 접근
- 서비스 생성 시 해당 파드에 대한 NAT 규칙 생성
- iptables 에 NAT 규칙 추가
	=> 위 2가지 작업을 kube-proxy 에서 수행


쿠버네티스 DNS
- 쿠버네티스는 기본적으로 클러스터 내부용 DNS 서비스를 제공
- 이전 버전에서는 kube-dns 로 제공했으나 지금 (v.1.11 이후)은 coreDNS 로 기능 제공
- 내부적인 도메인 이름은 "서비스이름.네임스페이스이름.svc.cluster.local" 형태로 구성
						(클러스터이름)
			"파드IP주소.네임스페이스이름.pod.cluster.local"
- 파드 생성 시 dnsconfig 항목을 설정하면 DNS 서버 정보 설정 가능