사연이 있는 코드

14. 파드의 컴퓨팅 리소스 관리

cjswoduddn — Mon, 25 Mar 2024 21:54:28 +0900

1. 파드 컨테이너의 리소스 요청

파드를 생성할 때 컨테이너가 필요로 하는 CPU와 메모리 양 제한을 지정할 수 있다
파드의 요청과 제한은 파드에 속한 컨테이너 요청과 제한의 합이다

1.1 리소스 요청을 갖는 파드 생성하기

# 리소스 요청을 갖는 파드
apiVersion: v1
kind: Pod
metadata:
  name: requests-pod
spec:
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main
    resources:
      requests:
        cpu: 200m
        memory: 10Mi

컨테이너 요청에 cpu 200m과 memory 10Mi를 지정했다
cpu를 지정하지 않으면 이미 cpu자원이 많이 할당된 경우 자원을 전혀 할당받지 못할 수도 있다.

실습환경은 2코어 머신이므로 컨테이너에 1코어, 즉 50%가 할당된 걸 보여준다
컨테이너 스펙에 제한이 아닌 요청으로 200m지정했으므로 1코어가 할당될 수 있다.

1.2 리소스 요청이 스케줄링에 미치는 영향

스케줄러는 파드를 만들 노드를 정할 때 스펙의 요청보다 높은 자원을 가진 노드를 선별한다
스케줄러는 노드를 정할 때 각 노드에 배포된 파드의 리소스 요청 총량을 확인해서 노드를 정한다(실제사용량 X)

스케줄러가 파드를 위해 최적의 노드를 선택할 때 파드의 요청을 사용하는 방법

스케줄 가능한 노드 중 최적의 노드를 찾는 알고리즘 LeastRequestedPriority, MostRequestedPriority
LeastRequestedPriority : 남은 리소스가 가장 큰 노드에 파드를 배정 => 고른 리소스 분배
MostRequestedPriority : 남은 리소스가 가장 작은 노드에 파드를 배정 => 최적의 노드 수

노드의 용량 검사

$ kubectl describe nodes

Capacity
Allocatable

=> Capacity는 노드의 총리소스이며 실제 스케줄 가능 여부는 Allocatable로 결정한다.

cpu 800m, memory 20Mi 파드를 하나 생성 후 정상적으로 running하는 모습 확인
cpu 1, memory 20Mi 파드 추가 생성 요청 시 Pending상태에서 컨테이너가 정상 동작하지 않음
describe 명령으로 requests-pod-3의 상태를 조회해보면 스케줄이 실패했음을 알 수 있다.
단, 지금까지 딱 cpu2개로 정확히 할당 가능한 만큼 요청을 했는데 실패한 이유가 있다

사용자 정의 파드 외에도 kube-system 파드가 자동으로 프로비저닝되어 노드의 자원을 사용하고 있었다.
두번째 파드를 삭제하면 스케줄러는 삭제를 통지받고 pending 상태의 파드를 스케줄링 할 수 있는지 다시 확인한다.

1.3 CPU 요청이 CPU 시간 공유에 미치는 영향

파드 A는 200m을, 파드 B는 1000m의 CPU요청량이 있고 이는 1:5 비율이다.
각자 최저 보장 자원을 받은 상태로 프로세스의 CPU사용률이 높아지면 유휴자원을 추가로 할당받는다
두 파드가 치열하게 경합할 경우 유휴자원은 요청량 비율료 1:5로 할당된다
만약 경쟁 상황이 아니면 파드 A가 유휴자원 100%를 할당 받을 수 있지만 파드B가 요청하면 바로 자원을 내준다.

1.4 사용자 정의 리소스의 정의와 요청

k8s는 사용자 정의 리소스를 노드에 추가하고 파드의 리소스 요청으로 사용자 정의 리소스를 요청할 수 있다.
노드 오브젝트의 capacity필드에 값을 추가해 값을 인식할 수 있게 한다
quantity는 정수여야 한다.
파드스펙에서 resources.requests필드로 지정할 수 있다.

2. 컨테이너에 사용 가능한 리소스 제한

2.1 컨테이너가 사용 가능한 리소스 양을 엄격한 제한으로 설정

줬다 뺏을 수 있는 CPU와 달리 메모리는 한번 주면 반납을 꼭 해야 재활용이 가능한 자원으로 컨테이너마다 메모리 제한이 필요하다.

리소스 제한을 갖는 파드 생성

# 리소스 요청을 갖는 파드
apiVersion: v1
kind: Pod
metadata:
  name: requests-pod
spec:
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main
    resources:
      limits:
        cpu: 1
        memory: 20Mi

리소스 제한 오버커밋

최소를 보장하는 리소스 요청과 달리 리소스 제한은 제한의 총량이 자원의 총량보다 많을 수 있다.
개별 컨테이너는 지정된 리소스 제한을 초과해 사용하려고 해도 종료될 수 있다.

2.2 리소스 제한 초과

CPU는 제한이 있어도 성능과 연결될 뿐 실행에는 문제가 없다
반면, 메모리는 필요한 만큼 자원을 할당받지 못하면 프로세스가 제동작을 못하므로 프로세스가 종료된다(OOM)
파드의 재시작 정책이 Always 또는 OnFailure로 설정된 경우 프로세스는 다시 실행된다
OOM으로 프로세스 재실행이 반복된다면 CrashLoopBackOff상태로 프로세스의 재실행 대기시간을 걸게 된다.

