search

ddps-lab / architect-cloud

Kubernetes , AWS Serveless
6 stars 4 forks source link

3번 슬라이드 pod custom resource 사용 시나리오 추가 #82

Open mumat0103 opened 3 months ago

mumat0103 commented 3 months ago

3번 슬라이드 124번 페이지 뒤에 pod custom resource 사용 시나리오를 추가해야 합니다. https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ @chris0765 재일님이 해당 부분 진행 부탁드립니다.

kmu-leeky commented 3 months ago

progress?

chris0765 commented 3 months ago

쿠버네티스 커스텀 리소스 내용 정리

Kubernetes Custom Resource

기존 Kubernetes 리소스 (pod, service 등) 외에 사용자가 필요로 하는 기능을 Kubernetes API를 통해 추가하고 Kubernetes 클러스터에서 자동으로 관리할 수 있도록 합니다.

커스텀 리소스를 사용하기 위한 방법으로는 Custom Resource Definition (CRD)와 API Aggregation (AA)가 있으며, 가장 쉽고 많이 사용되는 방법은 CRD입니다.

CRD

CRD는 커스텀 리소스가 어떤 데이터로 구성되어 있는지를 정의합니다.

RDS 커스텀 리소스 CRD yaml 파일 예시

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: prometheuses.monitoring.coreos.com
spec:
  group: monitoring.coreos.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                version:
                  type: string
                  description: "Version of Prometheus to be deployed"
                retention:
                  type: string
                  description: "Data retention period"
                scrapeInterval:
                  type: string
                  description: "Interval at which metrics should be scraped"
  scope: Namespaced
  names:
    plural: prometheuses
    singular: prometheus
    kind: Prometheus
    shortNames:
      - prom

하지만 이 CRD가 커스텀 리소스를 실제로 생성하지는 않습니다. 어떤 항목이 정의되어야 하는지 등을 저장하는 메타데이터 오브젝트일 뿐입니다.

위 CRD 파일은 prometheus instance를 커스텀 리소스로 관리하며, string type의 version, retention, scrape interval 파라미터가 필요함을 알려줍니다. 위의 CRD를 준수하는 조건의 CR yaml 파일로만 리소스를 생성할 수 있습니다.

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: my-prometheus
  namespace: monitoring
spec:
  version: "v2.26.0"
  retention: "10d"
  scrapeInterval: "15s"

여기서 CRD 파일을 확인하여 CR의 명세가 부합하는지를 확인하고, 실제 리소스를 생성/제거/관리하는 역할이 Operator입니다. (Operator == 커스텀 리소스 컨트롤러) Operator를 직접 구현하기 위해서는 쿠버네티스의 저수준 API를 알아야 하기 때문에 매우 어려운 일이어야 하지만, CoreOS에서도 이 부분을 인지하고 Operator SDK 도구를 제공하고 있습니다. (kubebuilder or MetaController라는 도구도 있다고는 합니다.)

