kubernetes
master : master, controller
- kubectl : 쿠버네티스 클러스터에 명령을 내리는 역할을 한다. api-server와 주로 통신한다.
- api-server : 쿠버네티스 클러스터의 중심 역할을 하는 통로, 주로 상태 값을 저장하는 etcd와 통신하며 그 밖의 요소들도 api 서버를 중심에 두고 통신한다. 컨트롤 플레인의 프론트 엔트. 외부 사용자와 상호 통신
- key value store(etcd) : 클러스터 데이터베이스를 백업하기 위해 사용하는 데이터베이스. 마스터는 노드, pod, 컨테이너들의 상태 정보를 파악하기 위해 etcd 에게 쿼리한다
- 컨트롤러 매니저 : 실제로 클러스터를 실행, 하나의 컨트롤러는 스케줄러를 참조하여 정확한 수의 포드를 실행. 포드에 문제가 발생하면 다른 컨트롤러가 이를 감지하고 대응. 서비스를 포드에 연결하므로 요청이 적절한 엔트포인트로 이동. 계정 및 API 액세스 토큰 생성
- 스케줄러 : 클러스터 상태가 양호한가? 새 컨테이너가 필요하다면 어디에 배치할까? CPU 또는 메모리와 같은 포드의 리소스 요구 사항과 함께 클러스터 상태 고려
node(worker) :
- kubelet : 컨트롤에서 노드에 작업 요청시 kubelet 가 작업 실행
- 컨테이너 런타임 : 파드를 이루는 컨테이너 실행을 담당한다.
- kube-proxy : 각 컴퓨팅 노드에는 k8s 네트워킹 서비스가 용이하도록 네트워크 프락시인 kube-proxy 가 기능한다. 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신 처리,
- pod가 외부와 통신하고 싶으면 kube-proxy가 대신 user와 통신한다.
- 퍼시스턴트 스토리지 : 사용자가 기본 스토리지 인프라에 관한 상세 정보를 몰라도 리소스 요청 가능
Pod에 볼륨 마운트하기
- 정적인 방법 : NFS 볼륨을 파드에 직접 마운트 하기
- 개발자와 운영자가 1명(개발자이면서 운영자 & nfs, iscsi가 무엇인지 알고 있는 사람)인 경우
container: - name: test-container image: nginx volumeMounts: - name: nfs-vol mountPath: /remote volume: # 외부에서 제공되는 볼륨의 모든 정보를 알고 있어야 컨테이너에 연결 가능하다. - name: nfs-vol nfs: server: 1.1.1.1 path: /shard
- 동적인 방법 : 볼륨에 대한 정보를 정확히 알 수 없는 경우 (PV(Persustent Volume)/PVC(Persustent Volume claim))
- PV
- 제공할 수 있는 볼륨의 정의하여 PV Pool에 담는다.
- 용량(1GB), accessmode(readwriteonce)- 1대1로의 연결(다른 사용자는 사용할 수 없다.),
- accessmode(readwritemany[shard]) - 1대N로의 연결,
- reclaimpolicy
- PV와 PVC가 연결된 상태에서 해제되었다면 생성된 PV를 어떻게 할 것인가?
- retain(남겨둔다)
- Delete(데이터를 포함하여 볼륨 삭제)
- Volume 요청에는 PVC 를 사용한다. 여기서는 Accessmode / 최소 용량 을 작성한다
K8S vs Swarm mode
- 애플리케이션의 배포 단위
- Pod vs Container
- Pods -> 1개 이상의 컨테이너
- k8s에서의 가장 작은 단위
- 언제라도 죽을 수 있는 존재이다. 예) scale 조정, 롤링 업데이트와 같은 경우 기존 파드를 죽이고 새로운 파트가 생성된다.
- 따라서 하나의 파드에서 데이터를 영구적으로 관리하는 것이 매우 어렵고 특정 파드로 지속적으로 접근하는 것도 사실상 거의 어렵다.
- 컨테이너들이 ip, port, 리소스를 공유한다.
- side car - back up, log
- Deployment로 Pod를 배포하면 nginx-blue-5d5w4d 형태로 배포된다.
- Statfulset로 Pod를 배포하면 nginx-blue-0, nginx-blue-1 형태로 배포된다.
K8S 기본 object
- 기본 오브젝트는 4가지가 있다.
- Pod
- 쿠버네티스에서 실행되는 최소 단위, 즉 웹 서비스를 구동하는데 필요한 최소 단위이다.
- 독립적인 공간과 사용 가능한 IP를 가지고 있다.
- 1개의 pod는 1개 이상의 container를 가지고 있기 때문에 여러 기능을 묶어 하나의 목적으로 사용 가능하다.
- namespace
- 리소스 구분하여 관리하는 그룹, 작업 공간, 다양한 여러 프로젝트가 진행되는 경우 별도의 네임 스페이스를 사용하여 프로젝트를 진행할 수 있다.
- 특별히 지정하지 않으면 default가 할당된다.
- 쿠버네티스에서 사용되는 kube-system
- 온프레미스에서 쿠버네티스를 사용할 경우 외부에서 쿠버네티스 클러스터 내부로 접속하게 도와주는 컨테이너들이 속해 있는 metallb-system이 있다.
- volume
- 파드가 생성될 때 파드에서 사용할 수 있는 디렉터리를 제공한다.
- 기본적으로 파드는 영속되는 개념이 아니라 제공되는 디렉터리도 임시로 사용한다.
- 파드가 사라지더라도 저장과 보존이 가능한 디렉터리를 볼륨 오브젝트를 통해 생성하고 사용할 수 있다.
- service
- 파드 접속을 안정적으로 유지하도록 서비스를 통해 내/외부로 연결된다.
- 서비스는 새로 파드가 생성될 때 부여되는 새로운 IP를 기존에 제공하던 기능과 연결해 준다.
- 기존 인프라에서 로드밸런서, 게이트웨이와 비슷한 역할을 한다.
- 그 외 object
- 디플로이먼트, 데몬셋, 컨피그맵, 레플리카셋, PV, PVC, 스테이트풀셋 등이 있다.
- 그 외 object - Deployment
- 디플로이먼트는 파드에 기반을 두고 있으며, 레플리카셋 오브젝트를 합친 형태이다.
- 그 외 object - ConfigMap, Secret
- 도커 이미지는 빌드 후 불변의 상태를 갖기 때무에 설정 옵션을 유연하게 변경할 수 없다.
- YAML 파일과 설정값을 분리할 수 있는 것이 configmap, secret
- ConfigMap
- 설정 정보를 저장해놓는 일종의 저장소 역할, 키/밸류 형식으로 저장
- 일반적인 환경 설정 정보나 CONFIG정보를 저장하도록 디자인
- Secret - 비밀키 등
- 보안이 중요한 패스워드나, API 키, 인증서 파일들은 secret에 저장
- configmap, secret 은 둘다 포드내에서는 clear text 로 보여진다. 단, 노드간 통신에서 secret은 노출되지않는다.
- 그 외 object - ingress
- 고유한 주소를 제공해 사용 목적에 따라 다른 응답을 제공할 수 있고, 트래픽에 대한 L4/L7 로드밸런서와 보안 인증서를 처리하는 기능을 제공한다.
- 인그레스를 사용하려면 인그레스 컨트롤러가 필요하다.
- 앞 서비스는 로드밸런서 뒤에 서비스는 노드 포트를 이용하여 연결한다.
LB ----> ingerss controller -----> ingress(rule) -----> node port svc(service) -----> Pod
Deployment update
- recreate
- 새로운 파드가 추가되기 전에 모든 이전 파드가 한 번에 중지됩니다.
- Rolling Update
- 새로운 파드가 점진적으로 추가되고 이전 파드가 중지됩니다.
- 새 버전의 인스턴스로 트래픽이 이전되기 전까지 이전 버전과 새 버전의 인스턴스가 동시에 존재할 수 있다는 단점이 있지만, 시스템을 무중단으로 업데이트 할 수 있다는 장점이 있습니다.
- 무중단 배포란 서버를 실제로 서비스할 때 서비스적인 장애와 배포에 있어서 부담감을 최소화하고, 서비스가 중단되지 않도록 배포하는 기술이다.
클라우드
- 멀티 테넌시란 다수의 테넌트(사용자)가 하나의 공간에 모여 있다.
- 클라우드 컴퓨팅에서는 서로 다른 고객이 서버 리소스를 나누어 사용하는 공유 호스팅을 멀티테넌시라고 부르기도 한다.
- 멀티 테넌시의 반대 개념인 단일 테넌시에서는 소프트웨어 인스턴스 또는 컴퓨터 시스템 하나에 최종 사용자 또느 사용자 그룹이 하나만 있다.
- tennent -> poject -> namespace