OOM으로 종료된 프로세스를 포함한 파드의 상태

2.3 컨테이너의 애플리케이션이 제한을 바라보는 방법

top 명령을 통해 확인한 used, free값은 컨테이너 메모리가 아닌 노드 메모리를 바라본다.
JVM -Xms 옵션을 설정하지 않은 경우 JVM은 노드 메모리를 기준으로 최대힙을 정하고, 애플리케이션 사용 시 컨테이너 메모리 제한을 초과해 컨테이너에 OOM이 발생할 수 있다.
-Xms옵션을 설정해도 JVM의 오프 힙 메모리에는 영향을 미치지 않는다(JVM 10 이후 -XX+UseContainerSupport)

컨테이너는 노드의 모든 CPU 코어를 본다

컨테이너 CPU제한도 컨테이너가 사용할 수 있는 CPU시간 양을 상대적으로 제한할 뿐이다.
제한된 CPU코어를 사용하는 애플리케이션에 매우 많은 스레드가 생성되어 그 CPU를 경합할 경우 작업 수행과 메모리 반납이 지연되고 이는 시스템 장애로 이어질 수 있다.
애플리케이션이 컨테이너 CPU제한을 참조하도록 하기 위해 Downward API를 이용해 그 값을 구할 수 있다

3. 파드 QoS 클래스 이해

리소스 제한 총합은 전체 리소스보다 클 수 있고 서로 다른 애플리케이션이 실행될 때 이 값을 초과한 경우가 생길 수 있다. 이때 어떤 파드를 종료시키고 어떤 파드에게 리소스를 할당할지 결정하는 정책이 QoS(Quality of Service)다.

BestEffort(최하위 우선순위)
Burstable
Guaranteed(최상위 우선순위)

3.1 파드의 QoS 클래스 정의

=> QoS클래스를 파드에 직접 설장하는 게 아닌 파드 컨테이너의 리소스 요청과 제한의 조합에서 파생된다.

BestEffort 클래스에 파드를 할당하기

우선순위가 제일 낮으며 아무런 리소스 요청과 제한이 없는 파드에 할당된다
최악의 경우 CPU를 전혀 할당받지 못한다.
다른 파드를 위해 즉시 메모리를 해제 후 종료될 수 있다
메모리 제한이 없으므로 여유가 있는 리소스 환경에서 가장 많이 자원을 활용한다

Guaranteed 클래스에 파드 할당하기

리소스 요청과 제한을 동일하게 설정한 경우 더많이도 못받지만 반드시 그 제한은 보장해준다
요청을 생략하면 제한과 동일하므로 제한만 설정해도 Guaranteed를 보장한다.
또한 한 파드에 속한 모든 컨테이너가 리소스 제한과 요청을 지정해야 한다.

Burstable QoS 클래스에 파드 할당하기

BestEffort와 Guaranteed 사이에 Burstable가 있다.
리소스제한과 요청이 일치하지 않는 경우, 제한과 요청을 지정하지 않은 컨테이너를 포함한 파드인 경우
Burstable 파드는 요청한 양만틈의 리소스를 얻지만 필요하면 추가 리소스를 할당받을 수 있다.

컨테이너 QoS 클래스 파악

다중 컨테이너 파드의 QoS 클래스 파악

다중 컨테이너 파드의 경우 만장일치인 경우만 그 정책대로 가고 한 컨테이너라도 정책이 다르면 Burstable다.

3.2 메모리가 부족할 때 어떤 프로세스가 종료되는지 이해

시스템이 오버커밋되면 QoS클래스는 어떤 컨테이너를 먼저 종료할지 결정하고 해제된 리소스를 높은 우선순위 파드에 준다.
BestEffort를 먼저 종료하고 Burstable, 마지막으로 시스템 프로세스가 메모리를 필요로하면 Guaranteed 파드가 종료된다.

QoS 클래스가 우선순위를 정하는 방법 이해

기본적으로 클래스의 우선순위 대로 파드의 프로세스를 종료시킨 뒤 자원을 회수한다
동일한 클래스인 경우 프로세스의 OOM점수를 정하고 가장 높은 프로세스를 종료시킨다.
위 예시에서 OOM점수는 메모리 요청량 대비 메모리 사용량인 메모리 비율이 높은 파드B를 파드C보다 먼저 kill한 케이스다.

4. 네임스페이스별 파드에 대한 기본 요청과 제한 설정

4.1 LimitRange 리소스 소개

모든 컨테이너 시소스 요청과 제한을 설정하는 대신 LimitRange 리소스를 생성해 이를 수행할 수 있다.
LimitRange는 컨테이너의 네임스페이스 별 리소스에 최소/최대 제한을 지정하고 명시하지 않으면 디폴트를 지정한다
LimitRange는 LimitRanger 어드미션 컨트롤 플러그인에서 사용된다
파드 매니페스트가 API 서버에 게시되면 LimitRanger플로그인이 파드 스펙을 검증한다.

4.2 LimitRange 오브젝트 생성하기

# LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: poi-limit
spec:
  limits:
  - type: Pod
    min:
      cpu: 50m
      memory: 5Mi
    max:
      cpu: 1
      memory: 1Gi
  - type: Container
    defaultRequest:
      cpu: 100m
      memory: 10Mi
    default:
      cpu: 200m
      memory: 100Mi
    min:
      cpu: 50m
      memory: 5Mi
    max:
      cpu: 1
      memory: 1Gi
    maxLimitRequestRatio:
      cpu: 4
      memory: 10
  - type: PersistentVolumeClaim
    min:
      storage: 1Gi
    max:
      storage: 10Gi

파드 단위로 리소스 제한을 설정한다
컨테이너의 기본 리소스 요청과 제한을 지정할 수 있다
컨테이너의 리소스를 제한하고, cpu와 memory의 비율로 제한을 설정할 수 있다.
PVC가 요청하는 스토리지의 최대, 최소 용량을 제한할 수 있다.
LimitRange는 기존 리소스의 제한을 검증하지 않고 이후 생성되는 리소스만 검증한다.
LimitRange는 본인이 속한 네임스페이스에서만 동작한다.

4.3 강제 리소스 제한

$ kbc create -f pod.yaml
The Pod "poid" is invalid:
* spec.containers[0].resources.requests: Invalid value: "20Gi": must be less than or equal to memory limit
* spec.containers[0].resources.requests: Invalid value: "1": must be less than or equal to cpu limit

4.4 기본 리소스 요청과 제한 적용

$ kbc describe po poid

  Limits:
      cpu:     200m
      memory:  100Mi
    Requests:
      cpu:        100m
      memory:     10Mi
      
$ kbc create -f po poid -n poi
$ kbc describe po poid

파드 manifast에 리소스 요청과 제한을 지정하지 않아도 describe에 내용이 나온다.
default 네임스페이스가 아닌 poi 네임스페이스에서는 요청과 제한에 대한 내용이 안나온다.

단, LimitRange는 생성되는 개별 파드나 컨테이너에만 적용된다. 즉, 제한에 걸리지 않는 파드가 계속 늘어나면 노드 또는 클러스터 전체 리소스는 한계치까지 사용될 수 있다

5. 네임스페이스의 사용 가능한 총 리소스 제한하기

5.1 ResourceQuota 오브젝트 소개

리소스쿼터 어드미션 컨트롤러 플러그인은 생성 중인 파드가 설정된 리소스쿼터를 초과하는지 확인한다
LimitRange와 마찬가지로 기존 생성되어 있던 파드에 대해서는 적용되지 않는다
리소스쿼터는 네임스페이스에서 파드가 사용할 수 있는 컴퓨팅 리소스양와 PVC 스토리지 양을 제한한다.
또한 그 총 개수를 제한할 수 있다

CPU 및 메모리에 관한 리소스쿼터 생성

# CPU와 메모리에관한 리소스쿼터

apiVersion: v1
kind: ResourceQuota
metadata:
  name: cpu-and-mem
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi

ResouceQuota는 네임스페이스 단위로 적용된다
네임스페이스에 속한 리소스의 총량에 대해 제한한다.

쿼터와 쿼터 사용량 검사

$ kbc describe quota

Name:            cpu-and-mem
Namespace:       default
Resource         Used   Hard
--------         ----   ----
limits.cpu       200m   600m
limits.memory    100Mi  500Mi
requests.cpu     100m   400m
requests.memory  10Mi   200Mi

=> describe quota를 입력하면 네임스페이스에 허용된 리소스양과 사용중인 리소스양을 확인할 수 있다.

리소스쿼터와 함께 LimitRange생성

=> LimitRange는 단독으로 만들고 적용할 수 있지만 ResourceQuota만 만든 네임스페이스에서 파드는 생성할 수 없다.

Error from server (Forbidden): error when creating "pod.yaml": pods "poid" is forbidden: failed quota: cpu-and-mem: must specify limits.cpu,limits.memory,requests.cpu,requests.memory

5.2 퍼시스턴트 스토리지에 관한 쿼터 지정하기

# 스토리지에 대한 리소스쿼터

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage
spec:
  hard:
    requests.storage: 500Gi
    ssd.storageclass.storage.k8s.io/requests.storage: 300Gi
    standard.storageclass.storage.k8s.io/requests.storage: 1Ti

네임스페이스의 모든 스토리지 양은 500Gi로 설정한다
각 PVC는 특정 스토리지클래스에 프로비저닝할 수 있으므로 각 스토리지 클래스 별로 스토리지 제한을 개별적으로 줄 수 있다.

5.3 생성 가능한 오브젝트 수 제한

apiVersion: v1
kind: ResourceQuota
metadata:
  name: objects
spec:
  hard:
    pods: 10
    replicationcontrollers: 5
    secrets: 10
    configmaps: 10
    persistentvolumeclaims: 4
    services: 5
    services.loadbalancers: 1
    services.nodeports: 2
    ssd.storageclass.storage.k8s.io/persistentvolumeclaims: 2

리소스쿼터는 네임스페이스 내 각 리소스의 개수를 제한할 수 있다
또한 리소스쿼터 자체에 대한 개수를 제한할 수 있다.

5.4 특정 파드 상태나 QoS 클래스에 대한 쿼터 지정

