SlideShare a Scribd company logo
1 of 32
Ch9. Deployments: updating
applications declaratively
Hongmin Park
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
● => 버전관리
Update pod
1) 기존 pod 삭제 후 새 deploy -> ReplicationController 에 pod v2로 변경
2) 새 pod deploy 후 기존 pod 삭제(downtime X)
-> v2 ReplicationController 생성 후 Service 연결을 v2로.
-> scale up/down 조절하는 rolling update 도 가능.
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 을 잘못 삭제할 수 있음)
Rolling update w/ ReplicationController
- kubectl rolling-update
Rolling update w/ ReplicationController
- kubectl rolling-update
Deployments
- kubectl rolling-update는 클라이언트에서 실행하는 구조. -> Master에서 관리 필
요
- Deployment > ReplicaSet, ReplicaContronller(low-level)
- 왜?
- 배포 중 버전별 ReplicaSet을 관리하기 위한.
- Deployment 를 생성하면 ReplicaSet 이 알아서 생김.
- 아래처럼 관리를 위해 Deployment 필요
- pod template 바꾸면 재배포 됨.
Deployments - strategies
- RollingUpdate(default)
- Recreate: 구 pods 모두 삭제 후 신 pods 배포
- Deployment resource에서 pod template을 변경하면 RollingUpdate 됨.
- *단, ConfigMap(/Secret)은 update trigger X.
Deployments - undo
> kubectl rollout undo
 deployment kubia
