쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 Section 7 복습

 

Object 그려보며 이해하기

section 7의 제목은 'Object 그려보며 이해하기' 이다.

Object는 쿠버네티스의 기능 중 특정 역할을 하는 것들이라고 생각하면 될 것 같다.

각각이 하는 일이 있고 역할이 있다. 

쿠버네티스의 pod를 구성하는 것들이라고 이해를 했다. 

 

이 section에서는 object들을 하나씩 그려보며 역할, 기능을 본다. 

다음 section들에서 쿠버네티스의 기능들을 사용해보며 object의 핵심 기능을 공부한다.

마지막으로 쿠버네티스 컴포넌트가 object들 어떻게 동작 시키는지 본다. 

 

알아볼 Object들은 다음과 같다. 

• Namespace
• Deployment
• Service
• ConfigMap, Secret
• PVC, PV
• HPA

이제 각 Object들을 설정할 때 어떻게 하는지, 설정의 속성들이 어떤 의미인지 보자. 

설정들을 보면 어떤 기능에 필요한 설정 값들을 설정하고, 다른 Object들과 어떻게 연결하고 이런 것을 작성해 놓은 것이다. 

쿠버네티스를 보면 설정하는 것이 대부분이라고 생각되는데 어떻게 설정해야 하는지, 설정하는 yaml코드들의 의미를 보는 것이다. 

 

Object 역할

먼저 Object들이 하는 일들을 간단하게 보자. 

• Namespace
  • 관련 Object들을 논리적으로 grouping 해주는 역할
• Deployment
  • Pod를 생성하고 업데이트 해주는 역할
  • Pod 원하는 개수 유지 역할
• Service
  • Pod에게 트래픽을 연결 시켜주는 역할
• ConfigMap
  • Pod에 환경 변수 값 (비민감 데이터)을 제공하는 역할
• Secret
  • Pod에 좀 더 중요한 값 (민감 데이터)을 제공하는 역할 
• PVC
  • Pod에 persistent volume = PV를 지정하는 역할
  • 저장 공간을 얼만큼 사용할지 설정하는 역할
• PV
  • 실제 volume을 지정하는 역할
  • 실제 컴퓨터의 저장 공간을 쿠버네티스에서 추상적으로 사용할 수 있게 지정하는 역할
• HPA
  • 부하에 따라 Pod를 scaling 하는 역할

 

각 Object의 큰 그림은 아래와 같다. 

살펴볼 주요 속성들도 표시가 되어 있다. 

 

각 object를 만드는 실제 yaml 파일을 보며 중요 속성과 그 속성의 의미를 보자. 

 

Namespace

Namespace는 관련 Object들을 논리적으로 grouping 해주는 역할

큰 개념이고 grouping 역할이기에 많은 속성은 없다. 

중요 속성은 아래와 같다. 

• kind
  • Object를 지정하는 속성
•  metadata
  • name
  • labels

name, labels 속성은 모든 Object에 있고 기본 중 기본이기에 아래에서 자세히 보자.

apiVersion: v1
kind: Namespace
metadata:
  name: anotherclass-123
  labels:
    part-of: k8s-anotherclass
    managed-by: dashboard

 

 

Deployment

Deployment는 Pod를 생성하고 업데이트하고 원하는 개수 유지 역할이다. 

역할에서 볼 수 있듯이 굉장히 중요하고 설정할 것이 많은 Object이다. 

주요 속성을 보자. 

• kind
•  metadata
  • namespace
    • 위에서 만든 Namespace object의 name 값을 넣는 것이다.
    • 그러면 해당 name을 가진 Namespace의 소속이 된다. 
  • name
    • 한 Namespace에서 Deployment끼리 name이 중복되면 안된다. 
  • labels
• replicas
  • 유지할 Pod 개수를 지정하는 것이다.
• strategy
  • Pod를 업데이트할 때 사용할 방식을 지정하는 것이다. 
  • 추후 어떤 방식들이 있는지, 어떻게 업데이트 되는지 볼 것이다. 
