Kubernetes 공부 - 기초
1. Object에 대해서
Pods 란?
: 하나 이상의 컨테이너 그룹.
: 공유 컨텍스트 위에서 여러 컨테이너가 작동함. (하나의 Host를 공유한다고 보면 됨!)
: 재생성 될 때마다 IP가 변경된다. (외부로부터 접속 가능한 IP는 아님!! : 외부로부터 접속 가능한 IP는 Service를 통해야 한다.)
기본적으로 Pod는 쿠버네티스 클러스터 내부 IP를 통해서만 접근할 수 있다.
외부로부터 Pod에 접근 가능하도록 하려면, Service를 통해 노출시켜야만 한다.
컨테이너란?
도커를 생각하면 쉬울 듯! 도커를 실행하면 하나의 컨테이너가 작동.
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다
Deployments 란?
쿠버네티스의 컨트롤러! 어떤 식으로 앱을 배포를 Deployments를 통해 설정한다.
배포방식을 정의!
무중단배포.. 등등
Service란?
쿠버네티스에서 서비스는 파드의 논리적 집합과 그것들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. (때로는 이 패턴을 마이크로-서비스라고 한다.)
하나의 마이크로서비스 클러스터를 구분 짓고, 구분된 클러스터(논리적 집합)에 접근할 수있는 End-point를 제공한다. 라고 보면 될 듯!
Service 만들기는 도큐먼트 참고!
아래 3가지 서비스 타입을 외워두면 좋을 듯.
- ClusterIP : 클러스터 내부에서만 접속 가능. 노드를 통해서 로드밸런싱이 가능. 디버깅.. 등등 Pod 관리용
- NodePort : 클러스터 내부에서만 접속 가능. Pod로 접속하면 Service로 리다이렉트해서 정해진 룰에 따라 분산시키는 방식. 내부망 연결, 데모 등에 사용 가능.
- LoadBalancer : 외부로부터 접속 가능. 하지만 ExternalIP를 위한 별도의 플러그인이 필요하다.
핵심 포인트는 아래의 옵션을 통해 외부로 노출을 선언할 수 있다는 것!
--type=LoadBalancer
Replication Contorller, ReplicaSet
: Pod들의 리커버리, 스케일링을 담당
DeamonSet
: 하나의 노드에 하나의 Pod만 돌아가는 것을 보장한다
: Pod 별 성능 상태 감시 앱, 로깅앱 등등..
CronJob
: CronJob! 특정 작업 완료 후에 종료되어야 하는 Pod의 동작을 담당
Label
: 목적에 따라 오브젝트를 분류. 오브젝트에 따라 따로 연결하기 위해서 사용
사용 목적에 따라 등록해놓으면 간편하게 Pod관리가 가능하다.
pod.yaml의 metadata.labels/* 에 지정을 해놓으면 service.yaml의 spec.selector/* 로 지정해서 노출시키는 역할인듯!
Node Schedule
: Pod를 어느 노드에 올릴지 선언
Volumn
- emptyDir : 하나의 노드내에서 모든 Pod들이 공유 가능한 저장 공간. 하지만, Pod가 삭제되면 emptyDir도 초기화된다. 고로, 메모리에 저장해놓을만한 단기적인 데이터만 저장하는 용도로 쓸 것.
파드 생성시 마운트해서 사용. - hostPath : 마찬가지로 노드내에서 모든 Pod들이 공유 가능한 저장 공간. Pod가 삭제되도 영구적으로 유지된다. 하지만, 너무 많은 데이터를 저장해두는 것은 메모리관리에 좋지않기 때문에 주의할 것.
파드 생성시 마운트해서 사용. - PV/PVC
- PV : Persistent Volumn : 쿠버네티스 관리자가 제공하는 저장 공간.
- PVC : (유저용) 관리자에 의해 제공 받는 PV를 사용하기 위해 Persistent Volumn Claim이 필요!
이것도 Pod 생성시에 마운트 설정을 통해 지정한다.
ConfigMap, Secret
- ConfigMap
- 환경변수 설정을 위한 오브젝트.
- Secret
- Secret은 비밀번호와 같은 값 관리하기 위한 오브젝트.
base64 암호화된 값을 설정. - 메모리에 저장 (1Mbyte 제한)
- Secret은 비밀번호와 같은 값 관리하기 위한 오브젝트.
NameSpace, ResourceQuota, LimitRange
- NameSpace
- 리소스의 경계를 결정.
- ResourceQuota
- 리소스, 오브젝트에 대한 Quota를 설정
- LimitRange
- Pod, PVC에 대한 자원할당설정
2. 컨트롤러
- 다음과 같은 설정을 가능하게 한다.
- Auto Healing: 노드가 죽으면 다른 노드에 Pod를 생성
- Auto Scaling: 트래픽이 몰릴 때 자동으로 스케일링
- Deployment: 배포방식 설정
- Job: 일시적인 작업이 필요할 때 Pod 생성 후 삭제
- Pod-Controller도 Pod-Service와 같은 방식으로 결합. (label-selector)
ReplicaSet
- Template
- Auto Healing 부분을 담당.
- Replicas
- Auto Scaling 부분을 담당
- Selector
- matchLabels: 키와 벨류가 같은 겅유에 Pod를 연결
- matchExpressions: 벨류는 달라도 키 값이 특정한 값이면 모두 연결시키는 등의 설정이 가능.
- Exists, DoNotExist, In, NotIn 이 있음. 자세한 내용은 도큐멘트 참조
※ Replica 설정 변경하기
## Scaling 설정 간단하게 변경
kubectl scale --replicas=<number of pods> <type/name>
## ReplicaSet 설정 변경
kubectl edit rs/<name>
Deployment
- 배포 방식을 설정
- Recreate: 한번에 죽이고 다시 생성시키는 기본방식
- kubectl edit deploy/<name> 에서 이미지 버전만 바꿔주면 Recrate 방식 배포가 진행.
- 롤백은 kubectl rollout undo deployment <name> --to-revision=<revision number of ReplicaSet>
- RollingUpdate: 하나씩 교체해가면서 배포하는 방식
- Blue/Green: 새 버전의 Pods를 생성하고, 문제가 없을 때 플래그만 바꿔서 릴리즈하는 방식. 롤백이 쉽지만, 자원이 2배 필요함.
- ReplicaSet으로 pod를 생성하고, service가 보고 있는 pod 그룹(selector)을 교체하는 방식으로 진행
- Canary: 일부의 리퀘스트만 새 버전의 Pod로 보내면서 테스트 후 문제가 없을 때 기존의 Pods랑 교체하는 방식.
Ingress Controller 라는 것을 사용해서 트래픽 분배 설정 가능. 하는방법은 TBD
- Recreate: 한번에 죽이고 다시 생성시키는 기본방식
- 내부적을 ReplicaSet을 생성해서 AutoScaling을 담당하게 함.
Job, CronJob
- Job : 일시적으로 작업이 필요한 배치작업 등을 실행. 실행 후 해당 Pod를 종료시킴.
- CronJob : 주기적으로 Job이 실행되도록 컨트롤하는 역할.
- ConcurrencyPolicy
- Allow: 사전에 생성된 Job의 종료 여부와 상관없이 새로운 Job을 생성
- Forbid: 사전에 생성된 Job이 종료되지 않았다면, 다음 생성할 타임의 Job을 skip 한다.
- Replace: 사전에 생성된 Job이 종료되지 않았다면, 그 다음 생성할 주기에 Pod만 새로 생성해서 작업을 이어간다. Job이 끝났을 때에는 다음 주기에 Job을 새로 생성함.
- ConcurrencyPolicy
※ 참고: https://kubernetes.io/ko/docs/tutorials/
튜토리얼
운영 수준의 컨테이너 오케스트레이션
kubernetes.io
튜토리얼 진행하면서 깨달은 것들.
- 외부에서 클러스터 내부로 리퀘스트 테스트 등을 할 때 막힌다 -> Service 확인. 이건 백퍼센트 서비스에 문제다.
단, 서비스 확인하기 전에 Pod에 접속해서 Pod간의 통신에 문제가 없는지 확인할 것. 문제가 없으면 백퍼센트 Service 문제