- --> rollout undo 가능.
Q. 근데 kubectl rollout 커맨드를
쓰면 결국 클라이언트에서 또 관리하게
되는것 아닌가 ?
Deployments - undo
- Deployment가 생성한 ReplicaSet이 삭제되지 않는 이유
- -> ReplicaSet 은 rollout history 관리!
- revisionHistoryLimit으로 rs history 개수 관리 가능
- maxSurge, maxUnavailable로 최대 동시 pod, 최대 unavailable pod 제한 가능
Deployments - undo
- kubectl rollout pause/resume deployment kubia -> 중단/재배포 가능.
- minReadySeconds: pod의 available 판단 시점. running 이후에 readiness
probe 체크 시간보다 크게 설정.
Ch10. StatefulSets:
deploying replicated stateful
applications
Hongmin Park
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
Stable identity for pod
- stable identity: hostname, ip 등 고정 값을 사용한다는 것.
- 어떨 때 stable identity 필요?
- -> distributed stateful applications 에서.
- stateful <-> stateless.
- 상태 유지가 필요한 앱.
- distributed app: 분산 환경에서 돌아가는 앱. MSA ?
- 한 앱에서 다른 앱의 hostname/ip 등이 설정파일에 필요한 경우
- 클러스터 환경
Stable identity for pod
- stable identity 구현?
- service IP 는 바뀌지 않는다는 점을 참고해서,
- 1 pod 1 ReplicaSet 구조.
- -> but,
- 여전히 어떤 pod이 어떤 IP 사용할지 모름
StatefulSets
- ReplicaSet 대신 StatefulSet 라는 resource 생성.
- pets(펫, stateful apps) vs cattle(가축, stateless apps)
- StatefulSet 으로 생성한 pod -> 항상 고유값 가짐, storage 분리 가능
- ordinal index 로 시작.
- Random (X), Organized (O).
StatefulSets - governing headless Service
- stateful app -> hostname 으로 요청해야 하는 경우 있음.
- governing headless Service -> pod에 network identity 제공.
- -> 각 pod 은 자신의 DNS 가짐.
- 새 pod이 다른 node에 떠도 hostname은 변하지 않음.
- scale up/down은 index 순서대로 하나씩 순차.
StatefulSets - dedicated storage
- stateful app -> 각 pod의 storage가 각각 있어야함. (?)
- PersistentVolumeClaim 이 separate PersistentVolume을 갖도록.
- 근데 pod은 pod template에서 생성됨
- volume도 volume claim template에서 생성됨
StatefulSets - dedicated storage
- stateful app의 persistent volume 은 scale-down 해도 삭제되지 않음.
- 추후 scale-up 했을 때에 컨텐츠가 날아가지 않게 하고 다시 붙여쓰기 위해.
- manual하게 삭제해주어야 함.
- *그렇다면.. stateful app의 경우 동적으로 scale up/down을 잘 안하나?
- replica 개수 설정이 그 개수만큼 유지시키는 목적도 있지만, 동적으로 줄이
거나 늘리기 위해서도 사용을 하는 것이데.. stateful app은 애초에 동적을
고려하지 않는 것인가 ?
StatefulSets - guarantees
- StatefulSet은 꼭. 두 stateful pod 인스턴스가 동시에 동일
identity(hostname 등)으로 뜨지 않도록 보장해야 함. at-most-one.
- 즉, 새로운 pod으로 대체할 때, 기존 pod이 running이 아님을 확실히 보장해
야.
StatefulSets - 실습
- StatefulSet으로 deploy 하려면
- 1) PersistentVolume
- 2) governing Service
- 3) StatefulSet itself
- 필요. 1) PersistentVolume
StatefulSets - 실습
- 2) governing Service
- Ch.5 에서 headless service 생성한 것과 동일.
- clusterIP: None -> client가 cluster로 연결할 수 없는 headless
service 의미.
- headless service -> clueter IP 대신 DNS lookup 으로 pod 연결.
StatefulSets - 실습
- 3) StatefulSet itself
- data라는 이름의 volumeClaimTemplates
- -> 각 pod에 PersistentVolumeClaim 생성
- pod 뜰 때 하나씩 뜸
StatefulSets - 실습
- Stateful로 생성된 pod describe -> pvc 생성
*PersistentVolume
*PersistentVolumeClaim
VS
*왜 교재랑 다르지?
교재는 아까 생성한 pv(pv-a, pv-c)
에 볼륨이 붙음
StatefulSets - 실습
- [test] 기생성한 pv-a, pv-b, pv-c를 지우고 StatefulSet을 재생성 해보자
- pv를 그냥 지우려 해도 안지워진다. pvc를 지워야 지워짐.
VS
StatefulSets - 실습
- [test] 기생성한 pv-a, pv-b, pv-c를 지우고 StatefulSet을 재생성 해보자
- PV를 랜덤하게 알아서 잡아주는건지, pvc, pv 모두 잘 생긴다. (아까처럼..)
VS
StatefulSets - 실습
- POST로 pod의 pvc에 날린 데이터 -> pod kill 후 다시 GET해도 남아있음.
- -> pod이 삭제되어도 떨어진 Volume 은 다시 붙고, 데이터 남아있음.
VS
StatefulSets - 실습
- 참고로 minikube에서 volume은 임의로생성할 때에는 /tmp/hostpath-
provisioner에 생성해서 붙여주는 듯.
- 이 경로가 pod 삭제해도 남아있음.
VS
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로 특정 서비스를 하겠다는
레코드.
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]
StatefulSets - Discovering peers
- 근데 data sync는 어떻게?
- 소스에서 peer를 모두 찾아 모든 peer에게 GET request를 보내 데이터를 찾
아오게 할 수 있음.
- -> 소스 의존도가 생기고.. 비효율적이어 보임.
- 누가 사용하나 ..?
[SRV record]
[A record]
StatefulSets - Updating
- statefulset 수정 후 ->
- pod template 변경되면 pod 삭제 해야 재배포됨.
- 또는 Deployment/DemonSet처럼 설정 가능(from k8s 1.7)
[SRV record]
[A record]

More Related Content

What's hot

Cassandra 멘붕기 | Devon 2012
Cassandra 멘붕기 | Devon 2012Cassandra 멘붕기 | Devon 2012
Cassandra 멘붕기 | Devon 2012Daum DNA
 
리눅스 커널 디버거 KGDB/KDB
리눅스 커널 디버거 KGDB/KDB리눅스 커널 디버거 KGDB/KDB
리눅스 커널 디버거 KGDB/KDBManjong Han
 
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)Hyunmin Lee
 
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.NAVER D2
 
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱PgDay.Seoul
 
Apache ZooKeeper 로
 분산 서버 만들기
Apache ZooKeeper 로
 분산 서버 만들기Apache ZooKeeper 로
 분산 서버 만들기
