다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
This material is made to educate operators, who deal with cassandra in production environment and based on cassandra version 1.1.X
이 자료는 Cassandra를 상용 환경에서 운용하기 위한, 운용자를 위한 교육 자료로 Cassandra 1.1.X를 기준으로 설명한 자료입니다.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
This material is made to educate operators, who deal with cassandra in production environment and based on cassandra version 1.1.X
이 자료는 Cassandra를 상용 환경에서 운용하기 위한, 운용자를 위한 교육 자료로 Cassandra 1.1.X를 기준으로 설명한 자료입니다.
네이버 클라우드 플랫폼의 Kubernetes Service(NKS)에서 Pod들의 오토스케일을 적용하는 방법에 대해서 소개합니다 | Introduce how to apply autoscale of Pods in the Kubernets Service (NKS) of Naver Cloud Platform
[17.01.19] docker introduction (Korean Version)Ildoo Kim
Docker(도커) 소개를 위해 사용했던 자료입니다.
제가 속한 개발팀에서는 도커 컨테이너를 기반으로 개발부터 배포까지 가능한 환경 및 인프라를 구축하여 개발팀에서 대다수의 오퍼레이션까지 관여하면서 Devops 형태로 운영합니다.
Docker(도커)를 처음 사용하거나 개념적으로 익숙하지 않은 초보를 위해 만든 자료입니다.
슬라이드에서 사용된 스크립트/코드는 아래에 있습니다.
https://github.com/ildoonet/docker_introduction
----
김일두, Software Engineer @ Kakao
Github : https://github.com/ildoonet
Linkedin : https://www.linkedin.com/in/ildoo-kim-56962034/
This presentation start from basic concept such as container and container orchestration
And then go through Kubernetes internal especially Master Node components and Work Node components and show and explain core mechanism with codes.
Similar to Ch9,10. Deployments and Statefulsets (20)
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]