본문 바로가기
database/DevOps를 위한 Kubernetes 시작

{쿠버네티스 운영} 쿠버네티스 서비스

by 문파워 2020. 11. 26.

※ 쿠버네티스 볼륨

 

Volumes

On-disk files in a container are ephemeral, which presents some problems for non-trivial applications when running in containers. One problem is the loss of files when a container crashes. The kubelet restarts the container but with a clean state. A second

kubernetes.io

  • 컨테이너간 볼륨 공유
apiVersion: v1
kind: Pod
metadata:
  name: test-ebs
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-ebs
      name: test-volume
  volumes:
  - name: test-volume
    # This AWS EBS volume must already exist.
    awsElasticBlockStore:
      volumeID: "<volume id>"
      fsType: ext4
      

 

  • 컨테이너간 볼륨 타입
Temp Local Network
emptyDir hostPath GlusterFS
gitRepo
NFS
iSCSI
gcePersistentDisk
AWS EBS
AzureDisk
Fiber Channel
Secret
VshereVolume

 

  • emptyDir 의 생명주기는 컨테이너 단위가 아니라 Pod 단위이다. 때문에 emptyDir은 삭제되지 않고 계속해서 사용이 가능하다.
  • emptyDir configuration example
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {} 
    

 

  • hostPath는 노드의 로컬 디스크의 경로를 Pod에서 마운트해서 사용
  • 같은 hostPath에 있는 볼륨은 여러 Pod사이에서 공유되어 사용
  • Pod가 삭제 되더라도 hostPath에 있는 파일들은 삭제되지 않고 다른 Pod가 같은 hostPath를 마운트하게 되면, 남아있는 파일을 액세스 가능
  • hostPath configuration example
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data
      # this field is optional
      type: Directory 
      

 

  • gitRepo: 생성시에 지정된 git 레파지토리의 특정 리비전의 내용을  clone을 이용해서 내려받은 후에 디스크 볼륨을 생성하는 방식
  • 물리적을는 emptyDir이 생성되고, git 레파지토리의 내용을 clone 으로 다운로드

 

※ PersistentVolume(PV) and PersistentVolumeClaim(PVC) 생명주기 

kubernetes.io/docs/concepts/storage/persistent-volumes/

 

Persistent Volumes

This document describes the current state of persistent volumes in Kubernetes. Familiarity with volumes is suggested. Introduction Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for us

kubernetes.io

클러스터 내 스토리지 일부 조각을 나타내는 API객체

PV는 Pod하고는 변개로 관리되고 별도의 생명주기를 가지고 있으며

PVC는 사용자가 PV에 하는 요청이다.

 


 

※ 쿠버네티스 서비스 개념

  • Pod 집합과 같은 애플리케이션들에 접근하는 방법을 기술하는 API객체
  • 포트와 로드밸런서를 기술할 수 있다.
  • Pod들을 서로 연결한다. 
  • Pod 접근 정책을 정의한다.
  • 마이크로서비스와 대응되는 개념으로 이해해야 한다.

kubernetes.io/docs/concepts/services-networking/service/

 

Service

An abstract way to expose an application running on a set of Pods as a network service. With Kubernetes you don't need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DN

kubernetes.io

 

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      

 

※ Health Check  개념

 

  • livenessProbe: Indicates whether the container is running. If the liveness probe fails, the kubelet kills the container, and the container is subjected to its restart policy. If a Container does not provide a liveness probe, the default state is Success.

  • readinessProbe: Indicates whether the container is ready to respond to requests. If the readiness probe fails, the endpoints controller removes the Pod's IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay is Failure. If a Container does not provide a readiness probe, the default state is Success.

쿠버네티스는 각 컨테이너의 상태를 주기적으로 체크해서, 문제가 있는 컨테이너를 자동으로 재시작하거나 또는 문제가 있는 컨테이너 (Pod를) 서비스에서 제외할 수 있으며

컨테이너가 살아 있는지 아닌지를 체크하는 방법이 Liveness Probe

그리고 컨테이너가 서비스가 가능한 상태인지를 체크하는 방법을 Readiness Probe라고 하는 2가지 방법을 제공한다.

댓글