Apache ZooKeeper 로
 분산 서버 만들기iFunFactory Inc.
 
Redis basicandroadmap
Redis basicandroadmapRedis basicandroadmap
Redis basicandroadmapDaeMyung Kang
 
Pg day seoul 2016 session_02_v1.0_ff
Pg day seoul 2016 session_02_v1.0_ffPg day seoul 2016 session_02_v1.0_ff
Pg day seoul 2016 session_02_v1.0_ffPgDay.Seoul
 
[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis Cluster[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis ClusterNAVER D2
 
Cassandra education material
Cassandra education materialCassandra education material
Cassandra education materialYoungki Kim
 
AWS Aurora 100% 활용하기
AWS Aurora 100% 활용하기AWS Aurora 100% 활용하기
AWS Aurora 100% 활용하기I Goo Lee
 
[233]멀티테넌트하둡클러스터 남경완
[233]멀티테넌트하둡클러스터 남경완[233]멀티테넌트하둡클러스터 남경완
[233]멀티테넌트하둡클러스터 남경완NAVER D2
 
검색로그시스템 with Python
검색로그시스템 with Python검색로그시스템 with Python
검색로그시스템 with Pythonitproman35
 
[252] 증분 처리 플랫폼 cana 개발기
[252] 증분 처리 플랫폼 cana 개발기[252] 증분 처리 플랫폼 cana 개발기
[252] 증분 처리 플랫폼 cana 개발기NAVER D2
 

What's hot (20)

Cassandra 멘붕기 | Devon 2012
Cassandra 멘붕기 | Devon 2012Cassandra 멘붕기 | Devon 2012
Cassandra 멘붕기 | Devon 2012
 
리눅스 커널 디버거 KGDB/KDB
리눅스 커널 디버거 KGDB/KDB리눅스 커널 디버거 KGDB/KDB
리눅스 커널 디버거 KGDB/KDB
 
03.Ansible 소개
03.Ansible 소개03.Ansible 소개
03.Ansible 소개
 
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
 
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
 
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱
 
Apache ZooKeeper 로
 분산 서버 만들기
Apache ZooKeeper 로
 분산 서버 만들기Apache ZooKeeper 로
 분산 서버 만들기
Apache ZooKeeper 로
 분산 서버 만들기
 
Redis basicandroadmap
Redis basicandroadmapRedis basicandroadmap
Redis basicandroadmap
 
Redis
RedisRedis
Redis
 
Pg day seoul 2016 session_02_v1.0_ff
Pg day seoul 2016 session_02_v1.0_ffPg day seoul 2016 session_02_v1.0_ff
Pg day seoul 2016 session_02_v1.0_ff
 
Ansible
AnsibleAnsible
Ansible
 
[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis Cluster[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis Cluster
 
Cassandra education material
Cassandra education materialCassandra education material
Cassandra education material
 
AWS Aurora 100% 활용하기
AWS Aurora 100% 활용하기AWS Aurora 100% 활용하기
AWS Aurora 100% 활용하기
 
[233]멀티테넌트하둡클러스터 남경완
[233]멀티테넌트하둡클러스터 남경완[233]멀티테넌트하둡클러스터 남경완
[233]멀티테넌트하둡클러스터 남경완
 
Kubernetes
Kubernetes Kubernetes
Kubernetes
 
주키퍼
주키퍼주키퍼
주키퍼
 
검색로그시스템 with Python
검색로그시스템 with Python검색로그시스템 with Python
검색로그시스템 with Python
 
[252] 증분 처리 플랫폼 cana 개발기
[252] 증분 처리 플랫폼 cana 개발기[252] 증분 처리 플랫폼 cana 개발기
[252] 증분 처리 플랫폼 cana 개발기
 
Redis edu 3
Redis edu 3Redis edu 3
Redis edu 3
 

Similar to Ch9,10. Deployments and Statefulsets

[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축Ji-Woong Choi
 
Ch7,8. Configmaps, Secrets and API
Ch7,8. Configmaps, Secrets and APICh7,8. Configmaps, Secrets and API
Ch7,8. Configmaps, Secrets and APIHongmin Park
 
[Open-infradays 2019 Korea] jabayo on Kubeflow
[Open-infradays 2019 Korea] jabayo on Kubeflow[Open-infradays 2019 Korea] jabayo on Kubeflow
[Open-infradays 2019 Korea] jabayo on Kubeflow석환 홍
 
Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기
Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기
Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기Jongwon Han
 
docker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea Clouddocker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea CloudJude Kim
 
ARTIK 710 IoT class 02
ARTIK 710 IoT class 02ARTIK 710 IoT class 02
ARTIK 710 IoT class 02정출 김
 
AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석
AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석
AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석Amazon Web Services Korea
 
Kubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideKubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideChan Shik Lim
 
Tensorflow service & Machine Learning
Tensorflow service & Machine LearningTensorflow service & Machine Learning
Tensorflow service & Machine LearningJEEHYUN PAIK
 
resource on openstack
 resource on openstack resource on openstack
resource on openstackjieun kim
 
Deploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptxDeploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptxwonyong hwang
 
[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)Ildoo Kim
 
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육Ji-Woong Choi
 
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 DockerXECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 DockerXpressEngine
 
kubernetes from beginner to advanced
kubernetes  from beginner to advancedkubernetes  from beginner to advanced
kubernetes from beginner to advancedOracle Korea
 
kubernetes : From beginner to Advanced
kubernetes : From beginner to Advancedkubernetes : From beginner to Advanced
kubernetes : From beginner to AdvancedInho Kang
 

Similar to Ch9,10. Deployments and Statefulsets (20)

[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
 
Ch7,8. Configmaps, Secrets and API
Ch7,8. Configmaps, Secrets and APICh7,8. Configmaps, Secrets and API
Ch7,8. Configmaps, Secrets and API
 
1.intro to k8s
1.intro to k8s1.intro to k8s
1.intro to k8s
 
[Open-infradays 2019 Korea] jabayo on Kubeflow
[Open-infradays 2019 Korea] jabayo on Kubeflow[Open-infradays 2019 Korea] jabayo on Kubeflow
[Open-infradays 2019 Korea] jabayo on Kubeflow
 
Kafka slideshare
Kafka   slideshareKafka   slideshare
Kafka slideshare
 
K8s in action02
K8s in action02K8s in action02
K8s in action02
 
Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기
Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기
Daily Continuous Deployment를 위한 Custom CLI 개발 및
 AWS Elastic Beanstalk에 적용하기
 
docker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea Clouddocker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
 
[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용
[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용
[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용
 
ARTIK 710 IoT class 02
ARTIK 710 IoT class 02ARTIK 710 IoT class 02
ARTIK 710 IoT class 02
 
AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석
AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석
AWS Summit Seoul 2015 - AWS를 통한 게임 운영의 정석
 
Kubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideKubernetes on Premise Practical Guide
Kubernetes on Premise Practical Guide
 
Tensorflow service & Machine Learning
Tensorflow service & Machine LearningTensorflow service & Machine Learning
Tensorflow service & Machine Learning
 
resource on openstack
 resource on openstack resource on openstack
resource on openstack
 
Deploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptxDeploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptx
 
[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)
 
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
 
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 DockerXECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
 
kubernetes from beginner to advanced
kubernetes  from beginner to advancedkubernetes  from beginner to advanced
kubernetes from beginner to advanced
 
kubernetes : From beginner to Advanced
kubernetes : From beginner to Advancedkubernetes : From beginner to Advanced
kubernetes : From beginner to Advanced
 

Ch9,10. Deployments and Statefulsets

  • 1. Ch9. Deployments: updating applications declaratively Hongmin Park
  • 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 을 잘못 삭제할 수 있음)
  • 5. Rolling update w/ ReplicationController - kubectl rolling-update
  • 6. Rolling update w/ ReplicationController - kubectl rolling-update
  • 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 체크 시간보다 크게 설정.
  • 12. Ch10. StatefulSets: deploying replicated stateful applications Hongmin Park
  • 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이 아님을 확실히 보장해 야.
  • 21. StatefulSets - 실습 - StatefulSet으로 deploy 하려면 - 1) PersistentVolume - 2) governing Service - 3) StatefulSet itself - 필요. 1) PersistentVolume
  • 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]