리눅스의 패키지 매니저 종류가 많은데, 아래 두가지를 기준으로 구분할 수 있다.

• 배포판 계열
  • Debian (Ubuntu, Debian)
  • RedHat (RHEL, CentOS, Fedora)
• 패키지간 의존성 관리 여부
  
  • X (의존성 관리 안함)
    • .deb 또는 .rpm 파일 하나를 직접 설치·삭제해야함.
    • 다른 필요한 프로그램(의존성)을 자동으로 다운로드하지 못함.
  • O (의존성 자동 관리)
    • Package Repository 에서 패키지를 찾아줌.
    • 다른 필요한 프로그램(의존성)을 자동으로 다운로드 & 설치함.

정리하면 아래 표와 같다.

apt-get 과 apt 의 차이는 아래와 같다.

• apt: apt-get의 복잡한 명령어를 사용자가 쓰기 편하게 다듬은 현대적 기본 도구. (현재 Ubuntu 권장)

yum 과 dnf 의 차이는 아래와 같다.

• yum의 성능과 메모리 사용량을 개선한 차세대 도구. (현재 RHEL/Fedora 권장)

누군가 만들어놓은 helm 차트 패키지를 내 쿠버네티스 환경에서 사용하기 위해서는 artifact hub 를 사용하면 된다. argo 의 argo-cd 패키지를 내 클러스터에 적용하는 예시로 알아보자.

1. helm repo 지정

헬름 패키지를 가져올 레포지토리를 아래와 같은 커맨드로 지정한다.

$ helm repo add argo https://argoproj.github.io/argo-helm
"argo" has been added to your repositories

아래와 커맨드로 조회하면 내 서버에 "argo" 라는 이름으로 "https://argoproj.github.io/argo-helm" 주소가 지정된 것을 알 수 있다.

이제 argo-helm 에서 제공하는 패키지를 설치할 수 있는 것이다.

$ helm repo list
NAME    URL
argo    https://argoproj.github.io/argo-helm

추가로, 아래 커맨드처럼 search 를 이용하면 특정 저장소에 속한 패키지들을 조회해볼 수 있다. --versions 옵션을 주면 모든 버전을 조회할 수 있다.

$ helm search repo argo
NAME                            CHART VERSION   APP VERSION     DESCRIPTION
argo/argo                       1.0.0           v2.12.5         A Helm chart for Argo Workflows
argo/argo-cd                    10.3.3          v3.5.1          A Helm chart for Argo CD, a declarative, GitOps...
argo/argo-ci                    1.0.0           v1.0.0-alpha2   A Helm chart for Argo-CI
argo/argo-events                2.4.24          v1.9.11         A Helm chart for Argo Events, the event-driven ...
argo/argo-lite                  0.1.0                           Lighweight workflow engine for Kubernetes
argo/argo-rollouts              2.41.1          v1.9.1          A Helm chart for Argo Rollouts
argo/argo-workflows             2.0.0           v4.1.0          A Helm chart for Argo Workflows
argo/argocd-applicationset      1.12.1          v0.4.1          A Helm chart for installing ArgoCD ApplicationSet
argo/argocd-apps                2.0.5                           A Helm chart for managing additional Argo CD Ap...
argo/argocd-image-updater       1.2.4           v1.2.2          A Helm chart for Argo CD Image Updater, a tool ...
argo/argocd-notifications       1.8.1           v1.2.1          A Helm chart for ArgoCD notifications, an add-o...

2. helm template 확인하기

helm template 명령어를 사용하면 최종적으로 클러스터에 적용할 manifest(yaml) 파일을 조회할 수 있다. 이는 설치하려는 helm 차트의 템플릿 파일들에 values.yaml 의 설정값을 결합하여 로컬머신에서 최종 yaml 을 렌더링해보는 것이다. 실제 패키지를 설치하기 전에 확인하는 용도이다.

아래 커맨드는 argo-cd 8.6.4 버전을 argocd 네임스페이스에 crd 를 제외하고 적용할 때 사용되는 템플릿을 출력한다.

helm template <릴리스명> <패키지명> -n <네임스페이스명> --version <설치버전> --set <파라미터>

$ helm template argocd argo/argo-cd -n argocd --version 8.6.4 --set crds.install=false

참고: https://helm.sh/docs/helm/helm_template

3. helm 패키지 설치하기

아래와 같이 install 명령어로 클러스터에 패키지를 설치한다. 위에서 사용한 template 명령어와 옵션은 동일하며, 이미 namespace 가 생성되어있지 않은 경우 --create-namespace 옵션을 추가해야 한다.

$ helm install argocd argo/argo-cd -n argocd --version 8.6.4 --set crds.install=false --create-namespace
NAME: argocd
LAST DEPLOYED: Sat Aug 15 16:31:39 2026
NAMESPACE: argocd
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
In order to access the server UI you have the following options:
...

4. 배포된 오브젝트(Pod) 확인

아래 명령어로 클러스터에 배포된 Pod 들이 정상인지 확인한다.

$ kubectl get -n argocd pods
NAME                                                READY   STATUS    RESTARTS   AGE
argocd-application-controller-0                     1/1     Running   0          83s
argocd-applicationset-controller-7dbb95fc56-p2pss   1/1     Running   0          83s
argocd-dex-server-69d8df8478-888vm                  1/1     Running   0          83s
argocd-notifications-controller-6fffcd649-cqtqx     1/1     Running   0          83s
argocd-redis-658b7bf8c9-9cqz4                       1/1     Running   0          83s
argocd-repo-server-76cf7c8749-hccjs                 1/1     Running   0          83s
argocd-server-5f57dc6487-799lz                      1/1     Running   0          83s

파드가 점유하는 자원(CPU, memory)이 노드의 한계까지 다다르게 되면 노드 안정화를 위해 파드를 하나씩 삭제하게 된다. 이때, 기본적으로 쿠버네티스가 QoS 클래스 를 기준으로 파드를 정리하게 된다. 하지만 QoS 보다 우선순위 높은 것이 있는데, 바로 PriorityClass 이다. 즉, PriorityClass 를 (높게)지정하면 QoS 클래스가 낮더라도 노드에 더 오래 남아있을 수 있는 것이다.

1. PriorityClass 생성

아래와 같은 매니페스트로 PriorityClass 를 생성한다. PC(PriorityClass)는 namespaced: false 인 리소스이다.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
preemptionPolicy: Never # 기본값은 preemptLowerPriority
globalDefault: false # 기본값은 false 
description: "This priority class will not cause other pods to be preempted."

value 로 지정하는 숫자값이 클 수록 선점(preemption)하게 된다. 사용자가 정의할 수 있는 value 의 범위는 -2147483648 ~ 1000000000 이다. preemptionPolicy 와 globalDefault 항목에 올 수 있는 값은 다음과 같다.

주의할점은 PC 는 파드가 생성될 때를 기준으로 파드에 적용된다는 점이다. 즉, 중간에 PC를 삭제하거나 새로운 PC를 globalDefault: true 로 만들어도 기존에 동작중인 파드는 영향을 받지 않는다.

2. 파드에서 사용

아래와 같이 spec.priorityClassName 에 지정한다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  priorityClassName: high-priority

3. 불변 속성

PC 는 선점 우선순위 값인 value 를 지정하기 위해 사용하는 오브젝트인데, 이 value 항목은 수정 불가능한(immutable) 값이다. 변경하려면 오브젝트를 삭제 후 재생성하여야 한다.

4. 시스템 정의 PriorityClass

아래와 같은 커맨드로 PC 를 조회해보면, 이미 생성된 2개의 PC 가 존재함을 알 수 있다.

$ kubectl get pc
NAME                      VALUE        GLOBAL-DEFAULT   AGE   PREEMPTIONPOLICY
system-cluster-critical   2000000000   false            38d   PreemptLowerPriority
system-node-critical      2000001000   false            38d   PreemptLowerPriority

value 값이 사용자 정의 가능 범위인 1000000000 을 넘는것을 알 수 있는데, 클러스터와 노드의 핵심 컴포넌트들의 우선순위를 높이기 위해 존재하는 PC 이다.

system-cluster-critical 은 nginx, calico-cni, coredns 같은 파드를 유지시켜주며,

system-node-critical 은 kube-apiserver, kube-scheduler, kube-controller-manager 같은 파드를 유지시켜준다.

참고: https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#non-preempting-priority-class