Category: Kubernetes

2025
0
Kubernetes

Kubernetes Node 재실행 후 swap 으로 인한 kubelet 무한 재시작

최근 홈 서버에 Kubernetes 클러스터를 구성하던 중, 노드가 재실행한 후에 노드가 NotReady 상태로 떨어지며 kubelet 이 계속 재시작되는 문제를 겪었다.systemd 로그를 확인해 보니, kubelet 이 무한 재시작되며 restart counter 가 6500회를 넘는 심각한 상태였다. 🔍 문제 상황계속 재시작 되는 노드로 들어가서 kubelet 서비스 상태를 확인하면 다음과 같은 메시지가 반복적으로 출력된다. > sudo systemctl status kubelet● kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: activating (auto-restart) (Result: exit-code) since Sun 2025-11-23 10:52:13 KST; 1s ago Docs: https://kubernetes.io/docs/ Process: 150004 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS (code=exited, status=1/FAILURE) Main PID: 150004 (code=exited, status=1/FAILURE) CPU: 90ms> sudo journalctl -u kubelet -n 50 --no-pagerNov 23 10:52:54 systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE Nov 23 10:52:54 systemd[1]: kubelet.service: Failed with result 'exit-code'. Nov 23 10:53:04 systemd[1]: kubelet.service: Scheduled restart job, restart counter is at 6578. Nov 23 10:53:04 systemd[1]: Started kubelet.service - kubelet: The Kubernetes Node Agent. Nov 23 10:53:04 kubelet[150116]: Flag --container-runtime-endpoint has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information. Nov 23 10:53:04 kubelet[150116]: Flag --pod-infra-container-image has been deprecated, will be removed in a future release. Image garbage collector will get sandbox image information from CRI. Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.710817 150116 server.go:209] "--pod-infra-container-image will not be pruned by the image garbage collector in kubelet and should also be set in the remote runtime" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.715367 150116 server.go:492] "Kubelet version" kubeletVersion="v1.29.15" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.715402 150116 server.go:494] "Golang settings" GOGC="" GOMAXPROCS="" GOTRACEBACK="" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.715759 150116 server.go:924] "Client rotation is on, will bootstrap in background" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.716990 150116 certificate_store.go:130] Loading cert/key pair from "/var/lib/kubelet/pki/kubelet-client-current.pem". Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.718180 150116 dynamic_cafile_content.go:157] "Starting controller" name="client-ca-bundle::/etc/kubernetes/pki/ca.crt" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.727293 150116 server.go:750] "--cgroups-per-qos enabled, but --cgroup-root was not specified. defaulting to /" Nov 23 10:53:04 kubelet[150116]: E1123 10:53:04.727405 150116 run.go:74] "command failed" err="failed to run Kubelet: running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/s 핵심 에러 메시지는 아래 한 줄이다. running with swap on is not supported, please disable swap! 즉, swap 이 활성화된 상태에서 kubelet이 실행되고 있기 때문에 강제로 종료되고 있었던 것이다. 초기 설정때 껏는데.. 재실행되면서 켜진 모양이다. 😭 ❗ Kubernetes 는 왜 swap을 허용하지 않을까?Kubernetes 는 노드 리소스를 엄격하게 관리하기 위해 메모리 관리 정책을 자체적으로 수행한다. 하지만 swap 이 활성화되어 있으면 다음과 같은 문제가 발생한다.

0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 참고 https://wlsdn3004.tistory.com/62 앞서 말했듯이, 쿠버네티스는 사용자 정보를 저장하지 않습니다. 사용자를 관리하고 싶으면, 쿠버네티스에서 제공하는 OIDC 를 통해 별도의 인증 서버와 연계를 하면 사용자를 관리할 수 있습니다. 인증서버로 유명한 Keycloak 을 이용해 사용자를 관리하고 쿠버네티스에서 인증을 진행할 수 있도록 설정을 진행하려고 합니다. ✅ 1. Keycloak Client 추가쿠버네티스에서 Keycloak 을 이용해 인증을 진행하기 위해서는 Client 생성(등록) 이 필요합니다. Client 단위로 Keycloak 에서는 쿠버네티스 사용자들을 관리하고 권한을 매핑해줄 수 있습니다.