쿼터는 쿼터범위(BestEffort, NotBestEffort, Terminating, NotTerminating)로 지정해 사용할 수 있다.
BestEffort는 파드의 QoS가 BestEffort인 파드에, NotBestEffort는 나머지 QoS 클래스를 가진 파드에 적용한다
Terminating은 파드스펙에 activeDeadlineSeconds가 설정된 파드에 적용된다.
각 파드가 종료되고 실패로 표시되기 전에 얼마나 오래 실행할 수 있는지 지정할 수 있다.(activeDeadlineSeconds)

# BestEffort/NotTerminating 파드에 대한 리소스쿼터

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort-notterminating-pods
spec:
  scopes:
  - BestEffort
  - NotTerminating
  hard:
    pods: 4

scope가 BestEffort가 지정된 경우 리소스에 대한 제한은 지정할 수 없다.

6. 파드 리소스 사용량 모니터링

과도한 리소스 요청은 서비스 장애를 일으키고 과도한 리소스 제한은 리소스 낭비를 초래한다.
예상되는 부하 수준에서 컨테이너의 실제 리소스 사용량을 모니터링해 적정 요청, 제한을 찾아야 한다.

6.1 실제 리소스 사용량 수집과 검색

cAdvisor 에이전트는 노드에서 실행되는 개별 컨테이너와 노드 전체의 리소스 사용 데이터를 수집한다.
전체 클러스터에서 이러한 통계를 주앙에서 수집하려면 힙스터라는 추가 구성요소를 실행해야 한다.(최신은 매트릭 서버)
힙스터는 노드 중 하나에서 파드로 실행되며 쿠버네티스 서비스를 통해 노출돼 IP로 접속이 가능하다.

# 매트릭 조회를 위해 필요한 리소스 매니페스트

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  - configmaps
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-insecure-tls
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        image: k8s.gcr.io/metrics-server/metrics-server:v0.4.2
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: https
            scheme: HTTPS
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 4443
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: https
            scheme: HTTPS
          periodSeconds: 10
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: {}
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

클러스터 노드의 CPU 및 메모리 사용량 표시

$ kbc top node

NAME                              CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
dkosv3-poi-cluster-ingress-5bzg   93m          2%     2786Mi          37%
dkosv3-poi-cluster-master-1       860m         22%    3705Mi          51%
dkosv3-poi-cluster-worker-47hn    112m         2%     3432Mi          46%
dkosv3-poi-cluster-worker-b7cl    119m         3%     3435Mi          46%
dkosv3-poi-cluster-worker-pbbl    259m         6%     3604Mi          48%

개별 파드의 CPU와 메모리 사용량 표시

$ kbc top pod --all-namespaces

NAMESPACE       NAME                                                  CPU(cores)   MEMORY(bytes)
default         demon-4sxsh                                           1m           244Mi
default         kubia-hostport                                        0m           8Mi
default         pod-add-settime-capability                            0m           0Mi
default         pod-as-user-guest                                     0m           0Mi
default         pod-drop-chown-capability                             0m           0Mi
default         pod-privileged                                        0m           0Mi
default         pod-with-host-network                                 0m           0Mi
default         pod-with-host-network-poi                             0m           0Mi
default         pod-with-host-pid-and-ipc                             0m           0Mi
default         pod-with-readonly-filesystem                          0m           0Mi
default         pod-with-shared-volume-fsgroup                        0m           1Mi
default         pod-with-shared-volume-fsgroup-poi                    0m           2Mi
default         poi-deployment-578dc868d9-cnjsj                       2m           134Mi
default         poi-deployment-578dc868d9-sckpm                       1m           138Mi
default         poi-deployment-578dc868d9-v9m74                       1m           133Mi
default         poid                                                  200m         61Mi
ingress-nginx   ingress-nginx-controller-poi-jrtrf                    3m           93Mi
kakao-system    fluentd-auditlog-pwcdq                                2m           89Mi

...

6.2 기간별 리소스 사용량 통계 저장 및 분석

top 명령은 현재 리소스 사용량만 표시해서 기간 별 리소스 집계가 안된다
일반적으로 집계를 위해 저장은 인플럭스DB를, 시각화를 위해 그라파나를 사용한다

[부록1] 각 리소스가 연결되는 방식

cjswoduddn — Sun, 9 Apr 2023 17:58:10 +0900

** 클러스터마다 연결방식이 상이할 수 있다.

클라이언트와 Ingress Controller(Pod)

도메인은 Ingress Node의 IP를 매핑했다. 즉, 노드포트로 들어온 클라이언트의 요청이 Ingress Controller라는 파드로 간다. (이것만 확인하면 됨)

Ingress Controller와 Ingress

$ kubectl describe ingresses poi-ingress

명령어로 확인해보면 Ingress의 Annotations를 확인할 수 있는데 여기서 kubernetes.io/ingress.class: poi라는 key value가 ingress-controller의 레이블에 있어야 한다. 반드시 key가 kubernetes.io/ingress.class에 대응하는 value가 같아야 하는데 자세한 건 차차 공부하면서 추가!

Ingress와 Service, Pod

Ingress의 정의부에 Service를 지정하고 Service와 Pod는 레이블로 매핑된다.

도커 빌드 오류(arm vs amd)

cjswoduddn — Sat, 8 Apr 2023 20:20:29 +0900

문제 상황

