오늘 스터디는 3회차 입니다. 벌써 4번째 모임이네요. (첫번째는 스터디 모임 구성 미팅이었습니다.)

스터디 내용은 다음과 같습니다.

발표자

• 3회 발표자 - 장병진

스터디 주제 목록

• Concepts >> Cluster Architecture >> Garbage Collection

  • https://kubernetes.io/docs/concepts/architecture/garbage-collection/

• Concepts >> Storage

  • https://kubernetes.io/docs/concepts/storage/

• Concepts >> Configuration

  • https://kubernetes.io/docs/concepts/configuration/

• Concepts >> Security

  • https://kubernetes.io/docs/concepts/security/

• Tutorials >> Configuration

  • https://kubernetes.io/docs/tutorials/configuration/

• Tutorials >> Security

  • https://kubernetes.io/docs/tutorials/security/

사실 쿠버네티스 스터디는 101 뿐만 아니라 모니터링 스터디도 같이 하고 있습니다.

모니터링 스터디는 1주는 온라인, 2주차 때는 오프라인으로 진행하는데, 2주차 오프라인 때는 101 스터디와 같이 하는 거죠.

오늘 모니터링 발표는 이재상님이 수고해 주셨습니다.

Minikube 로 프로메테우스를 설치하고 세팅하는 방법을 보여주었습니다.

모니터링 스터디 내용이 궁금하실 것 같아 여기에 남겨 봅니다.

[모니터링 스터디] 서비스 디스커버리

💡 프로메테우스 인프라스트럭쳐 모니터링 책의 12장 내용입니다.

• 참고 Repo: https://github.com/PacktPublishing/Hands-On-Infrastructure-Monitoring-with-Prometheus

1. 서비스 디스커버리?

프로메테우스에서 모니터링 대상, 타겟을 (자동으로) 관리하는 방법.

비교) 수동으로 타겟을 관리하는 전통적인 프로세스

• 자원 협상

• 운영 계약

• 신규 하드웨어 구매

• 하드웨어 배포

• 엑셀 관리

프로메테우스의 서비스 디스커버리)

Let everyone know you're about to start a deploy.

2. 프로메테우스의 서비스 디스커버리(sd) 옵션

프로메테우스 홈페이지에서 확인 가능한 서비스 디스커버리 옵션

https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config

클라우드 프로바이더

오토스케일을 통한 자원의 확장과 감소를 자동으로 감시해야 함.

• AWS

• Azure

• GCP

• OpenStack

• Joyent

• …

(AWS 서비스 디스커버리 설정과 프로메테우스 연결 화면)

scrape_configs:
  - job_name: ec2_sd
    ec2_sd_configs:
      - region: eu-west-1
        access_key: ACCESSTOKEN
				secret_key: 'SecReTKey'

컨테이너 오케스트레이터

컨테이너 Orchestrator는 실행 중인 서비스와 위치를 추출하는 기능을 기본적으로 지원하기 때문에 프로메테우스에서 해당 기능을 연결하기 용이하다.

프로메테우스는 우리가 스터디하는 쿠버네티스뿐만 아니라 메소스, 마라톤등의 컨테이너 오케스트레이터를 지원한다.

scrape_configs:
	- job_name: kubernetes_sd
		kubernetes_sd_configs:
			- role: pod
		relabel_configs:
			- action: keep
				regex: hey
				source_labels:
					- __meta_kubernetes_pod_label_app

minikube status
minikube delete
minikube start --kubernetes-version="v1.14.0" --vm-driver=virtualbox --extra-config=kubelet.authentication-token-webhook=true --extra-config=kubelet.authorization-mode=Webhook --host-only-cidr 192.168.59.1/24

# prometheus 설치
kubectl apply -f ./bootstrap
kubectl get po -A -w

# kubernetes sd config
cat bootstrap/03_prometheus-configmap.yaml

#kubernetes target 확인
minikube service prometheus-service -n monitoring

#hey app 설치
kubectl apply -f ./services/
kubectl get po -A -w

서비스 디스커버리 시스템

서비스 디스커버리 시스템: 서비스 간에 서로 통신하도록 제대로 구성돼 있는지, 서비스 관리 및 모니터링 기능을 제공

Consul + Prometheus 연동 예제)