0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - Role 과 ClusterRole

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 쿠버네티스에서 Role과 ClusterRole은 RBAC(역할 기반 접근 제어)를 통해 사용자나 서비스 계정에 권한을 부여하는 중요한 리소스입니다. 아래에 각각의 특징과 차이점을 정리해 보았습니다. Role네임스페이스 범위: Role은 특정 네임스페이스 내에서만 유효합니다. 따라서 한 네임스페이스의 자원에만 접근 권한을 부여할 수 있습니다. 정책 정의: Role 안에는 API 리소스(예: Pods, Services 등)에 대한 특정 동작(예: get, list, create 등)이 정의되어 있습니다. 바인딩: Role은 RoleBinding을 통해 사용자나 서비스 계정에 연결됩니다. 이때 RoleBinding 역시 특정 네임스페이스에 속합니다.

0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 쿠버네티스는 사용자를 “인증”하는 방식만 알면 되고, 사용자 정보를 자체를 저장하지 않습니다. X.509 인증서 를 사용하는 방식은 사용자 인증서를 만들고 클러스터에 등록해서 인증하는 방식입니다. ✅ 1. 사용자 인증서 및 키 생성1. 개인 키 (Private Key) 생성RSA 알고리즘으로 개인 키 생성 하게 되면 dev-user.key 파일이 생성됩니다. 개인 키는 인증서 서명 요청(CSR)을 만들 때 필요하며 이후 쿠버네티스 API 서버와 통신 시 이 키로 서명된 인증서를 사용해 본인을 증명

0
Kubernetes

[쿠버네티스 DevOps 구축] - OpenSearch 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://blog.pages.kr/2844 https://opendistro.github.io/for-elasticsearch-docs/docs/security/access-control/api/#reserved-and-hidden-resources https://forum.opensearch.org/t/default-password-reset/102/10 Admin Password 변경 https://github.com/opendistro-for-elasticsearch/opendistro-build/issues/558 https://opendistro.github.io/for-elasticsearch-docs/docs/security/configuration/yaml/#internal_usersyml https://github.com/opensearch-project/helm-charts/issues/161 ✅ OpenSearch 설치# Helm Repo 추가helm repo add opensearch https://opensearch-project.github.io/helm-charts/# OpenSearch 설치helm upgrade --install opensearch \ -f ./values-opensearch.yaml opensearch/opensearch \ -n logging --create-namespace Release "opensearch" has been upgraded. Happy Helming!NAME: opensearchLAST DEPLOYED: Thu Jan 18 15:55:28 2024NAMESPACE: loggingSTATUS: deployedREVISION: 2TEST SUITE: NoneNOTES:Watch all cluster members come up. $ kubectl get pods --namespace=logging -l app.kubernetes.io/component=opensearch-cluster-master -w ✅ OpenSearch Dashboard 설치helm upgrade --install opensearch-dashboard \ -f ./values-opensearch-dashboards.yaml opensearch/opensearch-dashboards \ -n logging --create-namespace

0
Kubernetes

[쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 ✅ 메트릭 수집을 위한 Prometheus서비스를 올렸다고 해서 끝이 아니다! 서비스를 운용하는 입장에서는 시스템이 안정적인지 지속적으로 확인을 해야 하는데, 운영하는 서비스의 CPU 사용률, 메모리 사용률과 같은 메트릭 정보를 지속적으로 수집하는 시스템을 구축해야 합니다. 저는 대중적으로 많이 알려진 Prometheus 를 이용해 쿠버네티스에서 운영중인 서비스에 대한 메트릭 정보를 수집하려고 합니다. Helm 을 이용한 Prometheus 설치# helm repo 추가helm repo add prometheus-community https://prometheus-community.github.io/helm-charts# prometheus 설치helm upgrade --install -f ./values-prometheus.yaml prometheus prometheus-community/prometheus -n monitoring --create-namespace Release "prometheus" does not exist. Installing it now.NAME: prometheusLAST DEPLOYED: Fri Nov 15 10:11:47 2024NAMESPACE: monitoringSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:prometheus-server.monitoring.svc.cluster.localGet the Prometheus server URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=prometheus,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9090####################################################################################### WARNING: Persistence is disabled!!! You will lose your data when ########### the Server pod is terminated. ######################################################################################The Prometheus alertmanager can be accessed via port 9093 on the following DNS name from within your cluster:prometheus-alertmanager.monitoring.svc.cluster.localGet the Alertmanager URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=alertmanager,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9093####################################################################################### WARNING: Persistence is disabled!!! You will lose your data when ########### the AlertManager pod is terminated. ############################################################################################################################################################################# WARNING: Pod Security Policy has been disabled by default since ########### it deprecated after k8s 1.25+. use ########### (index .Values "prometheus-node-exporter" "rbac" ########### . "pspEnabled") with (index .Values ########### "prometheus-node-exporter" "rbac" "pspAnnotations") ########### in case you still need it. ######################################################################################The Prometheus PushGateway can be accessed via port 9091 on the following DNS name from within your cluster:prometheus-prometheus-pushgateway.monitoring.svc.cluster.localGet the PushGateway URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app=prometheus-pushgateway,component=pushgateway" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9091For more information on running Prometheus, visit:https://prometheus.io/ ✅ 모니터링을 위한 Grafana메트릭 수집을 위한 Prometheus 를 설치 했는데! 단순 메트릭 정보만 있으면 운영하는 입장에서 가시적으로 와 닿지 않습니다.

0
Kubernetes

[쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://kubernetes.github.io/ingress-nginx/ https://github.com/nginxinc/kubernetes-ingress https://artifacthub.io/packages/helm/ingress-nginx/ingress-nginx https://www.nginx.com/blog/guide-to-choosing-ingress-controller-part-4-nginx-ingress-controller-options/ https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal-clusters Ingress Controller 설치현재 설치된 쿠버네티스에서는 Ingress 를 생성 하더라도 외부 요청을 Ingress 설정에 맞게 외부 요청을 내부 서비스로 전달해주는 Controller 가 따로 없습니다. 다시 말해, 규칙을 생성하더라도 규칙을 읽어서 적용시켜주는 모듈이 없는 상태입니다. 보통, 클라우스 서비스에서는 ALB 나 NLB 와 같은 서비스를 이용해 Ingress 정책을 읽어 Load Balancing 규칙을 적용해주는데, 개인 쿠버네티스 서비스에서는 저런 시스템을 기대하기 힘듦으로 저는 Nginx 에서 제공해주는 Ingress Controller 를 이용하려고 합니다. Helm 설치helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace

0
Kubernetes

[쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://github.com/rancher/local-path-provisioner 🔎 로컬 쿠버네티스 동적 프로비저닝로컬 쿠버네티스 환경에서는 기본적으로 동적 PV 프로비저닝을 지원하지 않습니다. 다시 말해, 사용자가 직접 PV 를 생성한 후 PVC 에 수동으로 PV 를 연결해야 합니다. EKS 에서는 CSI 드라이버를 통해 동적 프로비저닝을 제공하는데, 로컬 환경에서 동일한 기능을 제공해주는 플러그인을 찾다가 local-path-provisioner 를 발견했습니다. 1. local-path-provisioner 설치아래 명령어를 사용해 local-path-provisioner를 설치합니다.

0
Kubernetes

[쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ https://cocococo.tistory.com/entry/k8s-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%82%AC%EC%9A%A9%EC%9D%84-%EC%9C%84%ED%95%9C-kubeadm-kubelet-%EB%B0%8F-kubectl-%EC%84%A4%EC%B9%98-%EB%B0%A9%EB%B2%95 https://jongsky.tistory.com/112 https://www.youtube.com/watch?v=Wr6nrBRqYYE 📝 회고Vitality 팀에 있을때 EKS 로 구축된 시스템을 운영했었습니다. 지금은 해당 팀이 해체 되면서 운영하고 있지는 않지만 그때 내부적으로 진행했던 프로젝트들의 기억을 되살리고자 포스트로 남기려고 합니다. 🤔 쿠버네티스 운영환경 선택지속적으로 쿠버네티스 환경을 운영도 하면서 공부도 하고 싶어 여러가지 환경을 검토해봤는데, EKS 는 일단 컨트롤 플레인 자체만으로도 한달에 7만원 정도가 나와 Pass (너무 비싸 😭), 로컬 PC 에 Minikube 를 이용하는 방법은 노트북을 너무 핫하게 만드는 방법이라 Pass 요즘 알리에서 미니 PC 가 싸게 풀리고 있고 시스템 초기 구입 비용 빼면 운용하는데는 매월 전기세만 내면 돼 크게 부담이 안될 것 같아 미니 PC 를 이용한 서버를 구축하기로 했습니다.

2023
0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - ServiceAccount

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 참고 https://findstar.pe.kr/2023/04/09/access-k8s-api-from-pod/ https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/ 🔎 ServiceAccount 란? ServiceAccount 는 쿠버네티스 API 서버와 통신하고 클러스터 내의 다른 리소스에 접근하기 위한 인증 정보를 제공합니다. ServiceAccount 는 Pod 가 Kubernetes API Server 에 인증 하기 위한 Account 입니다. 때문에 Pod 를 생성할때 ServiceAccount 를 할당해야 하며 지정하지 않을 경우 default 가 자동으로 할당됩니다. Rule 과 RuleBinding 을 이용해 ServiceAccount 에 권한을 부여함으로써 Pod 가 다른 리소스에 접근할 수 있게 해줍니다. ServiceAccount 는 Namespace 단위로 생성되는 리소스며 다른 Namespace 에서 정의된 ServiceAccount 를 사용할 수 없습니다.

0
KubernetesIstio

Istio - Istio 설치 및 addon 설치

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - istioctl Istio 란? 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ istioctl 설치Mac 을 사용하는 경우 HomeBrew 를 이용해 istioctl 을 설치할 수 있습니다. brew install istioctl 다른 OS 를 사용하거나 특정 버전의 Istio 를 사용하고 싶은 경우 다음과 같이 Istio 버전을 Setting 한 후 해당 버전을 내려받아 사용할 수 있습니다. export ISTIO_VERSION=1.14.5curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIO_VERSION TARGET_ARCH=x86_64 sh -

0
KubernetesCustom

쿠버네티스 - CustomResource

참고 https://frozenpond.tistory.com/111 CustomResourceCustom Resource는 쿠버네티스에서 사용자가 정의한 리소스를 나타냅니다. 이는 일반적으로 클러스터 내에 존재하지 않는 기본 리소스의 새로운 종류를 정의하고, 이를 통해 사용자의 애플리케이션에 특화된 동작을 수행할 수 있도록 합니다. Custom Resource 는 클러스터 상태의 일부로서 존재하며, 일반적인 리소스와 동일한 방식으로 쿠버네티스 API를 통해 작동합니다. 예를 들어, 사용자는 Custom Resource 를 생성, 조회, 수정 및 삭제할 수 있습니다. Custom Resource 를 사용하기 위해 먼저 Custom Resource Definition(CRD) 을 정의해야 합니다. CRD는 Custom Resource 의 스키마를 설명하는 쿠버네티스 API 개체입니다. 이를 통해 Custom Resource 의 구조, 필드 및 기타 특성을 정의할 수 있습니다. CRD는 일종의 템플릿으로서, Custom Resource 의 정의를 기반으로 생성됩니다. CRD를 생성하면 쿠버네티스 API 서버가 새로운 Custom Resource 타입을 이해하고 처리할 수 있게 됩니다. Custom Resource Definition 을 작성한 후, 사용자는 해당 정의를 사용하여 Custom Resource 인스턴스를 생성하고 관리할 수 있습니다. Custom Resource 인스턴스는 일반적으로 YAML 또는 JSON 형식으로 정의되며, 클러스터에 배포됩니다. 이후 Custom Resource 는 클러스터 내에서 다른 리소스와 유사하게 다룰 수 있으며, 사용자는 쿠버네티스 API를 사용하여 Custom Resource 를 조작할 수 있습니다. Custom Resource 와 Custom Resource Definition 은 쿠버네티스의 확장성과 유연성을 높여줍니다. 사용자는 쿠버네티스 API를 통해 고유한 리소스 유형을 정의하고 제어할 수 있으며, 이를 통해 자신의 애플리케이션을 더욱 쉽게 관리할 수 있습니다.

0
KubernetesAutoscaler

쿠버네티스 - CA (Cluster Autoscaler)

목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s CA

0
KubernetesAutoscaler

쿠버네티스 - VPA (Vertical Pod Autoscaler)

목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s VPA

0
KubernetesAutoscaler

[쿠버네티스] HPA - 수평적 파드 오토스캐일링

목차 쿠버네티스 - VPA (Vertical Pod Autoscaler) [쿠버네티스] HPA - 수평적 파드 오토스캐일링 HPA (Horizontal Pod Autoscaler) 이란?HPA 는 CPU 사용량, 메모리 사용량, 또는 커스텀 메트릭을 기준으로 오토스캐일링 해주는 쿠버네티스 리소스 입니다. 수평이라 붙은 이유는 오토스캐일링시 자원의 사양을 늘리는게 아닌 동일한 사양을 가진 파드의 개수를 늘리기 때문에 그렇습니다. HPA는 애플리케이션의 부하가 증가하면 파드 수를 자동으로 늘리고, 부하가 감소하면 파드 수를 줄이는 식으로 관리합니다. 이를 통해 애플리케이션의 가용성과 성능을 최적화할 수 있습니다. HPA 기본적으로 Deployment 또는 ReplicaSet 와 같은 스케일링이 가능한 컨트롤러 리소스 에만 적용이 가능합니다. (Daemonset 은 적용 불가) ✅ Metrics Server 설치HPA는 메트릭 데이터를 기반으로 동작하므로, metrics-server 가 클러스터에 설치되어 있어야 합니다. kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml