대세는 쿠버네티스 섹션3

 

1. Pod

 

 

1) 컨테이너

-파드 안에는 하나의 독립적인 서비스를 운영할 수 있는 컨테이너가 있음

-컨테이너들은 서비스를 연결할 수 있도록 포트 번호를 가지고 있음

-한 컨테이너가 포트를 한 개 이상 가질 수 있지만, 한 파드 내에서 컨테이너들끼리 포트가 중복될 수는 없음 

-한 파드 내의 컨테이너들은 하나의 호스트로 묶여 있다고 볼 수 있음

-파드 내에서 다른 컨테이너로 접근할 시, 포트 번호를 통해 접근 가능

-파드 생성시 IP 주소 할당, 쿠버네티스 클러스터 내에서만 IP를 통해서 파드에 접근 가능 - 외부에서는 접근 불가능

-파드에 문제가 생길 경우 시스템이 파드를 삭제, 다시 재생성 -> IP 주소 삭제 ; IP주소는 휘발성을 가집

 

2) 라벨

-파드 뿐만이 아니라 모든 오브젝트에 다는 것이 가능 (파드에서 제일 많이 사용)

-라벨은 목적에 따라 오브젝트를 분류하고, 분류된 오브젝트들만 따로 골라서 연결하기 위함

-라벨의 구성:

key& value가 한쌍

-한 파드 내에 여러개의 라벨을 다는 것이 가능

-라벨을 통해 자신이 원하는 파드에만 접속할 수 있음

-사용 목적에 따라 라벨을 잘 달아 놓으면 해시태그처럼 사용가능

 

3) 노드 스케줄

-파드는 여러 노드들 중 하나의 노드에 올라가야 함

-내가 직접 노드를 선택하기 vs 쿠버네티스가 자동으로 지정해주기

 

(1) 직접 선택

- 노드에 라벨을 달고, 파드를 생성할 때 노드를 지정하기 

-파드 생성시 nodeSelector 항목에 노드의 라벨과 매칭되는 key value를 넣음

 

(2) 쿠버네티스가 자동으로

-노드에는 전체 사용 가능한 자원량이 있음

ex) 메모리와 CPU

-메모리: 파드에서 요구하는 메모리 양과 노드에 남은 메모리 양을 확인하고 지정

*사용량을 넣는 이유: 설정하지 않으면 파드 내의 앱에서 부하가 생길경우, 노드에 있는 자원을 사용하려고 할 것이고(무한정으로) 그렇게 되면 노드 내의 다른 파드들도 다 죽게됨

 

-각 자원에 대한 특성 때문에 메모리와 CPU가 다르게 작동; 메모리의 경우 초과되면 종료함

 

2. Service

1) Cluster IP

-서비스는 기본적으로 클러스터 IP를 가지고 있음

-서비스를 파드에 연결하면, 서비스 IP를 통해서도 파드에 접근 가능하게 함

*파드에도 클러스터 내에서 접근할 수 있는 IP가 존재 → 왜 굳이 서비스를 통해서 접근?

-파드는 쿠버네티스에서 장애 등으로 언제든지 죽을 수 있고, 죽으면 다시 재생성 되도록 설정되어 있는 오브젝트 

=> 파드 IP는 재생성시 변경됨 = 파드 IP는 신뢰성이 떨어짐

-서비스 IP는 사용자가 직접 지우지 않는 이상 삭제되거나 재생성되지 않음

-따라서 서비스 IP로 접근시, 항상 연결되어 있는 파드에 연결 가능 

-서비스 종류는 다양, 그 종류에 따라 파드에 접근하게 도와주는 방식에 차이가 존재

-그 중 가장 기본적인 방식이 cluster IP 

Cluster IP:

쿠버네티스 클러스터 내에서만 접근이 가능한 IP → 클러스터 내의 다른 모든 오브젝트들이 접근가능하지만, 외부에서는 접근 불가 (파드 내의  IP와 특징이 똑같음)

여러 파드들과 연결이 가능 →  여러 파드 연결시, 서비스가 트래픽을 분산시켜 파드에 전달해줌 

-사용시 type로 지정 가능, 그렇지만 기본값이 클러스터 IP라 이거 사용할거면 굳이 할 필요는 X

 

; 외부 접근이 불가능,  클러스터 내에서만 사용하는 IP → 

접근 가능 대상: 운영자(인가된 사용자)

주작업: 쿠버네티스 대시보드 관리 및 파드의 서비스 상태 디버깅

 

2) NodePort

-노드 포트 타입으로 만들어도 서비스에는 기본적으로 클러스터 IP가 할당됨 →  클러스터 IP와 같은 기능이 포함

-쿠버네티스 클러스터에 연결된 모든 노드에게 똑같은 포트가 할당, 외부로부터 어떤 노드든 그 IP의 포트로 접근할시 해당 서비스에 연결됨 →  서비스는 연결된 파드에 트래픽을 전달

-파드가 있는 노드에만 포트 할당이 아닌, 모든 노드에 포트가 만들어짐 

-각 노드에 파드가 하나씩 올라가 있는 상태에서 1번 노드의 IP로 접근하더라도 서비스는 노드2에 있는 파드에 트래픽 전달이 가능 →  서비스 입장에서는 어떤 노드에게서 온 트래픽인지 상관 없이, 자신에게 달린 파드들에게 트래픽을 전달만 해주면 되기 때문

*externalTrafficPolicy:Local = 특정 노드포트의 IP로 접근하는 트래픽은 서비스가 해당 노드 위에 올려진 파드에만 트래픽을 전달

 

물리적인 호스트의 IP를 통해서 파드에 접근, 대부분 호스트 IP는 보안적으로 내부망에서만 접근 가능하게 네트워크를 구성하므로 노드 포트는 클러스터 밖에는 있지만, 내부망 안에서 접근해야할 때 사용됨 

+) 데모나 임시 연결용으로도 사용 

 

3) Load Balancer

-노드 포트의 성격을 그대로 가져감

-로드 발란서가 추가, 각각의 노드에 트래픽을 분산 시켜주는 역할을 함

-로드 발란서에 접근하기 위한 외부 접속 IP의 주소는 개별적으로 쿠버네티스를 설치시 기본적으로 생성 X  별도로 외부접속 IP를 할당하는 플러그인이 필요함

 

로드 발란서는 실제적으로 외부에 서비스를 노출 시킬 때 사용, 내부 IP가 노출되지 않고 외부 IP를 통해서 안정적으로 서비스 노출이 가능

 

3. Voulme

1) emptyDir

-컨테이너들끼리 데이터를 공유하기 위해서 볼륨을 사용

-최초 생성시에는 볼륨 안이 비어있기 때문에 emptydir이라는 명칭이 붙음

-컨테이너 1이 웹 역할을, 컨테이너가 2가 백엔드 단을 처리하는 서버일 경우, 웹 서버로 받은 특정 파일을 마운트가 된 볼륨에 저장 →   백엔드 단에 있는 컨테이너 역시 볼륨을 마운트 하면 두 서버 간 볼륨을 각각의 로컬에 있는 파일처럼 사용

-두 컨테이너가 서로 파일을 주고 받을 필요 없이 편하게 사용이 가능

-볼륨은 파드 안에 생성, 파드 재생성시 데이터가 삭제됨 →  볼륨에 쓰이는 데이터는 일시적인 사용목적에 의한 데이터만 넣는 것이 바람직

-같은 볼륨(의 이름)을 지정했으면 마운트 패스의 경로는 달라도 ㄱㅊ

 

2) hostPath

-한 호스트, 파드가 올라간 노드의 패스를 볼륨으로 사용하는 것

-엠티 dir과 다른 점은 패스를 각각의 파드들이 마운트해서 공유, 파드가 죽어도 노드에 있는 데이터는 사라지지 않음

-만약 파드2가 죽어서 재생성될 경우, 꼭 해당 노드에 재생성이 되라는 보장은 없음 →  재생성되어서 다른 노드에 파드를 재생성할 수도 있음 = 이경우 파드가 볼륨에 마운트를 못함(자신이 있는 노드의 볼륨에만 마운트 가능) 

*똑같은 이름의 경로를 만들어서 직접 노드에 있는 패스끼리 마운트를 하면 해결할 수는 있음

-각각의 노드에는 각 노드 자신을 위해서 사용 되어야 하는 파일이 있음(시스템, 설정 파일 등) →  파드 자신이 할당되어 있는 호스트에 데이터를 읽거나 쓸 때 사용 

-호스트 패스는 파드가 생성되기 전에 만들어져 있어야 파드 생성시 오류가 나지 않음

-노드에 있는 데이터를 파드에서 사용하기 위한 용도

 

3) PVC / PV

-파드에 연속성있는 볼륨을 제공하기 위한 개념

-실제 볼륨들의 형태는 다양, 로컬 볼륨 or 외부 연결 볼륨

-이런 볼륨들은 각각 Persistent 볼륨을 정의한 후 연결

-파드는 PV에 바로 연결하지 않고 PVC를 통해서 연결을 진행  →  쿠버네티스는 볼륨 사용을 유저와 어드민 영역으로 나눔

-어드민은 쿠버네티스 운영자, 유저는 파드에 서비스를 만들고 배포하는 서비스 담당자

-볼륨의 종류가 많고 설정 방식 역시 개별적이다보니 볼륨을 관리하는 어드민이 PV를 생성하면 유저는 사용을 위해 PVC를 만듬

-storageClassName: "" = 현재 만들어진 PV 중에서 선택됨

 

4. ConfigMap, Secret

 

 

*ConfigMap, Secret 만들 때, 데이터로 상수/파일 넣을 수 있음 - 파일의 경우 환경변수가 아닌  볼륨을 마운트 해서 사용

 

1) Env(Literal)

-ConfigMap은 Key와 value로 구성 -> 필요한 상수를 정의하면 파드 생성시 컨피그맵을 가져와서 컨테이너 안의 환경변수에 셋팅 가능

-시크릿역시 보안적인 요소의 값을 저장(패스워드 등)

-시크릿은 밸류를 넣을 때 base64 인코딩을 해서 넣어야함

-파드 주입시에는 디코딩이 되어서 환경변수에서는 원래값이 보임

-시크릿은 메모리에 저장, 보안적 요소

-컨피그맵은 키밸류 리스트 무한히, 시크릿은 1MB

-시크릿 많이 만들면 시스템 자원에 영향을 줌

 

2) Env(file)

-파일을 통째로 컨피그맵에 넣을 수 있음 -> 파일 이름이 키, 내용이 밸류

-파드 환경변수에 넣을 때, 키를 새로 정의하여 컨텐츠만 넣음

: 마스터 콘솔로 들어가서 kubectl 명령어를 실행 

 

3) Volume Mount(File)

-파드 생성시 마운트 패스를 정의, 패스 안에 파일을 마운트

 

-환경변수 방식은 한번 하면 끝, 컨피그맵의 데이터 바뀌어도 환변에는 영향이 X
-파일 마운트는 마운트가 원본(컨피그맵)과 연결이므로 마운팅된 내용도 변경 

 

5. NameSpace, ResourceAuota, LimitRange

 

1) NameSpace

-한 네임스페이스 안의 같은 타입 오브젝트는 이름이 중복될 수 없음

-같은 파드의 이름 중복 당연히 안됨; 이름도 유호 ID같은 유일한 키 역할을 함

-타 네임스페이스의 자원과 분리되어 관리

-네임스페이스 안에는 서비스가 존재, 파드와 서비스 간의 연결을 파드에는 라벨 /  서비스에는 셀렉터로 연결

-네임스페이스 지우면 그 안의 자원도 삭제 됨

-타 네임스페이스의 같은 이름의 파드로 연결할 경우, 연결 가능하긴 함 

 

2) ResourceAuota

-네임스페이스의 자원 한계를 설명하는 오브젝트

-네임 스페이스에 제한하고 싶은 자원을 명시, 달 수 있음

-ResourceAuota가 설정된 네임스페이스에 파드를 만들 때, 파드는 무조건 스펙을 명시해야 함 →스펙이 없으면 네임스페이스에 만들어지지 않음

-자원 한계 이상으로 파드가 생성되지는 않음

-쿠버네티스의 업데이트와 함께 제한할 수 있는 오브젝트도 늘어나고 있음 → 제한시 어떤 버전에서 어디까지 가능한지 확인 필요

 

3) LimitRange

-각각의 파드마다 네임스페이스에 들어갈 수 있는지 자원을 체크

-min: 파드에서 설정되는 메모리의 limit 값이 1GB 가 넘어야 한다

-max: 파드에서 설정되는 메모리의 limit 값이 4GB를 초과할 수 없음

-maxlimitsreauestRatio: request값과 limits의 값이 설정한 비율 이상을 넘으면 안된다는 뜻 ex) 3이면 3배 이상이 안됨

-default & default request : 파드에 아무것도 설정하지 않았을 때, request 값과 limit 값이 여기에 선언된 값으로 설정됨