새로 받은 맥북에서 신나는 마음으로 간단한 웹서버를 빌드한 뒤 도커이미지를 만들어 배포했다. 그다음 컨테이너를 실행하는 파드를 만들었는데 위처럼 계속 파드 생성에 실패했다.

생각 정리

- 도커를 실행하는 환경 : amd

- 도커를 빌드한 환경 : arm

빌드할 환경을 실행할 환경으로 맞춰줘야 겠구나!

해결

$ docker buildx build --platform=linux/amd64 -t poistargram/port .
$ docker inspect poistargram/port

빌드할 때 실행환경인 amd 기반으로 빌드하도록 옵션을 넣어준다!(간단)

arm VS amd

M1칩은 arm 기반, Intel칩이 amd 기반이다. 이름도 비슷해서 매우 헷갈릴 것 같다.

간단하게 해결한 것처럼 적었지만 jdk버전 변경, 파드 에러 로깅 등등 헛다리를 오래 짚어 해결하는 데 4시간은 걸린 것 같다.

Spring @RequestScope 빈 스코프

cjswoduddn — Sun, 7 Aug 2022 16:48:37 +0900

스프링에서 관리하는 빈의 스코프는 기본값이 싱글톤이다. 웹애플리케이션을 운영하는 경우 사용자마다 다른 데이터를 갖고 서버에 진입할 수 있고 다른 데이터를 갖는다면 싱글턴빈으로는 그 값을 표현할 수 없다. 사용자마다 다른 데이터를 갖는 빈을 마치 스프링이 관리하는 싱글턴 빈처럼 사용할 수는 없을까?

@RequestScope 사용

@Component
@RequestScope
@Setter
@Getter
public class HttpRequest{

    private String headerMessage;
    private int count;

}

@Slf4j
@RequiredArgsConstructor
@RequestMapping
@RestController
public class TestController {

    private final HttpRequest request;

    @GetMapping
    public void test(){
        request.setCount(request.getCount()+1);
        log.info("count : {} ", request.getCount());
    }

}

HttpRequest에 @RequestScope 애너테이션을 붙여 스코프를 명시해주고 @Component를 붙여 빈으로 등록해준다. 그다음 빈을 주입받길 원하는 빈 TestController에 원래 하던 것처럼 HttpRequest를 주입해주고 매핑할 메서드에 request의 카운트를 늘려준다.

TestController에 주입해준 HttpRequest가 싱글턴이라면 count의 값은 매 요청마다 1씩 늘어나면서 출력할 거고, 매번 새로운 빈이라면 아무리 요청을 계속 넣어도 1만 출력할 거다.

curl을 이용해 테스트해보면 count는 계속 1로 찍히는 걸 확인할 수 있다.

의문점

근데 곰곰이 생각해보면 TestController에 final키워드로 붙은 HttpRequest에 매번 새로운 빈을 컨테이너가 주입해주는 게 말이 될까? 말 안된다. 로그에 HttpRequest의 해시코드를 추가로 출력해보자.

@Slf4j
@RequiredArgsConstructor
@RequestMapping
@RestController
public class TestController {

    private final HttpRequest request;

    @GetMapping
    public void test(){
        request.setCount(request.getCount()+1);
        log.info("hashCode : {}, count : {} ", request.hashCode(), request.getCount());
    }

}

...?

HttpRequest의 해시코드값이 매번 같은 값으로 나온다. 즉, TestController에 최초로 주입된 HttpRequest는 분명 싱글턴으로 동작하고 있다. 생각해보면 curl로 요청이 들어갈 때 HttpRequest의 생명주기가 시작되는데 TestController는 애플리케이션이 부팅되는 시점에 생성되고 그에 맞게 최초 HttpRequest또한 생겨야 정상인 거다.

엄밀히 말하면

디버거를 통해 주입된 HttpRequest를 까보면 이상한 걸 알 수 있다. 결론부터 말하자면 TestController 에 주입된 HttpRequest는 스프링이 HttpRequest에 붙은 애너테이션 @RequestScope를 보고 프록시 싱글턴빈을 생성해 주입한 빈이다. 실제로 우리가 의도한 대로 사용할 HttpRequest(count = 1을 응답해주는)는 빈 사용 시점까지 생성을 지연시킨다.

마치며

@RequestScope와 Intercepter를 잘 활용하면 웹 애플리케이션의 유저 별 정보나 로그찍기를 깔끔하게 할 수 있을 것 같다. 다만, 비지니스 코드에 직접 빈을 주입하는 건 스프링에 대한 지식이 많이 필요하므로 부적절한 것 같기도 하다.(애초에 스프링 애너테이션은...?)

프록시를 생성하는 과정을 좀 더 파보고 싶지만 이 과정 또한 문맥에 맞게 Lazy Propagation하도록 하자 ^^....

1장 쿠버네티스 소개

cjswoduddn — Wed, 29 Jun 2022 22:35:01 +0900

컨테이너의 이해

가상머신

작은 단위의 애플리케이션에 각각의 가성머신을 제공

애플리케이션의 개수가 많아지면서 하드웨어 리소스, 관리 리소스가 같이 커짐

리눅스 컨테이너

동일한 호스트 시스템에서 여러개의 서비스를 실행

서로 다른 환경이지만 가상머신에 비해 리소스가 훨씬 적음

도커 개념 이해

도커는 애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼

애플리케이션을 전체 환경과 함께 패키징

도커의 주요 개념