Operator SDK는 go 언어로 이루어져 있어 GO를 통해 작성합니다. Python을 통한 방법도 있다고 합니다만, 주류는 Go 언어입니다(https://medium.com/swlh/building-a-kubernetes-operator-in-python-with-zalandos-kopf-37c311d8edff)

대략적인 개발 순서는 다음과 같습니다.

물론 다양한 외부 리소스는 자신들의 Operator를 직접 제공하고 있어 편리한 부분이 있습니다.

위에 예시로 들었던 prometheus 또한 yaml 파일을 통해 Prometheus Operator를 설치하거나(https://github.com/prometheus-operator/prometheus-operator), helm을 통해 설치할 수도 있습니다(https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#kube-prometheus-stack).

결과적으로, Custom Resource, Operator, Custom Resource Definition의 관계는 기존 Kubernetes의 Resource, Controller, Resource Spec의 관계와 같습니다.

image

https://lcom.static.linuxfound.org/sites/lcom/files/kenzan-k8s-1.png

image

https://lcom.static.linuxfound.org/sites/lcom/files/kenzan-k8s-2.png

커스텀 리소스의 구조 정의는 CRD에서, 커스텀 리소스의 실제 프로비저닝 및 초기 구성, 실제 프로비저닝 자원과 리소스 정의를 비교하며 차이가 발생하지 않도록 모니터링, 자원 제거까지 도맡아 하는 것이 Operator, 자원을 생성할 때, Parameter를 정의하여 실제로 생성되는 것이 CR이라고 생각하면 될 것 같습니다.

위의 실제 예시였던 Prometheus도 실제로 Prometheus를 설치하는 부분은 Operator에 존재합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: prometheus-operator
  name: prometheus-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: prometheus-operator
  template:
    metadata:
      labels:
        app.kubernetes.io/name: prometheus-operator
    spec:
      containers:
      - args:
        - --kubelet-service=kube-system/kubelet
        - --localhost=127.0.0.1
        - --logtostderr=true
        - --config-reloader-image=jimmidyson/configmap-reload:v0.5.0
        - --prometheus-config-reloader=quay.io/prometheus-operator/prometheus-config-reloader:v0.53.1
        image: quay.io/prometheus-operator/prometheus-operator:v0.53.1
        name: prometheus-operator
        ports:
        - containerPort: 8080
          name: http

정리

Custom Resource는 Kubernetes에서 기본으로 제공하는 리소스(Pod, Service, Deployment 등)을 제외한 외부 리소스를 Kubernetes에서 통합하여 관리할 수 있도록 API를 확장하는 개념입니다.

Custom Resource를 사용하기 위해 필요한 자원은 Custom Resource Definition (CRD), Operator, Custom Resource (CR)이며, 각각의 역할은 다음과 같습니다.

개인적으로 "실제로 리소스를 프로비저닝 하는 자원은 무엇인가? 어떻게 프로비저닝하는가?" 부분이 잘 이해가 가지 않았었습니다.

kmu-leeky commented 3 months ago

CRD 라는 개념이 처음에 내가 생각했던것보다 훨씬 더 큰 개념 및 기능인것 같네. 간단히 실습해볼수 있을거라 생각했는데, 재일이가 서술한걸보니 그렇지 않을것 같다는 생각이 드네. 지금까지 찾아본게 있으니 이해를 조금 더 하고 넘어가면 좋기는 하겠다. 이걸 강의 내용으로 포함할런지에 대해서는 조금 더 고민이 필요해보이기는 한다. 현재 우리 실습 시나리오와 핏이 맞아야 하는데, 쉽지 않을수 있겠다는 생각도 드네.

chris0765 commented 3 months ago

CR 강의 자료 내용 구상

커스텀 리소스에 대해서 설명하려면 아래와 같은 내용이 들어가야합니다.

주요 내용

항목별 내용

CR 개념

CR 개념에 대한 설명

API Aggregation과 CRD

CR을 사용하기 위한 방법으로는 API Aggregation (AA)과 Custom Resource Definition (CRD)가 있음

API Aggregation 설명

여러 개의 API 서버를 하나의 API 서버처럼 사용할 수 있는 Kubernetes의 API Aggregation 개념 API Registration 기능을 통해 사용자가 별도로 필요한 기능을 API 서버로 만들어 쿠버네티스에 등록할 수 있음을 설명

API Aggregation 기반 CR 생성

apiserver-builder나 kubebuilder를 이용해 서버를 빌드하고, 커스텀 리소스 정의 후 컨트롤러 로직을 직접 구현해야 함 CRD보다 복잡하기 때문에 커스텀 리소스를 위해서는 API Aggregation보다 CRD를 사용하는 편 하지만 API 확장을 위해서 사용될 수 있기 때문에 CRD와는 별개로 필요한 기능이며, CRD에서 아직 지원하지 않는 기능을 구현할 수 있다 설명

CRD 설명

앞에서 설명한 CR의 구성을 정의하기 위한 데이터 간단한 예시 yaml 파일을 보여주며 어떤 식으로 파일이 구성되어야 하는지 설명

alice라는 커스텀 리소스를 규정하는 CRD

apiVersion: "apiextensions.k8s.io/v1beta1"
kind: "CustomResourceDefinition"
metadata:
  name: "alice.k106.com"
spec:
  group: "k106.com"
  version: "v1alpha1"
  scope: "Namespaced"
  names:
    plural: "alice"
    singular: "alice"
    kind: "Alice"
  validation:
    openAPIV3Schema:
      required: ["spec"]
      properties:
        spec:
          required: ["wonderland"]
          properties:
            wonderland:
              type: "string"
              minimum: 1

위 CRD는 alice라는 리소스에 wonderland라는 항목이 string 속성으로 반드시 있어야 한다는 것을 정의함

CRD 기반 CR 생성

간단한 CRD 예시와 연계하여 설명

apiVersion: "k106.com/v1alpha1"
kind: "Alice"
metadata:
  name: "my-custom-resource"
spec:
  wonderland: "this is my wonderland"

앞서 선언한 CR인 Alice를 생성하고 싶으며, 필수 항목인 wonderland에 string 속성 값을 넣어준 CR yaml 파일

이렇게 CRD를 바탕으로 CR을 생성했지만, 현재까지는 단순한 데이터일 뿐 실제로 동작하고 있는 pod이나 service가 아님을 말해주며, 커스텀 리소스가 실제로 어떻게 동작할지를 정의하는 컨트롤러가 필요함을 전달하며 Operator 개념 등장

Custom Resource Controller

컨트롤러를 구현하기 위해서는 쿠버네티스의 저수준 API를 알아야 하지만, 다행히 CoreOS에서 OperatorSDK를 제공함 Operator SDK와 Golang을 사용해 Operator를 비교적 간단하게 구현할 수 있음

Operator

Operator SDK를 사용해 Operator를 구현하는 예시 (Memcached) 대부분의 소프트웨어들은 Kubernetes를 위해 Operator를 제작하여 배포하기 때문에, 직접 구현하지 않아도 손쉽게 사용이 가능함 때문에 미리 제작된 Operator + 직접 CRD 생성을 통해 Custom Resource를 통합할 수 있음 혹은 Helm을 통해 CRD + Operator를 배포할 수 있음 (karpenter 역시 Helm을 통해 구성하고 있음)

image

Helm

Helm 개념 및 CRD와의 차이점 image

실습 내용 관련

Custom Resource 실습을 진행한다면 어떤 식으로 구성해야할지를 생각해보았습니다. 사실 개념 설명보다는 실습 부분이 더 난이도 있지 않을까 싶습니다. (완벽히 이해하려면, 단순히 따라하는 것은 어렵지는 않을 듯 함)

Coffee Manage를 사용한 그동안의 실습과 연관되게끔 하기 위해서는, 기존 기능의 한가지를 Custom Resource로 대체하거나, 새로운 Custom Resource를 추가하는 방향이 될 것 같습니다.

기존 기능 대체

Coffee Manage의 데이터베이스로 모놀리틱 애플리케이션에서는 내부 MySQL 서버, 그 이외에서는 RDS를 사용하는 것으로 알고 있습니다. 여기서 RDS를 Custom Resource로 대체하는 것으로 실습을 구성할 수 있을 듯 합니다. https://operatorhub.io/operator/ack-rds-controller Operator 코드가 존재하기 때문에, 가장 복잡한 부분인 Operator 구현 부분을 쉽게 넘어갈 수 있습니다.

새로운 기능 추가

Prometheus Operator를 생성 후, Coffee Manage 서비스를 모니터링 하는 실습이 가능합니다. 다만 기존 실습들과의 연계성은 많이 떨어진다 생각합니다.

결론

개념 설명만 두고 보면 Operator 이후 부분 제외 하루 안에 작성이 가능하고, Operator 이후 전체 부분은 2~3일이 걸릴 것이라 생각하고 있습니다. 실습 부분은 진행한다면 어느 정도가 걸리게 될지는 모르겠습니다.