seulcoding

7.3. Setting environment variables for a container Kubernetes에서는 각각의 컨테이너에 환경변수를 지정해 줄 수 있다. 다만 아직 pod레벨에서 지정하는 방법은 없다. 환경변수로 위에서 만든 fortune image의 interval을 설정해보자. fortune-env/fortuneloop.sh #!/bin/bash trap "exit" SIGINT echo Configured to generate new fortune every $INTERVAL seconds mkdir -p /var/htdocs while : do echo $(date) Writing fortune to /var/htdocs/index.html /usr/games/fortune > /va..

7. ConfigMaps and Secrets configuring applications Changing the main process of a container Passing command-line options to the app Setting environment variables exposed to the app Configuring apps through ConfigMaps Passing sensitive information through Secrets 거의 모든 app이 configuration을 필요로 하고 이를 app 자체에 담을 수 없으므로 kubernetes에서 어떻게 configuration option을 넘겨줄 수 있음 7.1. Configuring containerized ap..

Chapter 6. Volumes: attaching disk storage to containers Creating multi-container pods Creating a volume to share disk storage between containers Using a Git repository inside a pod Attaching persistent storage such as a GCE Persistent Disk to pods Using pre-provisioned persistent storage Dynamic provisioning of persistent storage 6.1. INTRODUCING VOLUMES 6.2. Usnig volumes to share data between..

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 (덧없다, 단명한다): 언제든지 생기고 사라질 ..

ch4. Replication and other controllers: deploying managed pods 4.6. Scheduling Jobs to run periodically or once in the future 소챕터들 4.1 keeping pods healthy 4.2. introducing replicationcontrollers 4.3. using replicasets instead of replicationcontroller 4.4. running exactly one pod on each node with daemonset 4.5. running pods that perform a single completable task 4.6. scheduling jobs to run peri..