• template : 아래 내용대로 pod가 만들어진다. 
  • nodeSelector
    • Pod를 띄울 노드를 선택하는 것이다. 
  • containers : 아래에 많은 옵션들이 존재
    • image
      • 도커 허브에서 다운 받아 사용할 컨테이너 이미지 이름
      • Pod에 띄울 컨테이너의 컨테이너 이미지를 지정하는 것이다. 
    • envFrom
      • configMapRef
        • ConfigMap object와 연결하는 것이다.
        • app의 환경 변수와 관련된 부분이다. 
    • startupProbe
      • startupProbe라는 기능에 대한 속성.
      • app이 잘 기동 되었는지 체크하고 있다가 기동이 안되면 app을 재기동 시키는 기능
      • 다음 section에서 자세하게 어떤 기능인지, 동작하는지 볼 것이다. 
    • readinessProbe
      • readinessProbe라는 기능에 대한 속성.
      • app에 트래픽을 연결할 것인지 결정하는 기능
      • 다음 section에서 자세하게 어떤 기능인지, 동작하는지 볼 것이다. 
    • livenessProbe
      • livenessProbe라는 기능에 대한 속성.
      • app이 정상이 아니면 재시작 시킬 것인지 판단하는 기능
      • 다음 section에서 자세하게 어떤 기능인지, 동작하는지 볼 것이다. 
    • resources
      • pod에 자원 얼만큼 할 당할 것인지, 최대 얼만큼 사용할 수 있는지 설정하는 속성
      • 아래 속성으로 cpu, memory 등이 있는데 cpu, memory 자원 할당하는 것이다.
      • 이 속성 설정하지 않으면 pod가 노드의 자원들을 모두 사용해버린다. 
    • volumeMounts
      • Volume을 특정 경로에 마운트 하도록 지정하는 속성
      • mountPath는 pod 내부에 만들어지는 디렉토리이다. 
      • volumeMounts의 name 속성과 아래 volumes의 name 속성이 매칭됨
      • 매칭 되어서 실제 PVC object와 연결이 되는 것이다. 
    • volumes
      • persistentVolumeClaim = PVC, secret 과 같은 속성들로 Object들과 연결하는 것이다.  

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: anotherclass-123
  name: api-tester-1231
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231
    version: 1.0.0
    managed-by: dashboard
spec:
  selector:
    matchLabels:
      part-of: k8s-anotherclass
      component: backend-server
      name: api-tester
      instance: api-tester-1231
  replicas: 2
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        part-of: k8s-anotherclass
        component: backend-server
        name: api-tester
        instance: api-tester-1231
        version: 1.0.0
    spec:
      nodeSelector:
        kubernetes.io/hostname: k8s-master
      containers:
        - name: api-tester-1231
          image: 1pro/api-tester:v1.0.0
          ports:
          - name: http
            containerPort: 8080
          envFrom:
            - configMapRef:
                name: api-tester-1231-properties
          startupProbe:
            httpGet:
              path: "/startup"
              port: 8080
            periodSeconds: 5
            failureThreshold: 36
          readinessProbe:
            httpGet:
              path: "/readiness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: "/liveness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          resources:
            requests:
              memory: "100Mi"
              cpu: "100m"
            limits:
              memory: "200Mi"
              cpu: "200m"
          volumeMounts:
            - name: files
              mountPath: /usr/src/myapp/files/dev
            - name: secret-datasource
              mountPath: /usr/src/myapp/datasource
      volumes:
        - name: files
          persistentVolumeClaim:
            claimName: api-tester-1231-files
        - name: secret-datasource
          secret:
            secretName: api-tester-1231-postgresql

 

Deployment object를 만들면 쿠버네티스에서 일어나는 현상을 보자. 

Deployment의 역할이 pod를 만들고 업데이트 하는 방법을 제공하는 것이라 strategy, replicas 속성을 설정했다. 

 

그러면 쿠버네티스가 Deployment의 이런 속성으로 보고 ReplicaSet이라는 object를 만든다. 

ReplicaSet 이름 = Deployment 이름 + 임의의 문자

ReplicaSet object의 속성은 Deployment의 replicas 속성의 값들이 그대로 복사된다. 

 

ReplicaSet은 replicas에 설정한 수만큼 pod를 만든다. 

pod 이름 = ReplicaSet 이름 + 임의의 문자

pod가 2개가 만들어지고 pod 하나를 억지로 삭제하려고 해도 ReplicaSet이 감지하고 항상 pod가 2개가 되도록 유지를 시켜준다.

 

그래서 정확히는 Deployment가 pod의 업데이트를 관리하고 ReplicaSet이 복제본을 관리하는 역할을 하는 것이다.

 

위에서 본 Object의 그림은 왼쪽인데 동작하는 것을 보면 오른쪽이라는 의미이다. 

 

Service

Service는 pod에게 트래픽을 연결 시켜주는 역할이다. 

주요 속성을 보자. 