- 이미지 : 애플리케이션과 환경을 패키징

- 레지스트리 : 도커 이미지를 공유하는 클라우드

- 컨테이너 : 도커 기반 컨테이너 이미지에서 생성된 리눅스 컨테이너

1. 개발자는 생성한 이미지를 레포지토리로 전송

2. 다른 개발자는 만들어진 이미지를 로컬로 다운

3. 로컬의 도커를 이용해 다운 받은 이미지로 컨테이너 생성

쿠버네티스 맛보기

- 시스템은 마스터와 워커로 구성

- 애플리케이션 메니피스트를 마스터에 게시하면 마스터가 애플리케이션을 워커노드 클러스터에 배포

- 마스터는 컨트롤 플레인 실행

- 워커는 컨테이너를 실행

컨트롤 플레인

- 쿠버네티스 API 서버

- 스케줄러는 애플리케이션의 배포를 담당

- 컨트롤러 매니저

- Etcd는 분산 데이터 저장소

워커 노드

컨테이너화된 애플리케이션을 실행하는 시스템

- 도커

- API 서버와 통신하고 노드의 컨테이너를 관리하는 Kubelet

- 애플리케이션 네트워크 트래픽을 로드밸런싱하는 쿠버네티스 서비스 프록시(kube-proxy)

- 앱디스크립터를 컨트롤 플레인에 전달

- 컨트롤 플레인은 앱디스크립터를 해석해서 노드를 스케줄링

- 노드에서 필요한 이미지는 도커가 이미지 레지스트리에서 읽어옴

- 노드가 활성화되고 컨트롤플레인은 지속적으로 디스크립터 대로 앱이 떠있는지 확인

- 애플리케이션의 복제본 수는 런타임에 변경이 가능

[mac] java 터미널 버전 변경하기

cjswoduddn — Sun, 27 Mar 2022 12:20:40 +0900

들어가며

사내에서 사용하는 java 버전은 1.8과 11이다. 각 프로젝트마다 java 버전을 설정해 컴파일할 수 있도록 intellij가 옵션을 제공해서 큰 불편함 없이 사용할 수 있다. 최근에 이러한 걸 크게 신경쓰지 않고 개발하다가 운영환경에서 빌드 할 때 에러를 맛보았다. 바로 프로젝트 빌드 결과물을 외부 저장소에 올릴 때 생긴 문제였다. 로컬에서 컴파일한 .jar파일을 외부에 올리는데 이때 컴파일하는 건 터미널에 설정된 java버전으로 하게 된다. 1.8로 빌드해야할 프로젝트를 11버전으로 빌드한 후 외부저장소에 올리고 그걸 다운받아 사용하는 프로젝트에서 버전이 맞지 않아 컴파일 오류가 발생하게 된 것이다. 서론이 길었는데 시스템의 java 버전을 확인하고 바꾸는 방법을 남겨보자.

버전 확인하기

java -version으로 현재 11버전임을 확인할 수 있다.

로컬에 다운로드한 java 버전 확인하기

/usr/libexec/java_home -V로 11버전과 1.8버전이 다운로드 되어 있는 걸 확인할 수 있다.

java 버전 변경

export 명령을 통해 java의 버전을 바꾸었다. 다만, 이 방법은 터미널을 나갔다 들어오면 다시 원래 버전으로 돌아오는 단점이 있다.

java 기본버전 변경

아까 사용한 버전 확인 명령어로 내 java의 위치를 파악한다.

에디터로 .bash_profile파일을 열고,

export 명령어를 입력해준 뒤

source를 통해 배시를 활성화한 뒤 버전을 확인해주면 끝~

참고

https://java.tutorials24x7.com/blog/how-to-switch-java-version-on-mac

Gradle 기본 꿀팁 정리

cjswoduddn — Sat, 12 Mar 2022 14:10:53 +0900

gradle 버전 확인하기

- gradlew가 있는 디렉토리 경로에서 ./gradlew --version 입력 후 확인

gradle의 캐싱

프로젝트를 실행할 때 gradle은 내부적으로 두 가지 캐시를 먼저 참조한다. 첫번째로 외부라이브러리에 대한 캐시인데 우리가 외부레파지토리에서(nexux, mavenRepository...) 의존성을 다운받은 라이브러리다. 보통 [~/.gradle/cache/modules-2/files-2.1] 경로에 쫙 있는 걸 확인할 수 있다. 다음으로는 내가 작성한 자바파일의 컴파일된 버전이다.

위 설정에서 build and run using을 intelliJ IDEA 또는 Gradle로 설정할 수 있는데 intellij로 설정할 경우 프로젝트 디렉토리 하위에 out디렉토리가 생겨 컴파일된 클래스 파일을 캐싱하고, gradle로 설정할 경우 build 또는 target디렉토리에 캐싱을 하게 된다.

[정리하는 내용이 있을 때마다 추가예정 ^^]

[java] 슈퍼타입토큰(super type token)

cjswoduddn — Sat, 1 Jan 2022 16:25:35 +0900

모든 글은 토비의 봄 채널을 보며 작성하였습니다.

https://www.youtube.com/watch?v=01sdXvZSjcI&t=1973s&ab_channel=TobyLee

배경

RestTemplate를 사용하다보면 파라미터바인딩을 위한 타입토큰을 넘겨주는 부분에서 생소한 ParameterizedTypeReference를 사용한 걸 볼 수 있다. 클래스 이름과 생김새를 보면 대충 아 바인딩 되길 원하는 타입을 저 안에 넣고 요청을 날리면 되겠구나 싶다. 근데 이상한 건 생성자로 성성했는데 왜 마지막에 {}가 붙냐는 것이다. 이번 기회에 파헤쳐보자.

타입토큰(Type Token)

RestTemplate을 통해 요청을 보낼 때 그 반환 타입을 타입토큰 형식으로 넘겨주는 걸 볼 수 있다. RestTemplate은 rest api를 이용해 다른 서버에게 요청을 하고 그 내용은 HTTP의 body로 넘어오게 된다(대부분 JSON). 이때 JSON으로 넘어온 값의 key, value를 map에 다시 보관하게 되고 그 map의 내용을 어떤 객체에 바인딩할지 정보가 필요하다. 당연히 RestTemplate에서 메서드롤 호출하는 지점의 반환값으로 런타임에 추측하는 건 말이 안된다. 그러기에 어떤 객체를 바인딩해야할지 정보를 담은 타입토큰을 파라미터로 넘겨주는 것이다.

다만, 반환받길 원하는 타입이 제네릭을 포함하고 있다면 문제가 된다. 자바의 언어적 이유로(나중에 여유되면 조사) 타입토큰은 제네릭 정보를 포함해서 넘길 수 없다. 말했듯이 메서드 호출 시점에 forObject에 대한 제네릭 타입을 코드에 적어줘도 RestTemplate은 객체 바인딩 시점에 SpecialDto를 바인딩해야함을 알 수 없다. 그래서 실제 forObject의 내부를 디버깅해보면 제네릭으로 SpecialDto가 들어가야할 지점에 LinkedHashMap이 들어가게 된다. 차라리 이게 익셉션을 날리는 구조였으면 나았을 것 같은데 이상하게 실행은 잘되고, 제네릭을 꺼내 쓸 때가 되어야 ClassCastException이 나게 된다.

슈퍼타입토큰(Super Type Token)

이 문제를 해결할 방법은 슈퍼타입토큰이다. 위처럼 인스턴스 생성 시점에 제네릭 정보를 넘기는 방식을 살펴보면, 컴파일러가 컴파일 시점에 모든 제네릭 타입을 로타입으로 바꾸고 강제타입캐스팅을 적용한 방식이다. 그래서 타입토큰은 제네릭을 구분하여 보낼 방법이 없는 것이다. 그렇다면 클래스를 제네릭 정보를 포함한 클래스를 상속한 클래스는 그 정보를 갖고 있을까? 갖고 있다. 상속한 클래스가 제네릭정보를 갖고 있다면 그 정보는 런타임에도 접근할 수 있는 정보가 된다. 이제 이 개념을 활용하면 리플렉션을 통해 그 타입을 가져올 수 있다.

이 개념을 갖고 위에서 보이는 ParameterizedTypeReference의 생성코드를 보면 상속한 클래스의 타입을 리플렉션해서 필드에 저장하는 걸 확인할 수있다. 단, 이 방식이 유효하려면 인스턴스 ParameterizedTypeReference의 인스턴스를 생성해 리플렉션 하는 게 아닌 ParameterizedTypeReference클래스를 상속한 익명클래스를 만들어서 그 익명클래스를 리플렉션하고 그 안에 있는 제네릭 정보를 빼와야 함을 알 수 있다.

AnonymousClass extends ParameterizedTypeReference<GenericDto<SpecialDto> {} ...

즉, 위 코드블럭에 나온 AnonymousClass를 리플랙션해야 정확하게 GenericDto속 SpecialDto까지 알아낼 수 있는 것이다.

마무리

이제 RestTemplate에서 왜 ParameterizedTypeReference을 넘기는지, 또 왜 생성시점에 {}를 넣어주는지(익명클래스 생성을 위함) 정확하게 알겠다 ^^

Spring 에러 핸들링

cjswoduddn — Sat, 2 Oct 2021 18:05:51 +0900

들어가며

웹애플리케이션 API서버를 만들 때 서버 퀄리티를 결정하는 건 인증과 에러처리라고 생각한다. 인증은 그 방식이 무수히 많고 깊이도 어마어마하지만 인증은(스프링 한정) 어느정도 정형화된 패턴이 있다. 스프링이 어떤 방식으로 에러를 핸들링하는지 그 방식을 커스텀하는 방법은 무엇인지 알아보자^^

@ExceptionHandler

이런식으로 컨트롤러에서 에러를 핸들링하는 메서드 위에 @ExceptionHandler 에노테이션을 붙여주면 잘 동작한다. 다만, 핸들링을 추가하려면 반드시 컨트롤러 수정이 필요하고 핸들링 범위가 딱 해당 컨트롤러만 적용된다는 점이 단점이다.

HandlerExceptionResolver

spring에서 기본적으로 제공하는 에러핸들러이고 커스텀해서 이용하는 방법도 있다. HandlerExceptionResolver를 구현한 객체를 빈으로 등록하면 스프링의 에러핸들링리스트에 추가되고 조건을 충족하는 경우 발동하는 매카니즘이다. 기본반환형이 ModelAndView여서 json형태로 리턴하려면 MappingJackson2JsonView를 빈으로 등록해줘야한다(이거 동작방식은 추후 조사하는 걸로..^^)

