일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- 화이트해커
- OpenID Connect
- 프로젝트
- 패시브스캐닝
- 넷크래프트
- OIDC
- 강의
- Mimikatz
- dnsenum
- 공격그래프
- NMAP
- Mac
- AttackGraph
- decap
- recon-ng
- davtest
- Chrome 작업관리자
- 액티브스캐닝
- airdecap-ng
- Shift + ESC
- 무선채널
- 계정 탈취
- 보안
- Kublet
- Social Network in Game
- ip forwarding
- SecurityMetric
- cgroups
- 대학원
- Container
- Today
- Total
네른
[Kubernetes] Health Check 본문
Kube는 Pod의 health check를 이용해서 컨테이너를 자동으로 재시작할 수 있음
- 크게 Liveness / Readiness/ Startup Probe라는 세 방식이 있음
- 세 Probe 모두 다음과 같은 방법을 이용할 수 있음
1) Command Probe
- 쉘 명령어를 수행하고, 결과값이 0이면 정상
livenessProbe:
exec:
command: ls -al
2) HTTP Probe
- HTTP Get 메소드를 이용해 응답이 200대 혹은 300대인경우 정상
livenessProbe:
httpGet:
path: /test
port: 8080
3) TCP Probe
- 지정된 컨테이너에 TCP 연결을 수행해서 성공한경우 정상
livenessProbe:
tcpSocket:
port: 8080
Liveness Probe
- 컨테이너의 동작 상태를 주기적으로 확인
- 만약 응답이 없는 경우 컨테이너를 kill 한 후 재시작하며, 이 때 재시작의 기준은 정책에 따라 다름
Readiness Probe
- 컨테이너가 시작되고 '준비되었는지' 주기적으로 확인함
- 만약 응답이 없는 경우 서비스의 엔드포인트에서 해당 Pod를 제외하고 사용 불가로 표기함
: 한 서비스에 여러개의 Pod가 연결된 경우, 한 Pod가 응답이없으면 해당 Pod만 서비스에서 제외
Startup Probe
- 컨테이너 내의 애플리케이션이 시작되었는지 확인
- 컨테이너가 실행되고 가장 먼저 동작하는 probe로, 실패한 경우에는 재시작 정책을 따름
위 Probe들을 이용하면 서비스의 안정적인 시작/재시작 혹은 업데이트를 적용시킬 수 있음
이 외에도, 롤링업데이트를 수행할 때에 가용성을 유지할 수도 있음
'DevOps' 카테고리의 다른 글
[Kubernetes] ConfigMap & Secret (0) | 2022.05.02 |
---|---|
[Kubernetes] Deployment & Rolling Update (0) | 2022.05.02 |
[Kubernetes] Kubernetes의 구조 - 컨트롤러 (0) | 2022.04.30 |
[Kubernetes] Kubernetes의 구조 - Master/Worker, 기본 오브젝트 (0) | 2022.04.30 |
[CI/CD] Gitlab-ci.yml 작성 예제 - Docker Image Push (0) | 2022.04.29 |