※ 쿠버네티스 볼륨
- 데이터를 담는 디렉토리
- 쿠버네티스 볼륨 종류 : kubernetes.io/docs/concepts/storage/volumes/
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가지 방법을 제공한다.
'database > DevOps를 위한 Kubernetes 시작' 카테고리의 다른 글
{쿠버네티스 모니터링} 프로메테우스 기반 모니터링 (0) | 2020.12.01 |
---|---|
{쿠버네티스 배포} 롤링 업데이트, Deployment, ConfigMap (0) | 2020.11.30 |
{쿠버네티스와 클러스터 아키텍쳐} 컴포넌트와 애드온 (0) | 2020.11.25 |
{쿠버네티스와 컨테이너} 가상화 컨테이너란? (0) | 2020.11.15 |
댓글