2020.12.02
pod내에 서비스가 준비가 되었는지
이후에 장애가 발생이 되었는지 점검하는 probe
Method 3가지
Method에 대한 결과로
서비스 객체가 LB역할을 하는데 ep가 준비되지 않았는데 Client가 요청하는 문제를 probe를 사용해서 해결 할 수 있다.
데몬셋, 스테이트풀셋 컨트롤러
디플로이먼트 컨트롤러 = 스테이트리스 프로세스를 배포하기 최적한 컨트롤러
롤링업데이트를 통해 도커를 수정할 수 있다.
도커 이미지 변경 할 수 있는 3가지 방법
set
edit
apply : 기존 리소스가 있더라도 업데이트 수행. upsert 한다
Ondelete :
제로 다운타임 서비스 : 롤링업데이트
Recreate는 중단이 잠시 발생 할 수 있음
롤링업데이트 관련된 작업 명령들
롤링업데이트 의 맥스서지, 맥스언어베일러블 설정가능
롤링업데이트 블루/그린 배포하기
블루/그린 : 새로운 버전 선 생성 -> 서비스의 Selector를 바꿔 lable 바라보는 값 스위치
볼륨
데이터 공유
영구적 저장
etcd 메소드 설정을 디커플링 방식으로 제공
메타데이터 정보 제공
다양한 볼륨형태
1. pod 내에 공유하는 방법 (컨테이너간에 공유하는 방식)
emptyDir : pod 삭제되면 함께 삭제되는 백앤솔루션
2. pod 외부 공유하는 방법
서로다른
3가지 타입
NFS
디커플링메소드 (pod 명세서안에 정의하지 않는다. 외부 명세서로 관리한다.) : PV, PVC
PV
PV와 바인딩된 PVC를 어떻게 할것이냐?
PV와 연결된 백앤스토리지를 어떻게 할것이냐?
Retatin 보존
Delete 삭제 (클라우드 환경의 EBS 사용할때 보안을 위해 Delete 정책 주로 사용한다)
ReCycle 재사용
볼륨모드
파일시스템 : Pod 내에 컨테이너에서 직접 연결
Raw Block
NODE 기준으로 Access Mode 가 동작한다
Once
Many
PVC
조건에 부합하는 PV를 스케쥴링해서 1:1 맵핑에서 사용할 수 있다.
PVC를 통해서 바인딩이 되면 Pod 에서 사용한다.
pod 내에 컨테이에서는 마운트포인터를 지정해서 사용한다.
백엔솔루션으로
Pod 안에 프로세스가 파일을 저장하면 PV와 마운트된 저장소에 최종 저장된다.
Raw Block
PV 쪽에서는 Block 모드 지정
PVC 에서는 Block 모드로 요청
Pod에서는 Device path를 지정한다. 3박자
Dynamic Provisioning 방식사용해서 스토리지 클래스를 사용한다.
스토리지 클래스 예문
어노테이션에 디폴트로 설정가능
SC를 다양하게 디파인한다. (sc1, sc2, sc3
PVC에 개발자들이 스토리지클래스 네임을 지정하면
sc 생성
pvc 생성 -> 요청
pv
실제로 디바이스가 생성됨
ConfigMaps
Secrets
어플리케이션의 동작 방식을 바꿀수 있다. 디커플링 방식으로 제공 ConfigMaps, Secrets
볼륨형태로 해당 Pod 내에 도커 이미지를 사용하여 Start된 상태에서 리소스는 key, value 형태
Secrets : 민감한 데이터를 베이스64로 인코딩해서 제공
ConfigMaps
생성방식 3가지
환경변수
configMap
volume 통해 파일로 전달
Secrets
DB를 pod로 배포를 할 때 즉, DB를 설치할때 아이디/패스워드 민감한 데이터 설정시
네임스페이스를 생성하면 디폴트 Secrets이 생성됨
Secrets의 마운트에 접근하여 정보도 확인 했음.
Scheduler
taint : node레벨에서 설정하는것
각각 워커노드에 특정 taint를 설정하게 되면
taint가 설정된 녀석을 피해서 일반적인 노드에 접근한다.
taint만 설정된 녀석만 붙도록 설정할 수 있다 -> Toleration
Toleration
그렇다 하더라도 node에 머물수 있도록 설정가능
그렇다면 일정 시간 동안 node에 머물수 있도록 설정가능
kubectl drain -> NoExecute 방식
kubectl cordon -> NoSchedule 방식
Pod 레벨의 Toleration
을 통해서 특정 GPU가 설정된 곳에만 POD가 머물수 있도록 스케쥴 설정가능
키
벨류
오퍼레이터
이펙트
설정을 해준다.
2020.12.03
Service 와 DNS Record
1.Headless (SRV)
2.ClusterIP (A)
• --external_ip= 지정 => 인바운드 인터페이스로 활용된다.
• Service가 L4 역할을 한다.
• Ingress Controller(L7 역할) : 서비스 관문을 만들어준다.
기본은 내부의 pod 끼리 서비스를 연동. 하나의 노드안에서 통신
외부 서비스와 연동해야 한다? external_ip 등록한다.
3.NodePort (A)
• 서비스 객체를 즉시 NodePort 타입으로 변경가능 : 각각 맴버노드에 NodePort가 할당된다.
• 포트는 동일하고, 인바운드 트래픽이 kube proxy에 의해 분산된다. (rule chain 기반)
• Clinet 도메인으로 요청 -> DNS에 의해 라운드로빈으로 분산된다.
모든 노드에서 받을 수 있도록 랜덤 노드포트가 생성되어 외부에서 들어오는 요청을 다 받을 수 있다.
4.LoadBalancer (A)
• 클라우드 환경에서 ELB와 LB를 연동한다.
• ELB에 FQDN이 등록된다.
클라우드 환경에서 싱글엔드포인트 방식으로 내부에서는 NodePort 트래픽을 태워 내부 노드들에게 보낸다.
5.ExternalName (CNAME)
Ingress Controller : 여러 도메인을 내부 서비스와 연결을 통합해서 관리하는 LB 역할을 한다.
'클라우드 컴퓨팅 & NoSQL > k8s' 카테고리의 다른 글
RBAC (0) | 2020.12.06 |
---|---|
HPA 설정 (0) | 2020.12.06 |
AutoScaling (0) | 2020.12.06 |
monitoring 구축 (0) | 2020.12.06 |
Monitoring (0) | 2020.12.06 |