• metadata
  • namespace
    • 위에서 만든 Namespace object의 name 값을 넣는 것이다.
    • 그러면 해당 name을 가진 Namespace의 소속이 된다. 
  • name
    • 한 Namespace에서 Service끼리 name이 중복되면 안된다. 
  • labels
• ports
  • Service가 외부 또는 내부에서 요청 보낼 port와 받은 요청을 pod의 어떤 port로 전달할지 등 지정하는 속성
  • port
    • Service가 내부 or 외부에 노출하는 포트 번호
    • 이 port로 요청이 오면 Service가 pod로 요청을 전달한다. 

apiVersion: v1
kind: Service
metadata:
  namespace: anotherclass-123
  name: api-tester-1231
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231
    version: 1.0.0
    managed-by: dashboard
spec:
  selector:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231
  ports:
    - port: 80
      targetPort: http
      nodePort: 31231
  type: NodePort

 

 

ConfigMap & Secret

ConfigMap는 Pod에 환경 변수 값 (비민감 데이터)을 제공하는 역할이다. 

Secret는 Pod에 좀 더 중요한 값 (민감 데이터)을 제공하는 역할이다. 

두 Object는 역할도 비슷하고 설정도 비슷하여 같이 보자. 

주요 속성은 아래와 같다. 

• kind
•  metadata
  • namespace
  • name
  • labels
• data (ConfigMap 속성)
  • 환경 변수로 들어갈 값들 작성
  • key-value 형태로 작정하면 됨
  • ex : spring에 application.yml에 들어갈 내용 같은 것들
• stringData (Secret 속성)
  • 제공할 값들을 key-value 형태로 작성하면 됨
  • 작성한 내용들을 가지고 파일이 만들어진다. 
  • 만들어질 파일 이름을 stringData 바로 아래 작성하는 것이다. 
  • (여기서는 postgresql-info.yaml 파일 만들어지는 것)

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: anotherclass-123
  name: api-tester-1231-properties
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231
    version: 1.0.0
    managed-by: dashboard
data:
  spring_profiles_active: "dev"
  application_role: "ALL"
  postgresql_filepath: "/usr/src/myapp/datasource/postgresql-info.yaml"

Secret

apiVersion: v1
kind: Secret
metadata:
  namespace: anotherclass-123
  name: api-tester-1231-postgresql
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231
    version: 1.0.0
    managed-by: dashboard
stringData:
  postgresql-info.yaml: |
    driver-class-name: "org.postgresql.Driver"
    url: "jdbc:postgresql://postgresql:5431"
    username: "dev"
    password: "dev123"

 

PVC & PV

PVC는 Pod에 persistent volume = PV를 지정하는 즉 저장 공간을 얼만큼 사용할지 설정하는 역할이다. 

PV는 실제 volume을 지정하는 역할로 실제 컴퓨터의 저장 공간을 쿠버네티스에서 추상적으로 사용할 수 있게 지정하는 역할이다. 

두 Object 역시 연관이 되어 있기에 같이 보자. 

• kind
•  metadata
  • namespace 
    • PVC에만 있다. 
    • PV는 Namespace 소속이 아니다. 
    • Namespace 위의 개념이 있는데 바로 Cluster이다. 
    • Namespace, PV가 이 Cluster 소속이다. 
    • 즉 아래와 같은 구조
    • Cluster
      • Namespace
        • ....
      • PV
  • name
  • labels
• storage
  • 저장 공간을 얼만큼 사용할지 지정하는 속성이다. 
• accessModes
  
  • 저장 공간의 접근 권한을 설정하는 속성이다. 
  • 읽기 권한, 쓰기 권한이 있다. 
• local (PV)
  • 지정한 path를 volume으로 사용한다는 의미이다.
• nodeAffinity (PV)
  • node 지정하는 속성이다. 

PVC 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  namespace: anotherclass-123
  name: api-tester-1231-files
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231
    version: 1.0.0
    managed-by: kubectl
spec:
  resources:
    requests:
      storage: 2G
  accessModes:
    - ReadWriteMany
  selector:
    matchLabels:
      part-of: k8s-anotherclass
      component: backend-server
      name: api-tester
      instance: api-tester-1231-files

PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: api-tester-1231-files
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231-files
    version: 1.0.0
    managed-by: dashboard
spec:
  capacity:
    storage: 2G
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  local:
    path: "/root/k8s-local-volume/1231"
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - {key: kubernetes.io/hostname, operator: In, values: [k8s-master]}

 

HPA

HPA는 부하에 따라 Pod를 scaling 하는 역할이다. 