# 실습환경 구축
cd chapter12
vagrant up
vagrant status

#consul console 접속
vagrant ssh consul

#prometheus console 접속
vagrant ssh prometheus

# consul web ui: http://192.168.42.11:8500
# consult metric 확인
curl -qs localhost:9107/metrics | grep "^consul"

#console-exporter를 consul의 service로 등록
vagrant@prometheus:~$ cat /vagrant/chapter12/configs/consul_exporter/payload.json
curl --request PUT \
--data @/vagrant/chapter12/configs/consul_exporter/payload.json \
http://consul:8500/v1/agent/service/register

# consul web ui에서 자동 타겟 등록 

이재상님 발표가 끝나니 바로 김밥과 음료수가 왔네요 ^^

역시 오늘도 **데보션에서 지원**해 주셨습니다.

101 스터디 발표

101은 장병진님께서 수고해 주셨습니다.

스터디 발표 내용은 아래에 정리해 주셨습니다.

Garbage Collection

Garbage collection은 소유자가 없는 오브젝트를 찾아 삭제해주는 Kubernetes의 기능입니다.

Kubernetes에서 가비지 수집은 사용하지 않는 리소스를 자동으로 삭제하여 클러스터의 공간을 확보하는 프로세스입니다.

기본적으로 Kubernetes는 리소스를 삭제해야 하는 시기를 결정하는 미리 정의된 규칙 집합을 기반으로 가비지 컬렉션을 수행합니다.

그러나 Kubernetes 가비지 수집기를 구성하여 가비지 수집 프로세스를 사용자 지정할 수도 있습니다.

Garbage collection은 Kubernetes가 클러스터 리소스를 정리하는 데 사용하는 다양한 메커니즘을 총칭하는 용어입니다. 이렇게 하면 다음과 같은 리소스를 정리할 수 있습니다.

• Terminated pods

• Completed Jobs

• Objects without owner references (소유자 참조가 없는 객체)

• Unused containers and container images (미사용 컨테이너 및 컨테이너 이미지)

• Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete (• 소유자 참조가 없는 객체)

