seulcoding

5.6. Using a headless service for discovering individual pods 지금까지는 service가 stable IP 주소를 제공하고, client가 endpoint를 통해서 랜덤으로 선택된 pod에 접근할 수 있는 것을 보았다. 하지만 만약 클라이언트가 모든 pod에 접근하고 싶다면? kubernetes는 이런 상황에 DNS lookup을 통해 pod IP들을 모두 알 수 있다. (clusterIP 필드를 None으로) Creating a headless service service의 spec에서 clusterIp 필드를 None으로 만들면 서비스를 headless로 만들고, kubernetes는 클라이언트가 pod에 붙을 수 없도록 cluster IP를 부여하지 ..

5.5. Signaling when a pod is ready to accept connections Introducing readiness probes container의 readiness probe가 성공하면 해당 컨테이너는 request를 받을 준비가 된 것 liveness probe와는 다르게 readiness가 실패해도 pod가 제거되거나 다시 시작되지는 않는다. Adding a readiness probe to a pod $ kubectl edit rc kubiaAdd spec.template.spec.containers. in kubia-rc-readnessprobe.yaml apiVersion: v1 kind: ReplicationController metadata: name: kubia ..

5.4 Exposing services externally through an Ingress resource Ingress (noun)—The act of going in or entering; the right to enter; a means or place of entering; entryway. Understanding why Ingresses are needed LoadBalancer service는 각각의 load balancer마다 각자의 IP 주소가 있어야 하지만, Ingress는 여러 서비스에 한개의 IP 주소만 필요하다. client가 HTTP 요청을 Ingress에게 보내면 request의 host와 path로 어떤 서비스로 포워딩할지를 결정한다. Understanding that an..

5.3. Exposing services to external clients 지금까지는 클러스터 안의 pod들이 어떻게 service에 접근하는지를 다뤘다. 하지만 frontend webserver와 같이 외부에 노출이 필요한 서비스들이 존재한다. (사실 내가 다루는 대부분의 서비스...) 여러 가지 방법으로 외부에서 접근 가능한 서비스를 만들 수 있따. service type을 NodePort를 설정: 각 클러스터의 노드는 자신의 포트를 열어 traffic을 service로 리다이렉트 service type을 LoadBalance로 설정 (extension of the NodePort type): Ingress 리소스 생성(radically different mechanism for exposing m..

5.2. Connecting to service living outside the cluster Introducing service endpoints service는 사실 pod와 직접 링크되는게 아니라 Endpoint resource가 중간에 존재한다. $ kubectl describe svc kubia Name: kubia Namespace: default Labels: Annotations: Selector: app=kubia Type: ClusterIP IP: 10.100.198.79 Port: http 80/TCP TargetPort: 8080/TCP Endpoints: 172.17.0.7:8080,172.17.0.8:8080,172.17.0.9:8080 Port: https 443/TCP Ta..

Ch 5. Services: enabling clients to discover and talk to pods 이 챕터는 다음 내용을 다룬다. Service 리소스를 만들고 한 주소로 pod 그룹을 expose 클러스터 안의 services를 expose 외부 서비스를 클러스터 안의 service와 연결 service의 부분으로 pod가 준비되게 컨트롤 Troubleshooting service 요즘의 많은 애플리케이션들은 외부 요청에 응답하게 만들어진다. kubernetes가 아닌 상황에서는 sysadmin이 클라이언트 앱에 각각의 IP주소나 hostname을 부여하지만, Kubernetes에서는 이런 방식으로 작동하지 않는다. Pod는 ephemeral (덧없다, 단명한다): 언제든지 생기고 사라질 ..

Pod Lifecycle Pod phase (파드의 단계) pod의 status 필드는 PodStatus 오브젝트로 정의됨 Pending: 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다. Running :파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다. Succeeded: 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다. Failed: 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이..

Pod Pod는 Kubernetes에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다. 파드는 무엇인가? Pod는 고래 떼 (pod of whales)나 콩꼬투리 (pea pod)와 마찬가지로 하나 이상의 컨테이너 그룹을 말한다. 이 그룹은 storage/network를 공유한다. 도커 구조 관점에서 보면 pod는 공유 네임스페이스와 공유 볼륨을 가진 도커 컨테이너 그룹 정도가 될 것이다. 파드의 의의 파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써 애플리케이션 배포 및 관리를 단순화 파드는 그 구성 요소 간에 데이터 공유 및 통신이 가능 파드의 내구성 (또는 결핍) 파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부..

hands-on-helm helm이 최근에 CNCO 통과 왜 helm 3가 좋은지? helm 2, 3는 전혀 별개로 설치/사용 가능하다. # 발표자가 준비해놓은 demo $ git clone https://github.com/jldeen/helm3-demo.git $ cd helm3-demo # script로 설치 가능. h3 alias 추가해줌 $ ./scripts/setup-helm3.sh # 최신 버전 helm3 설치 $ brew install helm # 최신 버전 helm2 설치 $ brew install helm@2그리고 helm 3의 사용법을 잠시 보여줌 helm3의 major refactor helm이 kubernetes보다 (6개월이지만) 먼저 나왔다고 한다! (ㅎㄷㄷ) 그래서 Makin..

Pod Overview 파드 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위 주로 두 가지 방법으로 사용 단일 컨테이너만 동작하는 파드 함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드 어떻게 파드가 다중 컨테이너를 관리하는가? 파드 내 컨테이너는 동일한 머신의 클러스터에 배치되고 스케쥴 됨 리소스와 의존성 공유 파드는 같은 파드에 속한 컨테이너에게 두 가지 공유 리소스를 제공 네트워킹 각 파드는 고유한 IP 주소를 할당 한 파드 내의 모든 컨테이너는 network namespace와 IP address, network port를 공유 다른 컨테이너와는 localhost를 사용하여 통신 저장소 Volumnes을 명시 가능 ..