주요 속성을 보자. 

• kind
•  metadata
  • namespace
  • name
  • labels
• scaleTargetRef
  • scaling 할 대상을 지정하는 속성이다. 
  • 현재는 kind : Deployment를 지정하여 Deployment가 scaling 되는 것이다. 
• minReplicas
  • 유지할 최소 pod 개수
• maxReplicas
  • 부하 생겼을 때 scaling 될 수 있는 최대 pod 개수
• metrics
  • 어떤 상황에서 scaling할지 지정하는 속성
  • 현재는 pod의 CPU 사용량이가 평균 40% 넘어가면 scaling하라고 설정한 것이다. 
• behavior
  • scaling 동작 방식을 세밀하게 제어하는 속성
  • scale up, scale down 각각의 동작에 대해 정책, 적용 방식 등 지정하는 속성
  • 현재는 scale up 한 후 부하가 더 증가해도 바로 scale up하지 말고 2분 유지하라는 의미이다. 

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  namespace: anotherclass-123
  name: api-tester-1231-default
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: api-tester-1231
    version: 1.0.0
    managed-by: dashboard
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-tester-1231
  minReplicas: 2
  maxReplicas: 4
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 120

 

name, labels, selector 속성 파헤치기

위의 Object들의 yaml을 보면 name, labels, selector 속성들이 자주 보이는 것을 알 수 있다. 

그만큼 중요한 속성들이기에 자세히 알아보자. 

 

labels

어떤 것에 간단한 정보 붙일 때 labeling이라고 한다. 

Object들은 점점 많아지고 그에 따라 관리도 어려워진다. 

이럴 때를 대비해 Object에 labeling을 하기 위해 labels 속성이 있는 것이다. 

labeling이 잘 되어 있으면 정보를 바로 빠르게 파악할 수 있는 장점이 있는 것이다. 

쿠버네티스에서는 label에 대한 정보를 관리할 것을 권고하고 있다. 

 

labels에 어떤 정보 넣어야 하는지 쿠버네티스에서 권고하는 방법이 있다. 

프로메테우스에서 권고하는 방법에 따라 잘 만들어 놨다.

그렇기 때문에 프로메테우스의 예시를 보며 lables 속성을 깊게 이해해보자. 

 

lables에 있는 속성들은 아래와 같다. 

• labels
  • part-of
    • application 전체 대표하는 이름
  • component
    • 서비스를 구성하고 있는 각각의 분리된 기능들 중 하나의 이름
    • 프로메테우스라는 application, 서비스에는 아래와 같은 기능들이 있다. 
      • prometheus : metrics 수집, 성능 api 제공
      • exporter : metrics 제공
      • grafana : 성능 정보 시각화
  • name
    • 실제 application 이름
    • component 밑에 어려 종류의 name이 있을 수 있다. 
  • instance
    • 여러 개의 application 설치 시 구별하기 위한 값
    • application 여러 개 설치해야 하는 상황에서 instance 식별자 값 다르게 줘서 구분하는 것이다. 
  • version
    • 말 그대로 버전 정보
    • 위의 다른 정보들은 한번 labeling 하면 변경할 일 거의 없다. 
    • 하지만 version은 app 버전이 변경되면 같이 수정해야 한다. 
  • managed-by
    • 어떤 도구로 배포 되었는지에 대한 tool 이름 적는 속성
    • 이 속성이 있으면 이 object를 생성하고 관리하는 주체가 누구인지 알 수 있다. 

 

labels에는 정보성 + 기능성이 있고 정보 역할만 하는 label이 있다.

labels 속성 앞에 prefix를 붙일 수도 있다.

이 prefix는 도메인을 가리킨다.

옵션 사항이라 꼭 넣을 필요는 없다.

지금까지 본 label들은 쿠버네티스 권고 항목들이다.

그리고 추가적으로 아래 그림에 other usecase (작성자 등)와 같이 의미 있는 정보들을 더 넣으면 좋다.

 

name

lables의 속성들을 보면 결국 다 이름이다. 

그리고 name이라는 속성도 있다. 

Object들이 어떻게 naming 했는지 보자. 

 

위에서 봤듯이 같은 Namespace에서 같은 Object들끼리는 이름이 중복되면 안된다. 

또 naming할 때 특수문자는 - 그리고 . 만 사용할 수 있다. 

쿠버네티스에서 권고하는 규칙은 없다고 한다. 

하지만 이름 지을 때 고려해야 하는 포인트, 더 좋은 방법을 보자. 

 

