1. Ch 3. Pods running
containers in Kubernetes
박홍민
2. Before ..
- 지난주에 뭐했더라 ? 기억이 안난다..
- Docker container 이미지 빌드, 컨테이너 실행(docker build -t
kubia, docker run --name kubia-conatiner -p 8080:8080 -d
kubia)
- Minikube (or kubernetes master), kubectl(k8s 클라이언트,
cli) 다운로드 및 실행
- 지난주에 실습하고 PC를 shutdown 했음 -> 다시켜야함
3. Before ..
- Minikube 는 방금 다시 켰고.. (minikube start)
- Kubectl 은 키거나 이미지를 재실행 한적이 없는데 지난주에
running, scaling 했던 pod 이 잡힘 -> minikube 가 run 하면서
명령내렸나 ?
-> kubectl 이란 것은 어떤것? 데몬? 프로세스? -> 그냥 CLI. master
node 와 REST API 통신함.
4. 무엇을 배우나
● Creating, running, and stopping pods
● Organizing pods and other resources with labels
● Performing an operation on all pods with a specific label
● Using namespaces to split pods into non-overlapping groups
● Scheduling pods onto specific types of worker nodes
5. Pod 은 왜 필요한가?
- 1 container 1 process 권고. 왜? 한 container 에서 나오는 로그
처리 분리하기 힘듬.
- 1 container 1 process 권고이기 때문에 container 끼리 그룹할
필요가 있음. -> pod 생김.
- 동일 pod 내의 container -> hostname, network interfaces,
IPC namespace 등 공유
- Filesystem 은 kubernetes Volume
6. Pod 은 왜 필요한가?
- K8s 에서 pods 들은 flat 함. NAT 없음. LAN 처럼 Flat network
- -> This is usually achieved through an additional software-defined network layered on top of the
actual network.
- 두 pod 에서 네트워크 패킷 던지면 source ip 가 서로의 actual ip
로 그대로 나옴.
7. Pod 이라는 개념을 상황으로 이해하자
- Multi-tier app -> pod들을 여러개로 분리.
- Pod 하나에 있는 컨테이너들 -> pod 이 죽으면 같이 죽는다.
- Pod 은 scaling 의 한 단위 -> 만약 WEB-WAS-DB 가 1 pod 에 있으
면, WEB 늘리고싶은데 DB 도 늘리는 꼴
- 그렇다면.. Pod 에는 어떤 container들을 하나로 묶어야 ?
-> 저럴 때라고 하는데 크게 와닿진 않는다.
-> 그냥 1 container 1 pod 으로 분리하면 되는듯 ?
운영 중에 아닌 경우 ?
8. Pod 이라는 개념을 상황으로 이해하자
잠깐.. 내가 k8s node를 생성한 적이 있었나 ?
마스터는 minikube를 설치하면서 됬을 것 같은데 …
Minikube 를 설치했더니 뭐가 마스터고 뭐가 worker node 인지 분간이
잘 안간다.
그렇지만 일단 나중에 보기로하고..
9. 잠깐..
내가 k8s node를 생성한 적이 있었나 ?
마스터는 minikube를 설치하면서 됬을 것 같은데 …
Minikube 를 설치했더니 뭐가 마스터고 뭐가 worker node 인지 분간이
잘 안간다.
Kubectl가 설치되있으면 worker node 인가 ?
그렇지만 일단 나중에 보기로하고..
10. Pod 의 정의
- YAML(metadata+spec+status) or json 으로 존재
11. 잠깐..
- pod 을 host OS 에서 process 로 잡을 수 있나 ?
- 의문의 명령어 날린 흔적들
15. (돌아와서) Pod 의 log
$ docker logs <container id> (pod 이 떠있는 서버. 즉, minikube
ssh를 한 minikube VM 에서)
->
$ kubectl logs kubia-manual -c kubia (local 에서. 즉, minikube
를 깐 로컬 서버에서)
Kubia server starting…
(.. 점점 내가 어느 서버에 있는지 헷갈려진다..)
16. Pod 관리 - label, annotation
- Label, selectors : pod 구분, 필터 같은 느낌
- Label 은 꼭 pod 에만 쓸 수 있는 건 아님.
- Label, selector 로 특정 node에 pod을 디플로이할 수 있음.
- Annotation은 긴설명, label 은 짧은설명
17. Pod 관리 - Namespace
- K8s Resources 분리 가능
- Namespace 에 따른 자원(CPU,memory …)/유저 한정
- 같은 pod 을 다른 namespace 로 띄울 수 있음
Q. 언제 label, 언제 namespace 쓰나? 크게 와닿지 않음.
Q. Kubernetes resource vs object
A representation of a specific group+version+kind is an object.
A specific URL used to obtain the object is a resource.
(...)
18. Pod 관리 - remove pod
- 분명 지웠는데, 2분전에 다시 생김. 왜?
- Kubectl run 으로 실행한 pod -> RelicationController 때문
.(Ch.9에 나온다고 함)
20. 무엇을 배우나
● Keeping pods healthy
● Running multiple instances of the same pod
● Automatically rescheduling pods after a node fails
● Scaling pods horizontally
● Running system-level pods on each cluster node
● Running batch jobs
● Scheduling jobs to run periodically or once in the future
21. Keeping pods healthy - liveness probes
[Liveness probes]
- HTTP GET probe
- TCP Socket probe
- Exec probe
실패 -> Container restart
* /health 같은 url path 로 모든 로직 점검하도록
* 그 컨테이너 자체의 이상만 점검하도록. 예) Frontend WEB ->
backend DB/WAS 와 연결이 안되는 것은 liveness probe에 넣으면 안됨
. (주 원인이 해당 container 가 아니므로.)