이러면 모든 컨트롤러에 대해서 발생한 에러는 이 핸들러를 반드시 거치게 된다.

마치며

좀 오래된 방식이긴 하지만 핸들링될 에러가 너~무 다양하지 않다면 괜찮은 방식인 것 같다. 관심의 분리 차원에서?? 학부 때라면 열정을 갖고 좀더 세세하게 봤겠지만 주말이라 그런 열정이 안 나온다.. ㅠㅠ 추후 살을 더 붙이는 걸로 가자.

Git 복잡한 상황 해결

cjswoduddn — Wed, 4 Aug 2021 19:12:19 +0900

회사에 다니기 전 혼자 개발할 때는 깃과 깃헙을 단순하게 활용했다. 협엽을 위한 버전관리 도구보다는 그저 ssh를 이용한 클라우드 활용하기 정도였다. 생각없이 커밋, 푸시, PR한 과거를 복구하면서 정리해보자.

현재 상황

- 개발을 위한 로컬브랜치 생성

- 열심히 개발 및 무지성 커밋(대략 5번, 커밋메세지 무지성 "tmp")

- 마스터와 싱크를 맞추기 위해 무지성 git merge master

- github에 push 후 master에 Pull Request

문제점

- master와 싱크를 맞추는 과정

- 무지성 커밋과 무지성 메세지

본인만 이해할 법한 그림이지만 어쨌든 문제상황을 만들었다. test/second에서 커밋한 내용을 PR하고 main에 합쳤다. 그리고 main에서 그 내용을 가져왔기 때문에 origin & main이 동일한 레퍼런스를 가리키고 있음을 알 수 있다. 이때 test/first에서 main과 싱크를 맞추기 위해 머지를 한 그림이고 이전에 무지성 3회커밋을 확인할 수 있다.

어떻게 해결할 것인가

1) main과 merge하기 전으로 reset시킨다

2) 여러 커밋로그를 하나로 rebase하고 의미있는 메세지를 적는다

3) 커밋을 임시로 취소하고 stash를 통해 임시 저장한다

4) local main에서 origin을 pull해서 main먼저 싱크를 맞춘다

5) 문제의 브랜치를 main으로 reset해서 싱크를 맞춘다

6) stash를 pop하여 깔끔한 상태로 만든 뒤 다시 커밋 후 푸시한다^^

나중에 또 볼 것 같은 예감이 드니 아주 천천히 자세히 정리하도록 한다.

1) main과 merge하기 전으로 reset시킨다

우선 test/first브랜치에서 git log --oneline를 입력하면 아래처럼 커밋 내역을 간단하게 확인할 수 있다.

git reset --hard lognumber를 통해 간단하게 머지 전으로 돌아가주자

2) 여러 커밋로그를 하나로 rebase하고 의미있는 메세지를 적는다

우선 무지성 커밋 3개를 하나로 합치자. 현재 HEAD로부터 3개를 합치고 싶기 때문에 아래와 같이 입력한다

git rebase -i HEAD~3

참으로 다양한 명령어가 있는데 적절히 읽어보고 사용하면 될 듯하다. 본인은 squash를 이용해 첫 커밋에 이후 두 커밋을 합치겠다. :wp를 통해 작업을 마무리하면 커밋메세지를 다시 작성할 기회를 주니 잘 생각해서 다시 작성해보자. 이후 다시 로그를 확인해보면

원하는 대로 작업이 된 걸 확인할 수 있다!!

3) 커밋을 임시로 취소하고 stash를 통해 임시 저장한다

커밋에서 취소한 내용을 stash에 보관할 거기 때문에 staged상태로 커밋이 취소되도록 한다.

git reset --soft HEAD^ (여기서 HEAD^는 현재 HEAD에서 한단계 이전 커밋으로 되돌아감을 말하는 상대경로 개념이다)

의도한 대로 HEAD가 바뀌었을 뿐 아니라 이전 커밋내역이 staged상태로 변경된 걸 확인할 수 있다. 이제 stash를 통해 임시 staged 파일들을 임시 저장하도록 하자(git stash, 잘 임시저장했는지 확인은 git stash list)

4) local main에서 origin을 pull해서 main먼저 싱크를 맞춘다

이건 이미 진행됐으니 넘어감

5) 문제의 브랜치를 main으로 reset해서 싱크를 맞춘다

아주 깔끔하게 싱크가 맞춰진 걸 확인할 수 있다!

6) stash를 pop하여 깔끔한 상태로 만든 뒤 다시 커밋 후 푸시한다^^

이후 add, commit하고 push해주자. 다만, 기존 원격 브랜치와 충돌이 일어나므로 git push -f를 통해 강제 푸시해주자. 주의할 점은 이 방법은 혼자 관리하는 브랜치일 때만 유효하다는 점이다. 절대 누군가가 이 브랜치에서 pull하거나 다른 내용을 작업하고 push한 상태면 안된다. 우리 회사는 이슈 브랜치를 같이 관리하진 않는 듯하니 우선 이방법으로 진행한다.

Before

After

마치며

굉장히 깔끔해진 결과로 바뀜을 알 수 있다. 생각보다 많은 시간을 쏟았다 ㅠㅠ