Namespace 이름은 해당 Namespace에 들어가는 app들에 대한 범위를 나타내는 이름이 좋다고 한다. 

Namespace 아래의 object들은 name 속성 + instance 속성으로 하면 좋다고 한다. 

이 2개의 속성을 합치면 웬만해서는 같은 오브젝트들 간에 이름이 겹칠 일이 없다.

 

쿠버네티스 가이드에서 instance 속성 = name 속성 + 식별자로 하라고 한다. 

instance 속성이 위에서 식별자 역할을 한다고 했다. 

그래서 결국 이름이 그냥 instance 속성인 경우도 많다고 한다. 

 

그리고 instance 속성 + 사용 목적 이렇게 하는 경우도 있다고 한다. 

사용 목적에 따라 naming을 추가하면 좋다고 한다. 

왼쪽 = name + instance / 오른쪽 = k8s 가이드 따라 만든 instance

 

name과 lables들은 Object의 연결 요소로 중요하다. 

추후에 이것들을 수정하다 에러 날 수 있으니 처음 지을 때 잘 지어놔야 한다. 

운영까지 간 상황이라면 별거 아닌 naming도 수정하기 많이 부담스럽다.

그래서 운영에 올라가기까지 많이 고민해보고 이름을 만들어야 한다.

 

selector 

selector 속성도 굉장히 중요하지만 위의 Object 속성들을 볼 때는 보지 않았다. 

하지만 각 yaml 파일을 보면 어디든 있는 것을 볼 수 있다. 

 

label은 app 정보를 파악하기 위한 용도로만 사용되는 것이 아니라 추가적인 기능이 있다.

바로 selector와 매칭이 되어서 두 Object를 연결하는데 사용을 한다.

 

selector의 내용이 모두 label에 포함이 되어야 한다.

label에는 selector의 내용에 추가로 version과 같은 정보가 있어도 된다.

즉 label = selector + a

 

사실 instance 이름이 유니크하기 때문에 selector에 instance만 넣어도 실수 없이 원하는 pod 매칭 시킬 수 있다.

그래서 instance 외에 추가적인 내용들을 넣는 것은 선택사항이다.

 

selector와 labels는 object들을 매칭해주는 역할을 한다.

 

쿠버네티스에서는 이렇게 object끼리 연결시키는데 object들마다 다른 방법을 제공한다.

크게 2가지 방법이 있다.

1. selector - labels 로 연결
2. object 내에서 대상을 연결하는 특별 속성을 제공

 

HPA 내에서 Deployment 이름을 지정하는 속성 scaleTargetRef가 있었다.

Configmap, Secret, PVC도 pod에서 직접 연결하는 속성이 있었다.

이것이 2번 방법에 해당하는 것이다. 

 

Deployment - ReplicaSet - Pod가 labels & selector로 연결이 된다. 

Service - Pod도 labels  & selector로 연결이 된다. 

PVC - PV도 labels  & selector로 연결이 된다. 

 

HPA - Deployment는 scaleTargetRef라는 속성에 의해 연결이 된다. (HPA 설정에 존재)

Pod - Configmap은 envFrom이라는 속성에 의해 연결이 된다. (Deployment 설정에 존재)

Pod - PVC / Pod - Secret은 volumes라는 속성에 의해 연결이 된다. (Deployment 설정에 존재)

 

Node도 클러스터를 구성하면서 쿠버네티스가 자동으로 만들어 놓은 Object가 있고 여기에도 labels가 있다. 

그래서 pod에서는 nodeSelector 속성이, PV에서는 nodeAffinity 속성이 노드의 labels와 연결된다.

 

node - Pod는 labels & nodeSelector로 연결이 된다. 

node - PV는 labels & nodeAffinity로 연결이 된다. 

 

정리하면 아래와 같다. 

• labels - selector 속성으로 연결
  • Deployment - ReplicaSet
  • ReplicaSet - Pod
  • Service - Pod
  • PVC - PV
• 특별 속성으로 연결
  • HPA - Deployment
    • scaleTargetRef 속성으로 연결
    • HPA 설정에 존재
  • Pod - Configmap
    • envFrom 속성으로 연결
    • Deployment 설정에 존재
  • Pod - PVC 
  • Pod - Secret
    • volumes 속성으로 연결
    • Deployment 설정에 존재
  • node - Pod
    • labels & nodeSelector 속성으로 연결
  • node - PV
    • labels & nodeAffinity 속성으로 연결

 

 

출처

https://inf.run/k7mF

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 | 일프로 - 인프런