GOORM: Kubernetes-44

1. Facts 
   : 배운것 - 인증과 권한관리 / 볼륨
   
   
2. Findings
   :
   TLS (Transport Layer Security)
    - kube-apiserver와 통신할 때의 기본 인증 방법
    - 통신할 때 오가는 패킷을 암호화
    - 서버뿐만 아니라 클라이언트가 유효한지도 검증하는 기능이 있다.
    - kuber-apiserver에 있는 인증서와 연결되는 클라이언트 인증서를 이용해 접속
   
   권한관리
    - ABAC(Attribute-based access control) : 속성 기반의 권한 관리 , 사용할 수 있는 속성에는 사용자, 그룹, 요청경로, 요청 동사 등이 있다. 구너한을 변경하려면 직접 마스터에 접속해서 파일을 변경한 후 kube-apiserver 컴포넌트를 재시작해야하므로 관리하기 번거롭다
    - RBAC(Role-based access control) : 역할 기반 권한 관리로 대부분의 권한 관리 시스템에서 많이 사용. 사용자와 역할을 별개로 선언한 후 두 가지를 조합해서 사용자에게 권한을 부여. 마스터에 접근할 필요 없이 kubectl 이나 API를 이용해 관리
   
   롤
    - 특정 API나 자원 사용 권한들을 명시해둔 규칙의 집합
    - 일반 롤 : 해당 롤이 속한 네임스페이스에만 적용. 추가로 네임스페이스에 한정되지 않은 자원과 API들의 사용 권한을 설정
    - 클러스터 롤 : 특정 네임스페이스 사용 권한이 아닌 클러스터 전체 사용 권한을 관리
    - 롤바인딩 : 롤과 사용자를 묶는 역할로 특정 네임스페이스 하나에 적용
    - 클러스터롤바인딩 : 클러스터롤과 사용자를 묶는 역할로 한번 설정했을 때 클러스터 전체에 적용
   
   볼륨
    - 컨테이너를 재시작하더라도 데이터를 유지
    - 퍼시스턴트볼륨 : 데이터를 저장했던 노드가 아닌 다른 노드에서 컨테이너를 재시작하더라도 데이터를 저장한 볼륨을 그대로 사용할 수 있도록 한다.
    - emptyDir : 파드가 실행되는 호스트의 디스크를 임시로 컨테이너에 볼륨으로 할당해서 사용. 파드가 사라지면 emptyDir에 할당해서 사용했던 볼륨의 데이터도 함께 사라진다.
    - hostPath : 파드가 실행된 호스트의 파일이나 디렉터리를 파드에 마운트
    - nfs(network file system) : 기존에 사용하는 NFS 서버를 이용해서 파드에 마운트. 여러 개 파드에서 볼륨 하나를 공유해 읽기/쓰기를 동시에 할 때도 사용
   
   
   

<수업 메모>

파드 스케줄링
파드 생성 시 파드 스케줄러를 통해 알맞은 노드를 선택
1. 노드 셀렉터 - 노드에 설정해둔 레이블을 확인하고 알맞은 노드를 선택

2. 노드 어피니티 - 	노드 셀렉터와 동일한 방식
		require / prefer 로 필수 또는 우선순위 설정이 가능

3. 파드 어피니티 / 안티어피니티
	기존의 파드를 포함해서 새로 만드는 파드를 모두 같은 노드에 배치 -> 어피니티
	기존의 파드를 포함해서 새로 만드는 파드를 각각 다른 노드에 배치 -> 안티 어피니티

4. 테인트 / 톨러레이션
	테인트 - 새로운 파드를 노드에 배치할 수 없게 설정 ( 예외 가능 )
	톨러레이션 - 테인트 값에 대해 일치하는 노드를 선택

5. 커든 - 새로운 파드를 배치할 수 없게 설정 ( 테인트와 달리 예외가 없음 )

6. 드레인 - 노드에서 동작 중인 모든 파드를 제거하고 다른 노드에서 재시작하도록 설정
		-> 단일 파드 / 로컬스토리지 사용 / 데몬셋 으로 구성된 파드 는 예외
        
인증과 권한 관리

인증 : 사용자 계정에 대한 확인

일반적인 사용자 계정 : 외부의 인증서비스를 통해서 사용하는 사용자
서비스 계정 : API 를 통해 관리하는 사용자	-> 주로 파드 동작에서 사용

기본적으로 설치 시 default 라는 이름의 서비스 계정 제공
해당 사용자의 토큰을 시크릿으로 저장
	-> 파드에서 해당 사용자를 사용

kubectl 명령어로 kube-apiserver 로 요청할 때에 인증은
~/.kube/config 파일의 정보로 인증

파일 구성
cluster	: 명령어를 전달할 대상(클러스터)에 대한 인증 정보
user	: 명령어를 사용하는 사용자에 대한 인증 정보
context	: 클러스터 / 사용자 / 네임스페이스 등에 대해 정의

명령어 사용 시 해당 파일을 통해
파일에서 정의해둔 사용자로 클러스터를 관리
(컨텍스트 활성화 필요)


인가 : 사용자가 작업을 할 때에 그 동작/대상 에 대해 권한이 있는지 확인


쿠버네티스에서 접근 제어를 위해서는 2가지 방식을 사용
1. ABAC ( Attribuet ) : 이전 방식. 
		컨트롤플레인(마스터)에 직접 접근해서 파일을 설정하는 방식
		1) 마스터 접근 가능
		2) kube-apiserver 재시작 필요

2. RBAC ( Role ) : 권한을 설정할 때 역할 기반으로 설정
	다양한 방식의 권한을 따로 설정하지 않고 묶어서 한 번에 설정하기 위해 사용 (편하게)

	Role / Role-Binding 
	Role : 권한들의 집합
	역할은 네임스페이스 단위로 접근제어 규칙을 설정
	클러스터롤은 클러스터 단위로 접근 제어 규칙을 설정
		-> 일반적인 규칙(rule) 또는 여러 규칙의 집합(aggregation)

	Role-Binding : 역할과 사용자와 연결
	일반 역할 연결 시에는 롤바인딩
	클러스터롤을 연결하려면 클러스터롤바인딩 사용


	설정 순서
	1) 사용자 생성
	2) 롤 생성
	3) 롤바인딩으로 사용자와 롤 연결설정
	4) ~/.kube/config 파일 직접 수정  또는  kubectl config 명령어로 수정
		-> 사용자/토큰 추가 , 컨텍스트 추가(클러스터이름/사용자이름) , 컨텍스트 변경
	5) 명령어 사용
    
데이터 저장
파드(컨테이너)의 데이터는 별도로 저장/관리 하지 않는다.
컨테이너를 삭제하면 데이터도 함께 삭제
컨테이너 삭제 후에도 보관되는 저장소

일반적인 컨테이너는 상태가 없다. ( 파드/레플리카셋/디플로이먼트 등)
	-> 정보까지 포함 ( 파드 이름, 파드 IP... )
	장점 : 컨테이너 문제 발생 시 자유롭게 재생성 가능
	단점 : 저장한 데이터 유실