• Stale or expired CertificateSigningRequests (CSRs) (만료된 CSR(CertificateSigningRequests)

• Nodes deleted in the following scenarios: (노드는 다음과 같은 상황에 삭제 진행됨)

  • On a cloud when the cluster uses a cloud controller manager (클러스터가 클라우드 컨트롤러 관리자를 사용하는 경우 클라우드에서)

  • On-premises when the cluster uses an addon similar to a cloud controller manager (클러스터가 클라우드 컨트롤러 관리자와 유사한 애드온을 사용하는 경우 온프레미스)

• Node Lease objects

• *종료된 포드 (Terminated pods)**

• 포드 수명 주기

  • 전체 Pod의 단계 뿐만 아니라 Kubernetes는 Pod 내부의 각 컨테이너 상태를 추적합니다. 컨테이너 수명 주기 후크를 사용하여 컨테이너 수명 주기의 특정 지점에서 실행되는 이벤트를 트리거할 수 있습니다. 일단스케줄러 포드를 노드에 할당하면 kubelet은 다음을 사용하여 해당 포드에 대한 컨테이너 생성을 시작합니다.컨테이너 런타임. Waiting, Running및 의 세 가지 가능한 컨테이너 상태가 있습니다 Terminated.

• 실패한 포드의 경우 API 개체는 사람 또는 제어 장치프로세스는 이를 명시적으로 제거합니다.

• 제어 영역의 컨트롤러인 Pod 가비지 수집기(PodGC)는 Pod 수가 구성된 임계값( kube-controller-manager에서 결정됨)을 초과할 때 종료된 Pod( Succeeded또는 단계 포함)를 정리합니다 . 이렇게 하면 시간이 지남에 따라 포드가 생성되고 종료될 때 리소스 누수를 방지할 수 있습니다.Failed terminated-pod-gc-threshold

• PodGC 컨트롤러는 종료된 Pod(Succeeded 또는 Failed 단계를 포함)를 정리하여, 클러스터에서 불필요한 리소스 누수를 방지합니다. 이를 위해서는 kube-controller-manager 구성 파일에서 terminated-pod-gc-threshold

  옵션을 설정해야 합니다.

• kube-controller-manager.yaml edit

• terminated-pod -gc-threshold=100 (값 변경, 기본값 12,500)

• 실제 Prod에서는 얼마의 값으로 운영할까요!

--terminated-pod-gc-threshold int32     Default: 12500

종료된 포드 가비지 수집기가 종료된 포드 삭제를 시작하기 전에 존재할 수 있는 종료된 포드 수입니다. <= 0이면 종료된 포드 가비지 수집기가 비활성화됩니다.

kube-controller-manager

또한 PodGC는 다음 조건 중 하나를 충족하는 모든 Pod를 정리합니다.

1. are orphan pods(고아 포드) - 더 이상 존재하지 않는 노드에 바인딩됨,

2. are unscheduled terminating pods,(예약되지 않은 종료 포드)

3. 기능 게이트가 활성화되면 [node.kubernetes.io/out-of-service](<https://kubernetes.io/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service>)NodeOutOfServiceVolumeDetach

   
   

   로 오염된 준비되지 않은 노드에 바인딩된 파드를 종료합니다 .

   
   

   (are terminating pods, bound to a non-ready node tainted with [node.kubernetes.io/out-of-service](<https://kubernetes.io/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service>), when the NodeOutOfServiceVolumeDetach feature gate is enabled.)

Completed Jobs (완료된 작업)

• 완료된 작업에 대한 자동 정리

• Automatic Cleanup for Finished Jobs

• 작업이 완료되면 작업이 성공했는지 실패했는지 알 수 있도록 해당 작업을 API에 유지하는 것이 유용합니다(작업을 즉시 삭제하지 않음). 쿠버네티스의 TTL 애프터피니시제어 장치실행이 완료된 작업 개체의 수명을 제한하는 TTL(Time to Live) 메커니즘을 제공합니다.

• 완료 후 TTL 컨트롤러는 작업에 대해서만 지원됩니다. 이 메커니즘을 사용하여 이 예 에서와 같이 작업 필드를 지정하여 완료된 작업( Complete또는 )을 자동으로 정리할 수 있습니다 .Failed.spec.ttlSecondsAfterFinished

• Kubernetes에서 완료된 Job 리소스는 기본적으로 삭제되지 않습니다. 이러한 리소스들은 클러스터에 계속해서 존재하게 되며, 이는 클러스터의 자원을 차지하게 되고, 결국 클러스터 운영에 문제를 일으킬 수 있습니다. 이러한 이유로 Kubernetes는 자동으로 완료된 Job 리소스를 삭제할 수 있는 기능을 제공하고 있습니다.

• 자동 삭제 기능을 활성화하기 위해서는 Job 리소스를 생성할 때 .spec.ttlSecondsAfterFinished

  필드에 값을 설정해야 합니다. 이 필드에 설정한 값은 Job이 완료된 후 몇 초 후에 해당 리소스를 삭제할지 결정합니다. 이 값을 0으로 설정하면 Job이 완료된 즉시 해당 리소스가 삭제됩니다.

Objects without owner references(소유자 참조가 없는 객체)

• Kubernetes의 많은 개체는 소유자 참조를 통해 서로 연결됩니다 . 소유자 참조는 어떤 개체가 다른 개체에 종속되어 있는지 컨트롤 플레인에 알려줍니다. Kubernetes는 소유자 참조를 사용하여 컨트롤 플레인 및 기타 API 클라이언트에 개체를 삭제하기 전에 관련 리소스를 정리할 수 있는 기회를 제공합니다. 대부분의 경우 Kubernetes는 소유자 참조를 자동으로 관리합니다.

• 소유권은 일부 리소스에서도 사용하는 레이블 및 선택기 메커니즘 과 다릅니다 . 예를 들어, 서비스개체를 생성합니다 EndpointSlice. 서비스는 레이블을 사용하여 컨트롤 플레인이 EndpointSlice해당 서비스에 사용되는 개체를 결정할 수 있도록 합니다. 레이블 외에도 EndpointSlice서비스를 대신하여 관리되는 각각에는 소유자 참조가 있습니다. 소유자 참조는 Kubernetes의 다른 부분이 제어하지 않는 개체를 방해하지 않도록 도와줍니다.

Unused containers and container images (미사용 컨테이너 및 컨테이너 이미지)

• kubelet 5분마다 미사용 이미지에 대해 가비지 수집을 수행하고 1분마다 미사용 컨테이너에 대해 가비지 수집을 수행합니다. 외부 가비지 수집 도구를 사용하면 kubelet 동작이 중단되고 존재해야 하는 컨테이너가 제거될 수 있으므로 사용을 피해야 합니다.

• 미사용 컨테이너 및 이미지 가비지 컬렉션에 대한 옵션을 구성하려면 구성 파일을 사용하여 kubelet을 튜닝 하고 리소스 유형을 사용하여 가비지 컬렉션 관련 매개 변수를 변경합니다 [KubeletConfiguration](<https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration>)

• [KubeletConfiguration](<https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration>) 구성파일

• Kubelet은 IP 주소 192.168.0.8 및 포트 20250에서 서비스를 제공하고, 이미지를 병렬로 가져오고, 사용 가능한 메모리가 200Mi 미만으로 떨어지면 Pod를 제거하도록 구성됩니다. 네 개의 evictionHard 임계값 중 하나만 구성되었으므로 다른 evictionHard 임계값은 기본 제공 기본값에서 0으로 재설정됩니다. 다른 모든 Kubelet 구성 값은 플래그로 재정의하지 않는 한 기본 제공 기본값으로 유지됩니다. 구성 파일과 동일한 값을 대상으로 하는 명령줄 플래그는 해당 값을 재정의합니다.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
    memory.available:  "200Mi"

Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete(StorageClass 재확보 정책이 Delete인 동적으로 프로비저닝된 PersistentVolume)

• 회수 Recycle정책은 더 이상 사용되지 않습니다. 대신 권장되는 접근 방식은 동적 프로비저닝을 사용하는 것입니다.

• 기본 볼륨 플러그인에서 지원하는 경우 회수 정책은 볼륨에서 Recycle기본 스크럽( )을 수행 하고 새 클레임을 위해 다시 사용할 수 있도록 합니다.rm -rf /thevolume/*

• 그러나 관리자는 참조 에 설명된 대로 Kubernetes 컨트롤러 관리자 명령줄 인수를 사용하여 사용자 지정 재활용 포드 템플릿을 구성할 수 있습니다 . 사용자 지정 recycler Pod 템플릿에는 volumes아래 예와 같이 사양이 포함되어야 합니다.

• "restartPolicy: Never"를 사용하므로 컨테이너가 종료되면 Pod는 삭제됩니다.

• Pod은 BusyBox 이미지를 사용하며, 명령어는 "/scrub" 디렉토리가 존재하는 경우 해당 디렉토리를 삭제하는 것입니다.

• 이 Pod는 볼륨으로 "hostPath"를 사용합니다. "hostPath" 볼륨 유형은 호스트 머신에서 지정한 디렉토리에 Pod에서 사용할 수 있는 볼륨을 제공합니다. 이 Pod를 사용하려면 "kubectl apply" 명령을 사용하여 YAML 파일을 적용해야 합니다. 그러면 Kubernetes는 Pod를 시작하고 "vol" 볼륨에 정의된 경로를 "hostPath" 볼륨 유형의 경로로 바꿉니다.

apiVersion: v1
kind: Pod
metadata:
  name: pv-recycler
  namespace: default
spec:
  restartPolicy: Never #always, Onfailure(비정상 종료 발생 시 컨테이너를 재시작), never
  volumes:
  - name: vol
    hostPath:
      path: /any/path/it/will/be/replaced
  containers:
  - name: pv-recycler
    image: "registry.k8s.io/busybox"
    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z \\"$(ls -A /scrub)\\" || exit 1"]
    volumeMounts:
    - name: vol
      mountPath: /scrub

사용자 지정 recycler Pod 템플릿에 지정된 특정 경로는 volumes재활용되는 볼륨의 특정 경로로 대체됩니다.

Stale or expired CertificateSigningRequests (CSRs) (부실하거나 만료된 CSR(CertificateSigningRequests))

Certificates and Certificate Signing Requests

Kubernetes 인증서 및 트러스트 번들 API 는 Kubernetes API의 클라이언트가 X.509를 요청하고 획득할 수 있는 프로그래밍 인터페이스를 제공하여 X.509 자격 증명 프로비저닝을 자동화 할 수 있습니다. 인증서인증 기관(CA)에서.

트러스트 번들 배포를 위한 실험적(알파) 지원도 있습니다 .

인증서 서명 요청

기능 상태: Kubernetes v1.19 [stable]

CSR(CertificateSigningRequest) 리소스는 표시된 서명자가 인증서에 서명하도록 요청하는 데 사용되며, 그 후에 최종 서명되기 전에 요청이 승인되거나 거부될 수 있습니다.

노드 는 다음 시나리오에서 삭제됩니다.

• 클러스터가 클라우드 컨트롤러 관리자를 사용하는 경우 클라우드에서

• 클러스터가 클라우드 컨트롤러 관리자와 유사한 애드온을 사용하는 경우 온프레미스

• Node Lease objects (노드 임대 객체)

Owners and dependents (소유자 및 종속)

Kubernetes의 많은 개체는 소유자 참조를 통해 서로 연결됩니다

소유자 참조는 어떤 개체가 다른 개체에 종속되어 있는지 컨트롤 플레인에 알려줍니다. Kubernetes는 소유자 참조를 사용하여 컨트롤 플레인 및 기타 API 클라이언트에 개체를 삭제하기 전에 관련 리소스를 정리할 수 있는 기회를 제공합니다. 대부분의 경우 Kubernetes는 소유자 참조를 자동으로 관리합니다.

소유권은 일부 리소스에서도 사용하는 레이블 및 선택기 메커니즘 과 다릅니다 . 예를 들어, 서비스개체를 생성합니다 EndpointSlice. 서비스는 레이블을 사용하여 컨트롤 플레인이 EndpointSlice해당 서비스에 사용되는 개체를 결정할 수 있도록 합니다. 레이블 외에도 EndpointSlice서비스를 대신하여 관리되는 각각에는 소유자 참조가 있습니다. 소유자 참조는 Kubernetes의 다른 부분이 제어하지 않는 개체를 방해하지 않도록 도와줍니다.

Cascading deletion (계단식 삭제)

Kubernetes는 ReplicaSet를 삭제할 때 남겨진 포드와 같이 더 이상 소유자 참조가 없는 객체를 확인하고 삭제합니다. 개체를 삭제할 때 Kubernetes가 계단식 삭제 라는 프로세스에서 개체의 종속 항목을 자동으로 삭제할지 여부를 제어할 수 있습니다 . 계단식 삭제에는 다음과 같은 두 가지 유형이 있습니다.

• Foreground cascading deletion (Foreground 계단식 삭제)

  • 포그라운드 계단식 삭제(계단식 삭제라고도 함)는 Kubernetes의 기본 동작입니다. 사용자가 리소스(예: Deployment, ReplicaSet 또는 StatefulSet)를 삭제하면 API 서버는 상위 리소스를 삭제하기 전에 모든 종속 리소스(예: Pod, 서비스 및 ConfigMap)를 삭제합니다. 이렇게 하면 상위 리소스가 삭제되기 전에 모든 종속 리소스가 적절하게 정리됩니다.

  • 포그라운드 계단식 삭제는 종속 리소스가 상위 리소스보다 먼저 삭제되도록 하여 클러스터에 고아 리소스가 남지 않도록 하려는 경우에 유용합니다.

• Background cascading deletion (Background 계단식 삭제)

  • 반면 백그라운드 계단식 삭제는 상위 리소스가 삭제된 후 종속 리소스를 삭제합니다. 이는 종속 리소스를 삭제하는 데 시간이 오래 걸리고 상위 리소스를 먼저 삭제하여 삭제 프로세스 속도를 높이려는 경우에 유용할 수 있습니다.

Kubernetes를 사용하여 소유자 참조가 있는 리소스를 가비지 수집에서 삭제하는 방법과 시기를 제어할 수도 있습니다.파이널라이저.

일반적으로 포그라운드 계단식 삭제는 부모 리소스가 삭제되기 전에 종속 리소스가 적절하게 정리되도록 하기 때문에 권장되는 접근 방식입니다. 그러나 많은 수의 종속 리소스를 삭제해야 하고 삭제 프로세스 속도를 높이려는 경우와 같은 일부 경우에는 백그라운드 계단식 삭제가 유용할 수 있습니다.

Foreground cascading deletion

포그라운드 계단식 삭제에서는 삭제하려는 소유자 개체가 먼저 삭제 진행 중 상태에 들어갑니다. 이 상태에서는 소유자 객체에 다음과 같은 일이 발생합니다.

Background cascading deletion

백그라운드 계단식 삭제에서 Kubernetes API 서버는 소유자 객체를 즉시 삭제하고 컨트롤러는 백그라운드에서 종속 객체를 정리합니다. 기본적으로 Kubernetes는 포그라운드 삭제를 수동으로 사용하거나 종속 개체를 분리하도록 선택하지 않는 한 백그라운드 계단식 삭제를 사용합니다.

자세한 내용은 백그라운드 계단식 삭제 사용을 참조하세요 .

Orphaned dependents

Kubernetes가 소유자 개체를 삭제할 때 남겨진 종속 항목을 고아 개체라고 합니다 . 기본적으로 Kubernetes는 종속 개체를 삭제합니다. 이 동작을 재정의하는 방법을 알아보려면 소유자 개체 및 고아 종속 개체 삭제를 참조하십시오 .

• *Garbage collection of unused containers and images (미사용 컨테이너 및 이미지의 가비지 컬렉션)

그만큼 kubelet5분마다 미사용 이미지에 대해 가비지 수집을 수행하고 1분마다 미사용 컨테이너에 대해 가비지 수집을 수행합니다. 외부 가비지 수집 도구를 사용하면 kubelet 동작이 중단되고 존재해야 하는 컨테이너가 제거될 수 있으므로 사용을 피해야 합니다.

• *Container image lifecycle (컨테이너 이미지 수명 주기)

Kubernetes는 kubelet의 일부인 이미지 관리자를 통해 모든 이미지의 수명 주기를 관리합니다.캐드바이저. kubelet은 가비지 수집 결정을 내릴 때 다음 디스크 사용량 제한을 고려합니다.

• HighThresholdPercent

• LowThresholdPercent

구성된 HighThresholdPercent값을 초과하는 디스크 사용량은 가장 오래된 것부터 시작하여 이미지가 마지막으로 사용된 시간을 기준으로 순서대로 이미지를 삭제하는 가비지 수집을 트리거합니다. kubelet은 디스크 사용량이 LowThresholdPercent값에 도달할 때까지 이미지를 삭제합니다.

Container garbage collection (컨테이너 가비지 컬렉션)

kubelet garbage 사용자가 정의할 수 있는 다음 변수를 기반으로 사용되지 않는 컨테이너를 수집합니다.

• MinAge0

  : kubelet이 컨테이너를 가비지 수집할 수 있는 최소 기간입니다. 0로 설정하여 비활성화합니다

• MaxPerPodContainer0

  : 각 포드가 가질 수 있는 죽은 컨테이너의 최대 수입니다. 미만으로 설정하여 비활성화합니다.

• MaxContainers0

  : 클러스터가 가질 수 있는 죽은 컨테이너의 최대 수입니다. 미만으로 설정하여 비활성화합니다.

이러한 변수 외에도 kubelet 가비지는 일반적으로 가장 오래된 것부터 시작하여 식별되지 않고 삭제된 컨테이너를 수집합니다.

MaxPerPodContainer포드당 최대 컨테이너 수( )를 유지하는 것이 허용 가능한 전체 죽은 컨테이너( )를 벗어나는 MaxContainers상황에서 잠재적으로 서로 충돌할 수 있습니다 . 이 상황에서 kubelet은 충돌을 해결하기 위해 조정됩니다. 최악의 시나리오는 가장 오래된 컨테이너 로 다운그레이드하고 제거하는 것입니다. 또한 삭제된 팟(Pod)이 소유한 컨테이너는 .MaxPerPodContainerMaxContainersMaxPerPodContainerMaxPerPodContainer1MinAge

Configuring garbage collection (가비지 수집 구성)

리소스를 관리하는 컨트롤러에 특정한 옵션을 구성하여 리소스의 가비지 수집을 조정할 수 있습니다. 다음 페이지에서는 가비지 수집을 구성하는 방법을 보여줍니다.

• Configuring cascading deletion of Kubernetes objects (Kubernetes 개체의 계단식 삭제 구성)

• Configuring cleanup of finished Jobs (완료된 작업 정리 구성)

configMap

ConfigMap 은 포드에 구성 데이터를 주입하는 방법을 제공합니다. ConfigMap에 저장된 데이터는 유형의 볼륨에서 참조할 수 configMap있으며 포드에서 실행되는 컨테이너화된 애플리케이션에서 사용할 수 있습니다.

ConfigMap을 참조할 때 볼륨에 있는 ConfigMap의 이름을 제공합니다. ConfigMap의 특정 항목에 사용할 경로를 사용자 정의할 수 있습니다. 다음 구성은 log-configConfigMap을 다음과 같은 포드에 마운트하는 방법을 보여줍니다 configmap-pod.

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox:1.28
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

ConfigMap log-config은 볼륨으로 마운트되고 해당 log_level항목에 저장된 모든 콘텐츠는 path 의 Pod에 마운트됩니다 /etc/config/log_level. 

이 경로는 볼륨에서 파생되며 mountPath키 path 는 입니다 log_level.

참고

configmap은 설정 정보를 저장해놓는 일종의 저장소 역할을 한다.

configmap은 key/value 형식으로 저장이된다.

configmap을 생성하는 방법은 literal (문자)로 생성하는 방법과 파일로 생성하는 방법 두가지가 있다.

메모:

ConfigMap을 사용하려면 먼저 생성해야 합니다 .ConfigMap을 볼륨 마운트로 사용하는 컨테이너는 [subPath](https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath)ConfigMap 업데이트를 수신하지 않습니다.텍스트 데이터는 UTF-8 문자 인코딩을 사용하여 파일로 노출됩니다. 다른 문자 인코딩의 경우 binaryData.

emptyDir

볼륨 emptyDir은 Pod가 노드에 할당될 때 처음 생성되며 해당 Pod가 해당 노드에서 실행되는 동안 존재합니다. 

이름에서 알 수 있듯이 emptyDir볼륨은 처음에는 비어 있습니다. 

포드의 모든 컨테이너는 볼륨의 동일한 파일을 읽고 쓸 수 emptyDir있지만 해당 볼륨은 각 컨테이너의 동일하거나 다른 경로에 마운트될 수 있습니다. 

어떤 이유로든 포드가 노드에서 제거되면 의 데이터가 emptyDir영구적으로 삭제됩니다.

emptyDir은 Pod가 생성될때 생성되고, Pod가 삭제 될때 같이 삭제되는 임시 볼륨이다.

단 Pod 내의 컨테이너 크래쉬되어 삭제되거나 재시작 되더라도 emptyDir의 생명주기는 컨테이너 단위가 아니라, Pod 단위이기 때문에, emptyDir은 삭제 되지 않고 계속해서 사용이 가능하다.

생성 당시에는 디스크에 아무 내용이 없기 때문에, emptyDir 이라고 한다.

emptyDir의 물리적으로 노드에서 할당해주는 디스크에 저장이 되는데, (각 환경에 따라 다르다. 노드의 로컬 디스크가 될 수 도 있고, 네트워크 디스크등이 될 수 도 있다.)

emptyDir.medium 필드에 “Memory”라고 지정해주면, emptyDir의 내용은 물리 디스크 대신 메모리에 저장이 된다.

emptyDir 구성 예

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

hostPath

HostPath 볼륨에는 많은 보안 위험이 있으므로 가능하면 HostPath를 사용하지 않는 것이 가장 좋습니다. HostPath 볼륨을 사용해야 하는 경우 필요한 파일 또는 디렉토리로만 범위를 지정하고 ReadOnly로 마운트해야 합니다.

AdmissionPolicy를 통해 특정 디렉터리에 대한 HostPath 액세스를 제한하는 경우 정책이 유효하려면 마운트를 volumeMounts사용해야 합니다(MUST) .readOnly

볼륨 hostPath은 호스트 노드의 파일 시스템에서 Pod로 파일 또는 디렉터리를 마운트합니다.

필드에 대해 지원되는 값은 type다음과 같습니다.