좋은 강의를 주시고 있으셔서 너무나도 감사한 마음으로 잘 듣고 있습니다. 그런데 궁금한 점이 이번 강의에서 하나 생겼습니다. 꽤 오랜 시간이 지난 영상이라 답변을 해 주실 수 있을지 모르겠네요. ** 궁금한 점: Restart 하는 시점이 예상과 좀 많이 달라서 이해가 안 됩니다.🥲 livenesProbe 내용을 다른 사람들처럼 정답과 같이 지정한 후, watch kubectl get pods -o wide 명령으로 계속 확인해 보고 있으면, 재시작 하는 타이밍이 제가 예상한 것과는 너무 다르네요. /tmp/healthy 파일 생성 이후 30초 동안 유지한후 제거되므로, 해당 컨테이너가 Running 상태가 되고 난후, 41~2초 정도 되었을 때 ls /tmp/healthy 명령 실패가 2회 넘어서 Restart가 이루어져야 할 것 같습니다. 이유는 periodSeconds가 5초, failureThreshold가 2회라서, sleep 30초 + period 5초 x failure 2회 체크 = 대략 40초라고 생각했습니다. 타이밍이 조금 안 맞다하더라도 50초 내외에는 Restart가 되어야 할 것 같았습니다. 하지만, 제 환경에서는 약 70초 정도가 지났을 때마다 Restart가 진행되는 것으로 파악됩니다. 혹시 제 예상과 다르게 동작하는 적절한 이유가 있을까요? 아니면 제가 잘못 이해하고 있는건가요? 답변 주시면 너무 감사하겠습니다. 그럼 새해 복 많이 받으시고 좋은 일만 가득하세요.
안녕하세요 선생님 좋은 강의 항상 감사드립니다. 궁금한 부분이 있는데요. Deployment 리소스에 의해 Pod가 자동 복구 되는 것과 livenessProbe에 의해 자동 복구되는 것에 어떤 차이가 있는걸까요? 큰 차이는 Self-Healing 대상인걸까요? 예를들면 Deployment의 경우 Node 장애시 Pod를 자동복구 시켜주는 것과 달리 livenessProbe 속성의 경우 Container를 자동 복구 시켜주는 것 이라던지요 또는 Deployment와는 달리 livenessProbe의 경우 헬스체크 옵션이 다양하다는 것에 있을까요? 그렇다면 kube-controller manager가 Pod의 개수를 보장하고 관리하는 역할을 수행하는 컴포넌트라면 Container를 관찰 및 모니터링을 수행하는 컴포넌트는 kubelet이라고 보면 될까요?
Deployment 리소스에 의해 Pod가 자동 복구 되는 것과 livenessProbe에 의해 자동 복구되는 것에 어떤 차이 1. Deployment는 파드의 갯수를 보장해주는 RS컨트롤러로 replicas 수를 늘리면 scale out 되는것이고 2. livenessProbe는 컨테이너 self-healing 설정이라 interval을 가지고 건강검진해서 문제가 있으면 컨테이너를 죽이고 다시 실행하는 것입니다. == 둘간의 연관성을 찾으시면 안되고, 각각 기능을 보셔야합니다.
파드를 실행할때마다 쿠버네티스가 자동으로 노드를 할당해주고 실행시켜주는 걸로 아는데, 저는 어떤 걸 해도 항상 node1에서 실행이 되네요. 랜덤하거나 혹은 CPU 사용량이라던가를 보고서 의미있게 파드를 실행시켜줄 노드를 결정해줄거 같은데, 지금까지 실습을 따라하고 추가 다른 예제들도 몇몇 따라 해봐도 계속 node1에서 실행되니까 쿠버가 알아서 노드 할당해주고 이런 모습을 못보는게 좀 답답하기도 하네요. 현재 노드1, 2 다 살아있고, 그나마 파드 한 10개 이상 동시에 띄웠을 때 정도만 노드 2에 몇개가 잡히고 나머지는 노드 1에 잡힙니다. 아마도 노드1을 더 이상 쓰기 어려울 정도일 때에만 다른 노드를 쓰는 정책으로 설정이 되어 있는거 같은데, 막상 강사님껄 보면 node2, node3 등에서도 적절히 번갈아가면서 파드가 켜지는 거 같구요... 노드 선택 정책 이런거 아예 안건드리고 완전 기본 상태에서도 노드가 번갈아가면서 선택되는게 맞나요?
![[따배쿠] 5-3, 4. 쿠버네티스 Pod - init container & infra container](http://i.ytimg.com/vi/ChArV14J6Ek/mqdefault.jpg)
![[따배쿠] 5-3, 4. 쿠버네티스 Pod - init container & infra container](/img/tr.png)
![[따배쿠] 5-6 쿠버네티스 Pod - Pod에 Resource 할당하기 (CPU/memory requests, limits)](http://i.ytimg.com/vi/lxCtyWPsb-0/mqdefault.jpg)
![[따배쿠] 5-1-1. 쿠버네티스 Pod - Container 정리와 Single / Multi Container Pod 생성](http://i.ytimg.com/vi/0rYt3PcggzA/mqdefault.jpg)
![[따배쿠] 6-1 Controller - ReplicationController란?](/img/1.gif)
잘보고 갑니다
39:37 ㅋㅋㅋㅋ "엄청나지 않습니까? 박수....." 강사님. 너무 매력적이세요. 쵝오
ㅋㅋㅋ 다시 봤습니다. 영상... 에구 부끄러워라.. ㅋㅋ
주말 k8s 강의 정주행 중입니다.감사합니다.
apiVersion: v1
kind: Pod
metadata:
name: liveness-exam
spec:
containers:
- image: busybox
name: busybox-container
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- ls
- /tmp/healthy
initialDelaySeconds: 10
periodSeconds: 5
successThreshold: 1
failureThreshold: 2
네. 잘 이해하시고 작성하셨습니다. ^^
정말 감사합니다.
apiVersion: v1
kind: Pod
metadata:
name: liveness-exam
spec:
containers:
- name: busybox-container
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
#추가한부분
livenessProbe:
exec:
command:
- ls
- /tmp/healthy
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 2
successThreshold: 1
오~ livenessProbe 이해하시는것은 문제 없었다는거죠? ^^ 완전 잘하셨습니다.
[문제풀이]
apiVersion: v1
kind: Pod
metadata:
name: liveness-exam
spec:
containers:
- name: busybox-container
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- ls
- /tmp/healthy
initialDelaySeconds: 10
failureThreshold: 2
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 1
입니다.
처음에 depth 잘못맞춰서 헤매구 두번째 initialDelaySeconds 인데 intialDelaySecond라구 해서 헤맸어요ㅠ 그래도 직접 타이핑하면서 큰 도움이 되었습니다. 항상 감사합니다~~
오 잘 기록하셨습니다. ^^
좋은 강의를 주시고 있으셔서 너무나도 감사한 마음으로 잘 듣고 있습니다.
그런데 궁금한 점이 이번 강의에서 하나 생겼습니다.
꽤 오랜 시간이 지난 영상이라 답변을 해 주실 수 있을지 모르겠네요.
** 궁금한 점: Restart 하는 시점이 예상과 좀 많이 달라서 이해가 안 됩니다.🥲
livenesProbe 내용을 다른 사람들처럼 정답과 같이 지정한 후, watch kubectl get pods -o wide 명령으로 계속 확인해 보고 있으면, 재시작 하는 타이밍이 제가 예상한 것과는 너무 다르네요.
/tmp/healthy 파일 생성 이후 30초 동안 유지한후 제거되므로, 해당 컨테이너가 Running 상태가 되고 난후, 41~2초 정도 되었을 때 ls /tmp/healthy 명령 실패가 2회 넘어서 Restart가 이루어져야 할 것 같습니다.
이유는 periodSeconds가 5초, failureThreshold가 2회라서, sleep 30초 + period 5초 x failure 2회 체크 = 대략 40초라고 생각했습니다. 타이밍이 조금 안 맞다하더라도 50초 내외에는 Restart가 되어야 할 것 같았습니다.
하지만, 제 환경에서는 약 70초 정도가 지났을 때마다 Restart가 진행되는 것으로 파악됩니다.
혹시 제 예상과 다르게 동작하는 적절한 이유가 있을까요? 아니면 제가 잘못 이해하고 있는건가요?
답변 주시면 너무 감사하겠습니다. 그럼 새해 복 많이 받으시고 좋은 일만 가득하세요.
안녕하세요. 이성미입니다.
컨테이너가 30초 동작하고 kill 되었을때 period 5초에서 확인해서 중지상태 점검한거, 2회 점검까지 확인하신거죠? 이후 container kill 시그널이 전달되어 컨테이너가 중지되고, 다시 로딩되어 실행되는 시간이 들어갈것입니다. 이것까지 확인하셔야죠. 언제 kill 시그널이 전달되는지까지 확인해야합니다.
@@ttabae-learn 이성미 강사님, 컨테이너 자체가 중지되고 다시 로딩되는 데까지는 생각을 못 했네요. 답변 정말 감사합니다. 새해 복 많으시고, 올해에도 좋은일만 가득하시기를 바랍니다.
영상 중간에 nfsd 컨테이너 예제를 설명하면서.. port를 4096이라 했네요. ^^ 리눅스 오랫동안 안했더니 이런걸 다 햇갈리네요.
nfsd 는 2049 포트를 사용합니다. ^^
apiVersion: v1
kind: Pod
metadata:
name: liveness-exam
spec:
containers:
- name: busybox-container
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- ls
- /tmp/healthy
periodSeconds: 5
successThreshold: 1
failureThreshold: 2
initialDelaySeconds: 10
저는 요즘 시작하고 있어서, 아래분들 답 올려주셨지만, 한번 올려봅니다~!
고맙습니다
감사합니다~ 엄청 중요한 기능이네요
도움이 되어 다행입니다. 감사합니다😊
안녕하세요 선생님. 종은 강의 감사드립니다. 질문이 있는데요.. 최소 바이너리 udp daemon(FROM scratch) pod에 대한 헬스 체크를 할 방법은 있는지 궁급합니다.
뭔가 헬스체크를 할수 있는 명령어가 있어야겠죠?
최소크기이든, 최대크기이든, base image scratch 아래 추가로 넣은 파일이나 프로그램이 있으면 명령어로 가능합니다.
정말 강의 잘하시네요.꼼꼼하고 우아하고 치밀하고 섬세하고. ㅎㅎ. 좋은 강의 감사드립니다.
도움이 되어 정말 다행입니다. 더 많은 컨텐츠들 기대해주세요. 감사합니다😊
혹시 다른 파드에서 어느 특정파드를 헬스체크 할수있을ㄲ요?
다른 파트에서 화인하려면 모니터링 툴을 사용하눈것을 말씀하시는것일까요??
안녕하세요 선생님
좋은 강의 항상 감사드립니다.
궁금한 부분이 있는데요.
Deployment 리소스에 의해 Pod가 자동 복구 되는 것과 livenessProbe에 의해 자동 복구되는 것에 어떤 차이가 있는걸까요?
큰 차이는 Self-Healing 대상인걸까요?
예를들면 Deployment의 경우 Node 장애시 Pod를 자동복구 시켜주는 것과 달리 livenessProbe 속성의 경우 Container를 자동 복구 시켜주는 것 이라던지요
또는 Deployment와는 달리 livenessProbe의 경우 헬스체크 옵션이 다양하다는 것에 있을까요?
그렇다면 kube-controller manager가 Pod의 개수를 보장하고 관리하는 역할을 수행하는 컴포넌트라면 Container를 관찰 및 모니터링을 수행하는 컴포넌트는 kubelet이라고 보면 될까요?
Deployment 리소스에 의해 Pod가 자동 복구 되는 것과 livenessProbe에 의해 자동 복구되는 것에 어떤 차이
1. Deployment는 파드의 갯수를 보장해주는 RS컨트롤러로 replicas 수를 늘리면 scale out 되는것이고
2. livenessProbe는 컨테이너 self-healing 설정이라 interval을 가지고 건강검진해서 문제가 있으면 컨테이너를 죽이고 다시 실행하는 것입니다.
==
둘간의 연관성을 찾으시면 안되고, 각각 기능을 보셔야합니다.
소리가 다시 커져서 정말 좋네요 ㅎㅎㅎ
다행이네요. ㅋㅋ 돈들인 가치가 있죠? 마이크 좋은것 같아요. ^^
apiVersion: v1
kind: Pod
metadata:
name: liveness-exam
spec:
containers:
- name: busybox-container
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe
exec:
command:
- "cat"
- "/tmp/healthy"
initialDelaySeconds: 10
periodSeconds: 5
successThreshold: 1
failureThreshold: 3
강의에서 보내주신 코드에 livenessProbe 코드를 추가하였습니다.
네. 잘하셨습니다. ^^ 문제 풀이하듯이 스스로 만들어볼때 도움이 많이 되는것 같습니다.
apiVersion: v1
kind: Pod
metadata:
name: liveness-exam
spec:
containers:
- name: busybox-container
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf/tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- ls
- /tmp/healthy
failureThreshold: 2
고맙습니다. ^^
조금 더 넣어야합니다. 실패 횟수만 들어갔는데, 시작해서 10초 후부터 self-healling 하는거, 성공횟수 1회(default이긴 하지만) 을 추가로 넣어주세요~^^
오늘도 감사합니다~
고맙습니다.
221005 수강완료!
감사합니다😊
교수님 강의 항상 잘보고 있습니다. livenessProbe기능 너무 좋아보이는데 실무에서 거의 항상 사용된다고 생각하는것이 맞을까요,,?
[이성미 강사] 네. 꼭 써야하는 기능입니다.
감사합니다. 여기까지 왔는데, 도움이 정말 됩니다. 힘드시더라도 계속 올려주세요..
넵. 지치지 않고 달려보겠습니다. ^^
마지막 문제의 제 정답은
```
apiVersion: v1
kind: Pod
metadata:
name: liveness-exam
spec:
containers:
- name: busybox-container
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- ls
- /tmp/healthy
initialDelaySeconds: 10
periodSeconds: 5
successThreshold: 1
failureThreshold: 2
```
[이성미 강사] 고맙습니다. ^^
파드를 실행할때마다 쿠버네티스가 자동으로 노드를 할당해주고 실행시켜주는 걸로 아는데, 저는 어떤 걸 해도 항상 node1에서 실행이 되네요.
랜덤하거나 혹은 CPU 사용량이라던가를 보고서 의미있게 파드를 실행시켜줄 노드를 결정해줄거 같은데, 지금까지 실습을 따라하고 추가 다른 예제들도 몇몇 따라 해봐도 계속 node1에서 실행되니까 쿠버가 알아서 노드 할당해주고 이런 모습을 못보는게 좀 답답하기도 하네요.
현재 노드1, 2 다 살아있고, 그나마 파드 한 10개 이상 동시에 띄웠을 때 정도만 노드 2에 몇개가 잡히고 나머지는 노드 1에 잡힙니다.
아마도 노드1을 더 이상 쓰기 어려울 정도일 때에만 다른 노드를 쓰는 정책으로 설정이 되어 있는거 같은데,
막상 강사님껄 보면 node2, node3 등에서도 적절히 번갈아가면서 파드가 켜지는 거 같구요...
노드 선택 정책 이런거 아예 안건드리고 완전 기본 상태에서도 노드가 번갈아가면서 선택되는게 맞나요?
node1에 있는 컨테이너 이미지를 삭제한 후에 시도해보세요. node1에 이미지가 저장되어 있어서 스케쥴링 될수 있습니다. ^^
readiness 의 용도는 뒤에 나오나요?
네. 책의 순서대로 진행하기 때문에 readiness 더 뒤에서 나옵니다. ^^