준's 생각 정리소

Pod Probe Liveness Probe 기본적으로 Pod의 생존 여부를 확인하기 위한 방법이다 우리가 알기로 pod이 죽었을 경우 kubelet이 알아서 재시작으로 시켜주고 다시 pod이 할당된다. 하지만 죽어있느 pod에 때문에 deadlock이 발생한다면 어찌 해야될지 모른다! 그러므로 liveness probe를 사용하여 주기적으로 체크! 방법으로는 HTTP request, TCP socket, exec command가 있다 HTTP Request 지정된 IP, Port, Path에 HTTP Get을 요청한다. probe에 대한 에러, 미응답의 경우 실패로 간주 ex) apiversion: v1 kind: Pod metadata: labels: test: liveness name: livene..

Cloud/Kubernetes 2020. 6. 17. 15:42

Controller Replication Controller selector label 기반으로 RC가 관리한 pod를 가지고 오는데 사용한다 Replicas num 항시 pod의 갯수를 유지한다 많으면 삭제, 적으면 추가 Pod template pod를 추가할때 어떠한 pod를 만들지에 대한 정보 기술 ReplicaSet RC의 상위 버전 Equality 기반 x set 기반 Deployment RC,RS의 상위 버전의 추상화 개념 Blue/Green 한번에 모든 서비스를 새로운 버전으로 바꾼다 Rolling pod를 하나씩 지워가면서 바꿈 위의 배포 방법은 rollback 시 불안정한 부분들이 많이 발생 ex) 클라이언트에서 실행되기 떄문에 연결이 끊어질 경우 배포작업이 끊김 수동 컨트롤이 필요한 부..

Cloud/Kubernetes 2020. 5. 11. 13:28

Object What to do? 어떠한 어플리케이션이 동작/ 어떠한 노드에서 동작 중인가 체크 어플리케이션이 이용할 수 있는 리소스 reboot, update, etc 에 대한 policy 끊임없이 내가 원하는 spec의 status가 되도록 요구하는 명세서와 같은 역할을 한다 Component 우리가 원하는 상태를 기술하는 spec 부분 기본적인 오브젝트를 생성 관리하는 controller 부분 yaml, JSON 파일로 존재한다 apiVersion, kind, metadata, spec 등을 기본적으로 요구 apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지 kind - 어떤 종류의 오브젝트를 생성하고자 하는지 metadata - 이름, 문자열, ..

Cloud/Kubernetes 2020. 5. 11. 13:27

Kubernetes Intro History Tradition 어플리케이션의 리소스를 정확히 파악할 수 없었으므로 자원의 비효율이 많이 발생 이를 해결하기 위해 물리 서버를 증설 하는것 외에는 답이 없었다 Virtual Machine 단일 서버에서 여러가지 가상화를 통해 어플리케이션을 격리함으로써 리소스 할당에 제한을 둘수 있었다. 각 머신은 운영체제를 가지고 있고 격리, 파괴가 아주 쉬움 그러나 각각의 VM이 격리 되어있기때문에 유연하지 못하다 이 모든걸 OS위의 hypervisor가 통제 Container VM과 다르게 자체 OS를 두지 않고 하나의 OS를 공유 -> 오버헤드가 적고 라이트하다 격리성을 최대한 완화, 또 인프라와의 종속성을 끊었기 떄문에 이식이 매우 쉬움 보통적으로 Docker가 co..

Cloud/Kubernetes 2020. 5. 8. 19:54