2. What to learn
● Replacing pods with newer versions
● Updating managed pods
● Updating pods declaratively using Deployment resources
● Performing rolling updates
● Automatically blocking rollouts of bad versions
● Controlling the rate of the rollout
● Reverting pods to a previous version
● => 버전관리
3. Update pod
1) 기존 pod 삭제 후 새 deploy -> ReplicationController 에 pod v2로 변경
2) 새 pod deploy 후 기존 pod 삭제(downtime X)
-> v2 ReplicationController 생성 후 Service 연결을 v2로.
-> scale up/down 조절하는 rolling update 도 가능.
4. Rolling update w/ ReplicationController
- img 를 같은 태그로 하면 안됨 -> 같은 건줄 알고 안받음.
- -> imagePullPolicy: Always 로 설정해야됨.
- kubectl rolling-update 커맨드로 가능.
- 기존 RC를 새 RC, 새 img 로 대체해서 기존 RC의 pod 을 scale down, 신규 RC의
pod scale up.
- 1) 기존 rc를 복제하여 label selector 에 deployment 추가.
- 2) Replicas 수정.
- (deployment 안달면 rolling 하다가 변경전/후 pod 을 잘못 삭제할 수 있음)
7. Deployments
- kubectl rolling-update는 클라이언트에서 실행하는 구조. -> Master에서 관리 필
요
- Deployment > ReplicaSet, ReplicaContronller(low-level)
- 왜?
- 배포 중 버전별 ReplicaSet을 관리하기 위한.
- Deployment 를 생성하면 ReplicaSet 이 알아서 생김.
- 아래처럼 관리를 위해 Deployment 필요
- pod template 바꾸면 재배포 됨.
8. Deployments - strategies
- RollingUpdate(default)
- Recreate: 구 pods 모두 삭제 후 신 pods 배포
- Deployment resource에서 pod template을 변경하면 RollingUpdate 됨.
- *단, ConfigMap(/Secret)은 update trigger X.
9. Deployments - undo
> kubectl rollout undo
deployment kubia
- --> rollout undo 가능.
Q. 근데 kubectl rollout 커맨드를
쓰면 결국 클라이언트에서 또 관리하게
되는것 아닌가 ?
10. Deployments - undo
- Deployment가 생성한 ReplicaSet이 삭제되지 않는 이유
- -> ReplicaSet 은 rollout history 관리!
- revisionHistoryLimit으로 rs history 개수 관리 가능
- maxSurge, maxUnavailable로 최대 동시 pod, 최대 unavailable pod 제한 가능
11. Deployments - undo
- kubectl rollout pause/resume deployment kubia -> 중단/재배포 가능.
- minReadySeconds: pod의 available 판단 시점. running 이후에 readiness
probe 체크 시간보다 크게 설정.
13. What to learn
● Deploying stateful clustered applications
● Providing separate storage for each instance of a replicated
pod
● Guaranteeing a stable name and hostname for pod replicas
● Starting and stopping pod replicas in a predictable order
● Discovering peers through DNS SRV records
14. Stable identity for pod
- stable identity: hostname, ip 등 고정 값을 사용한다는 것.
- 어떨 때 stable identity 필요?
- -> distributed stateful applications 에서.
- stateful <-> stateless.
- 상태 유지가 필요한 앱.
- distributed app: 분산 환경에서 돌아가는 앱. MSA ?
- 한 앱에서 다른 앱의 hostname/ip 등이 설정파일에 필요한 경우
- 클러스터 환경
15. Stable identity for pod
- stable identity 구현?
- service IP 는 바뀌지 않는다는 점을 참고해서,
- 1 pod 1 ReplicaSet 구조.
- -> but,
- 여전히 어떤 pod이 어떤 IP 사용할지 모름
16. StatefulSets
- ReplicaSet 대신 StatefulSet 라는 resource 생성.
- pets(펫, stateful apps) vs cattle(가축, stateless apps)
- StatefulSet 으로 생성한 pod -> 항상 고유값 가짐, storage 분리 가능
- ordinal index 로 시작.
- Random (X), Organized (O).
17. StatefulSets - governing headless Service
- stateful app -> hostname 으로 요청해야 하는 경우 있음.
- governing headless Service -> pod에 network identity 제공.
- -> 각 pod 은 자신의 DNS 가짐.
- 새 pod이 다른 node에 떠도 hostname은 변하지 않음.
- scale up/down은 index 순서대로 하나씩 순차.
18. StatefulSets - dedicated storage
- stateful app -> 각 pod의 storage가 각각 있어야함. (?)
- PersistentVolumeClaim 이 separate PersistentVolume을 갖도록.
- 근데 pod은 pod template에서 생성됨
- volume도 volume claim template에서 생성됨
19. StatefulSets - dedicated storage
- stateful app의 persistent volume 은 scale-down 해도 삭제되지 않음.
- 추후 scale-up 했을 때에 컨텐츠가 날아가지 않게 하고 다시 붙여쓰기 위해.
- manual하게 삭제해주어야 함.
- *그렇다면.. stateful app의 경우 동적으로 scale up/down을 잘 안하나?
- replica 개수 설정이 그 개수만큼 유지시키는 목적도 있지만, 동적으로 줄이
거나 늘리기 위해서도 사용을 하는 것이데.. stateful app은 애초에 동적을
고려하지 않는 것인가 ?
20. StatefulSets - guarantees
- StatefulSet은 꼭. 두 stateful pod 인스턴스가 동시에 동일
identity(hostname 등)으로 뜨지 않도록 보장해야 함. at-most-one.
- 즉, 새로운 pod으로 대체할 때, 기존 pod이 running이 아님을 확실히 보장해
야.
22. StatefulSets - 실습
- 2) governing Service
- Ch.5 에서 headless service 생성한 것과 동일.
- clusterIP: None -> client가 cluster로 연결할 수 없는 headless
service 의미.
- headless service -> clueter IP 대신 DNS lookup 으로 pod 연결.
23. StatefulSets - 실습
- 3) StatefulSet itself
- data라는 이름의 volumeClaimTemplates
- -> 각 pod에 PersistentVolumeClaim 생성
- pod 뜰 때 하나씩 뜸
24. StatefulSets - 실습
- Stateful로 생성된 pod describe -> pvc 생성
*PersistentVolume
*PersistentVolumeClaim
VS
*왜 교재랑 다르지?
교재는 아까 생성한 pv(pv-a, pv-c)
에 볼륨이 붙음
25. StatefulSets - 실습
- [test] 기생성한 pv-a, pv-b, pv-c를 지우고 StatefulSet을 재생성 해보자
- pv를 그냥 지우려 해도 안지워진다. pvc를 지워야 지워짐.
VS
26. StatefulSets - 실습
- [test] 기생성한 pv-a, pv-b, pv-c를 지우고 StatefulSet을 재생성 해보자
- PV를 랜덤하게 알아서 잡아주는건지, pvc, pv 모두 잘 생긴다. (아까처럼..)
VS
27. StatefulSets - 실습
- POST로 pod의 pvc에 날린 데이터 -> pod kill 후 다시 GET해도 남아있음.
- -> pod이 삭제되어도 떨어진 Volume 은 다시 붙고, 데이터 남아있음.
VS
28. StatefulSets - 실습
- 참고로 minikube에서 volume은 임의로생성할 때에는 /tmp/hostpath-
provisioner에 생성해서 붙여주는 듯.
- 이 경로가 pod 삭제해도 남아있음.
VS
29. StatefulSets - Discovering peers
- pod끼리 통신할 때 API 안거치고 통신 가능?
- DNS - A, CNAME, MX record and SRV record
- *A record: domain -> IP
- *CNAME record: Canonical Name, domain1 -> domain2
- *MX record: Mail Exchange
- *SRV record: Service record, hostname:ports로 특정 서비스를 하겠다는
레코드.
30. StatefulSets - Discovering peers
- 어플리케이션에서 SRV DNS lookup 으로 사용할 수 있음.
- kubia.default.svc.cluster.local 콜하면 pod은 랜덤 선택
- node.js 예) dns.resolveSrv("kubia.default.svc.cluster.local", callBackFunction);
[SRV record]
[A record]
31. StatefulSets - Discovering peers
- 근데 data sync는 어떻게?
- 소스에서 peer를 모두 찾아 모든 peer에게 GET request를 보내 데이터를 찾
아오게 할 수 있음.
- -> 소스 의존도가 생기고.. 비효율적이어 보임.
- 누가 사용하나 ..?
[SRV record]
[A record]
32. StatefulSets - Updating
- statefulset 수정 후 ->
- pod template 변경되면 pod 삭제 해야 재배포됨.
- 또는 Deployment/DemonSet처럼 설정 가능(from k8s 1.7)
[SRV record]
[A record]