홈페이지>프로그래밍 관련>기타 소스코드
다운로드

선체 - 헬름 균일 레이어 라이브러리

이 저장소에는 Hull Helm 라이브러리 차트가 포함되어 있습니다. Helm 차트에서 Kubernetes 객체를 구축, 유지 관리 및 구성하기 쉽도록 설계되었으며 기존 헬름 차트 구성을 위반할 위험없이 기능을 향상시키기 위해 Addon으로 Helm 차트에 추가 할 수 있습니다.

차트 자체 및 관련 문서는 Hull Library Helm 차트의 루트 폴더 인 hull 폴더에서 찾을 수 있습니다.

Kubernetes API JSON Schemas는 kubernetes-json-schema 폴더에 저장됩니다.

아래는 선체 차트 README.md 입니다.

추상화를 유지해야합니다 -Kelsey Hightower

소개

Helm의 주요 설계 측면 중 하나는 사용자가 응용 프로그램의 Kubernetes 구성의 개별 추상화를 생성하는 것입니다. Helm 차트 /templates 폴더의 Yaml 템플릿 형태로 실현되는 각 개별 헬름 차트에 대해. 보일러 플레이트 kubernetes yaml 코드 블록이 포함 된이 템플릿 파일과 한편으로는 GO 템플릿 표현식을 사용하는 사용자 정의 구성 매핑은 중앙 values.yaml 을 통한 응용 프로그램 구성 사이의 접착제를 제공합니다. . 아마도이 응용 분당 추상화의 이러한 접근 방식은 가장 전문화 된 응용 프로그램에 대한 Tailormade Configuration 패키지를 만드는 데 적합하지만 단순하고 반복적이며 기성품 애플리케이션 포장 사용 사례를 위해 큰 오버 헤드를 갖는 비용이 발생합니다. Helm 차트에 의해 도입 된 추상화를 생성, 유지 및 (종종) 이해하기, 특히 다양한 소스의 많은 개별 헬름 차트에 직면 할 때 지루하고 도전 할 수 있습니다.

Hull 라이브러리의 주요 기능은 Helm 차트 워크 플로에서 맞춤형 YAML 템플릿 파일을 완전히 제거하여 추상화 수준을 제거 할 수 있다는 것입니다. hull 라이브러리 차트를 사용하여 모든 속성을 포함한 Kubernetes 객체는 values.yaml 에 완전히 투명하게 지정 될 수 있습니다. Hull 라이브러리 차트 자체는이를 달성하기 위해 Helm 차트의 사양, 구성 및 렌더링을 간소화하기위한 균일 한 계층을 제공합니다. 또한 Helm 차트와 Kubernetes API 객체 구성 사이의 중개인을 피하기 위해 Kubernetes API 상단의 얇은 레이어로 생각할 수도 있지만 각 구성 스위치를 추가하도록 요구하는 대신 개별 구성 옵션을 사용자 정의 해야하는 경우 유연성을 제공합니다. 템플릿에 수동으로. JSON 스키마 유효성 검사 HELM JSON 유효성 검사 기능 ( values.schema.json )을 기반으로 한 JSON Schema 유효성 검사를 지원하는 IDE를 사용할 때 kubernetes API를 작성하는 데 도움이됩니다. 추가 이점 (균일 한 상속 가능한 객체 메타 데이터, 구성/비밀 의 단순화 된 포함, values.yaml 내에 교차 참조 값을 포함시킵니다. 그러나 가장 중요한 것은 선체 라이브러리가 기존의 헬름 차트에 의존성으로 추가 될 수 있으며 기존의 헬름 차트 기능을 중단하지 않고 나란히 사용할 수 있습니다. 자세한 내용은 HULL 라이브러리 차트를 Helm 차트에 추가하는 것을 참조하십시오. 마지막으로, 라이브러리 차트 자체가되면 모든 것이 일반적인 헬름이 제공하는 기능 내에서 100% 작동합니다. 추가 툴링이 소개되거나 관련되지 않습니다.

이 프로젝트에 대한 귀하의 피드백은 가치가 있으므로 Issues 섹션에서 토론하거나 토론을 시작하거나 기능 소원 및 버그 보고서를 작성하십시오. 감사합니다!

Hull Library 차트 아이디어는 일반적인 헬름 차트 개념과 테스트에서 부분적으로 영감을 얻었습니다.

.

빠른 시작 - hull-demo 차트

선체의 세부 사항으로 뛰어 들기 전에 다음은 어떻게 작동하는지에 대한 첫 번째 엿볼 수 있습니다. 이 페이지의 릴리스 섹션에서 hull-demo Helm 차트의 최신 버전을 다운로드 할 수 있습니다. 최소한의 노력으로 Hull을 테스트하거나 Hull을 기반으로 새 헬름 차트를 설정하기 위해 모든 것이 부트 스트랩됩니다.

hull-demo 차트는 frontend 및 backend 배포 및 서비스 쌍으로 가상의 응용 프로그램 myapp 랩합니다. backend 포드에 장착 된 서버 구성을위한 구성 파일이 있습니다. frontend 포드는 환경 변수를 통한 backend 서비스 주소에 대해 알아야합니다. 또한 설정은 debug 설정 (프론트 엔드 액세스를위한 NODEPORT 사용)에서 프로덕션과 같은 설정 (클러스터 립 서비스 및 유입을 사용하여)으로 기본적으로 쉽게 전환 할 수 있어야합니다.

이러한 측면을 캡처하기위한 기본 구조는 다음과 같을 수 있습니다 (설명을위한 줄 주석이 추가됨). 

 hull : # HULL is configured via subchart key 'hull'
  config : # chart setup takes place here for everything besides object definitions
    specific : # central place for shared values specific to this chart
      debug : true # a switch influencing creation of objects in this chart
      application_version : v23.1 # a shared image tag for multiple container
      myapp : # some exemplary configuration settings for the app, exposed here for transparency
        rate_limit : 100
        max_connections : 5
  objects : # all objects to create are defined here
    deployment : # create deployments
      myapp-frontend : # the base part of the object name for frontend deployment
        pod : # configure pod-related aspects
          containers : # non-init containers
            main : # one main container
              image : # provide image reference
                repository : mycompany/myapp-frontend # repository
                tag : _HT*hull.config.specific.application_version # reference to central tag value above
              ports : # exposed ports
                http : # port name is http
                  containerPort : 80 # the port number
              env : # environment variables
                SERVER_HOSTNAME : # name of variable
                  value : _HT^myapp-backend # value is dynamically rendered reference to myapp-backend service name
                SERVER_PORT : # name of variable
                  value : " 8080 " # backend service port
      myapp-backend : # the base part of the object name for backend deployment
        pod : # configure pod-related aspects
          containers : # non-init containers
            main : # one main container
              image : # image reference
                repository : mycompany/myapp-backend # repository
                tag : _HT*hull.config.specific.application_version # reference to central tag value above
              ports : # exposed ports
                http : # port name is http
                  containerPort : 8080 # the port number
              volumeMounts : # mounts of the container
                appconfig : # context key is appconfig
                  name : myappconfig # the name needs to match a volume
                  mountPath : /etc/config/appconfig.json # mountPath
                  subPath : backend-appconfig.json # subPath
          volumes : # volumes that may be mounted
            myappconfig : # key matching a volumeMounts name
              configMap : # configmap reference
                name : myappconfig # the configmap to load, simply referenced by key name   
    configmap : # create configmaps
      myappconfig : # the backend configuration
        data : # data section
          backend-appconfig.json : # key name is file name
            serialization : toPrettyJson # serialize the dictionary content of inline to pretty Json
            inline : # define the contents of the file as a dictionary for convenience
              rate-limit : _HT*hull.config.specific.myapp.rate_limit
              max-connections : _HT*hull.config.specific.myapp.max_connections
              debug-log : _HT!{{ if _HT*hull.config.specific.debug }}true{{ else }}false{{ end }}
    service : # create services
      myapp-frontend : # frontend service, automatically matches pods with identical parent object's key name
        ports : # definition of service ports
          http : # http port for type=ClusterIP
            enabled : _HT?not _HT*hull.config.specific.debug # bind rendering to debug: false condition, use embedded transformation to reference field
            port : 80 # regular port 
            targetPort : http # targetPort setting
          http_nodeport : # http port for type=NodePort
            enabled : _HT?_HT*hull.config.specific.debug # bind rendering to debug: true condition
            port : 80 # regular port 
            nodePort : 31111 # the node port
            targetPort : http # targetPort setting
        type : |-  # dynamically switch type based on hull.config.specific.debug setting
          _HT!
            {{- if _HT*hull.config.specific.debug -}}
            NodePort
            {{- else -}}
            ClusterIP
            {{- end -}}
      myapp-backend : # backend service, automatically matches pods with identical parent object's key name
        ports : # definition of service ports
          http : # http port
            port : 8080 # regular port 
            targetPort : http # targetPort setting
        type : ClusterIP # in cluster service
    ingress : # create ingresses
      myapp : # the central frontend ingress
        enabled : _HT?not _HT*hull.config.specific.debug # rendering bound to debug: false
        rules : # the ingress rules
          myapp : # key-value dictionary of rules
            host : SET_HOSTNAME_HERE # change the host at deployment time to actual one
            http : # http settings
              paths : # paths definition
                standard : # a standard path definition
                  path : / # could be changed at deployment time
                  pathType : ImplementationSpecific # path type
                  backend : # backend config
                    service : # service targeted
                      name : myapp-frontend # key name suffices to reference service created in this chart
                      port : # target port
                        name : http # target port name

이것은 hull-demo 의 values.yaml 로 구성되는 예입니다. 최신 hull-demo 릴리스를 다운로드하고 실행하면 

 helm template hull-demo-<version>.tgz

위의 values.yaml 기반으로 한 객체 세트를 렌더링합니다.

  • 중앙에 구성된 이미지 tag 세트 (기본적으로 v23.1 )와 myapp-backend 의 서비스 내 클러스터 주소를 가리키는 환경 변수가있는 myapp-frontend 에 대한 배포
  • 중앙에 구성된 이미지 tag 세트 (기본적으로 v23.1 )와 myappconfig ConfigMap에서 장착 된 구성이있는 myapp-backend 용 배포
  • values.yaml 표현식을 통합하여 동적으로 구축 된 JSON 파일의 myappconfig configmap.
  • myapp-backend 배포를 앞두고 간단한 클러스터 립 서비스
  • 유형 및 포트 구성이 중앙 debug 스위치에 의존하는 myapp-frontend 배포를 앞두고 서비스- debug 설정 모드에서 NodePort 입력하거나 비 데그 설정의 myapp 유입과 함께 ClusterIP 입력하십시오.
  • debug: false 값이 설정된 경우에만 렌더링/생성되는 Ingress Object myapp

이 구성의 모든 측면은 추가 values.yaml 사용하여 배포 시간에 변경 또는 덮어 쓰일 수 있습니다.

  • 설정 debug: true 또는 debug: false 통해 전체 구성을 debug 모드로 전환합니다.
  • 배포에 리소스 정의 추가
  • 유입의 호스트 이름과 경로를 설정합니다
  • 포드에 추가 환경 변수를 추가하십시오
  • myapp configmaps 소스 값 ( rate_limit 및 max_connections )을 변경하거나 완전히 덮어 쓰십시오.
  • ...

모든 객체와 논리는 hull-demo 의 values.yaml 에서 백선 미만의 전체 구성 코드로 작성되었습니다. 위에서 언급 한 모든 측면을 테스트 helm template 추가 values.yaml 추가하여 단순히 실험 할 수 있습니다. 자신의 Helm 차트를 부트 스트랩하려면 values.yaml 비우십시오. yaml 구성, 차트 폴더의 name Chart.yaml 로 바꾸십시오.

이것은 Hull을 사용하는 방법의 첫 번째 데모이지만 더 많은 기능과 지원되는 사용 사례가 있습니다. 자세한 내용은 주요 기능과 자세한 문서를 확인하십시오.

주요 기능 개요

위에서 강조 표시된 바와 같이, Helm 차트에 포함될 때 Hull Library 차트는 values.yaml 파일만으로 주어진 사양에서 Kubernetes 객체를 동적으로 렌더링하는 작업을 취할 수 있습니다. YAML 객체 구성을 통해 /templates 폴더의 사용자 정의 YAML 템플릿 대신 Hull Library의 GO 템플릿 기능으로 지연된 모범 사례를 집중 시행 할 수 있습니다.

  • 개별 보일러 플레이트 YAML 템플릿을 차트에 추가하지 않고도 Kubernetes 객체를 지정하는 데 필요한 것에 집중하십시오. 이는 일반 헬름 워크 플로에서 일반적인 오류 및 유지 보수 원을 제거합니다. 선체가 렌더링 된 출력이 Kubernetes API 사양에 맞도록하려면 많은 단위 테스트가 Kubernetes API JSON 스키마에 대한 선체 렌더링 출력을 검증합니다.

    자세한 내용은 JSON 스키마 검증의 문서를 참조하십시오.

  • Hull에서 지원하는 모든 Kubernetes 객체 유형의 경우 Kubernetes 객체 유형 특성에 대한 전체 구성 액세스를 직접 사용할 수 있습니다 . 이는 차트 관리자가 누락 된 구성 옵션을 하나씩 추가하지 않아도되며 Helm 차트 사용자는 Helm 차트를 포킹하여 구성에 필요한 속성 만 추가합니다. Kubernetes API 버전과 일치하는 새로운 버전으로 선체 차트를 최신 버전으로 업데이트하는 것은 새로운 API 버전에서 Kubernetes 객체에 추가 된 속성을 구성 할 수 있도록해야합니다. 선체 차트는 최소 Kubernetes API 버전이 지원하는 버전으로 제공됩니다.

    자세한 내용은 아키텍처 개요에 대한 문서를 참조하십시오.

  • 선체 라이브러리의 단일 인터페이스는 배포 차트에서 객체를 작성하고 구성하는 데 사용됩니다. 이것은 차트 제작자/관리자 및 차트가 실제로 작동하는 방식과 포함 된 내용에 대한 상호 이해를 촉진합니다. /templates 폴더를 파고 들기 위해 헬름 차트의 영향을 이해하는 것이 더 이상 필요하지 않습니다. 오해를 피하기 위해 라이브러리의 인터페이스 (Hull 라이브러리의 values.yaml )가 완전히 JSON이 검증되었습니다. 라이브 JSON 스키마 검증 (예 : VSCODE)을 지원하는 IDE를 사용하면 선체 객체를 만들 때 IDE 지침을 얻을 수 있습니다. 렌더링하기 전에 JSON 스키마 적합성은 선체 라이브러리에 의해 검증됩니다.

    자세한 내용은 JSON 스키마 검증의 문서를 참조하십시오.

  • 균일하고 풍부한 메타 데이터는 선체 라이브러리에서 생성 된 모든 객체에 자동으로 첨부됩니다.

    • Kubernetes 및 Helm에 대해 정의 된 Kubernetes 표준 레이블은 모든 객체 메타 데이터에 자동으로 추가됩니다.
    • 추가 사용자 정의 레이블 및 주석 메타 데이터는 다음을 위해 계층 적으로 설정할 수 있습니다.
      • 모든 생성 된 Kubernetes 객체 또는
      • 주어진 유형의 모든 kubernetes 객체 또는
      • 모든 개별 Kubernetes 객체.

    메타 데이터 덮어 쓰기에 대한 자세한 내용은 아래 고급 예제를 참조하십시오.

  • 더 큰 크기의 내용을 위해 values.yaml 또는 외부 파일에서 내용의 인라인 사양을 선택하여 구성 및 비밀 입력의 유연한 처리. 파일에서 데이터를 가져 오면 데이터는 템플릿 엔진을 통해 실행되거나 템플릿으로 가져온 '도'와 같이 이미 소비 애플리케이션에 전달 될 템플릿 표현식이 포함되어있을 수 있습니다. 표준 시나리오의 편리한 처리에 중점을두면 파일 내용을 values.yaml 의 일반 YAML 구조로 정의 할 수 있으며 헐을 헐을 연속하여 파일 확장자로 또는 선택한 모든 표현에 따라 JSON 또는 YAML에 자동으로 직렬화 할 수 있습니다. Hull은 Base64 비밀의 인코딩을 처리하므로 구성 맵 및 비밀을 작성하는 방식이 동일하게 작동하며 배포에 구성 맵 또는 비밀을 추가하려면 몇 줄의 코드 만 필요합니다.

    자세한 내용은 구성 및 비밀에 대한 문서를 참조하십시오.

  • 객체 인스턴스를 인스턴스화하기위한 광범위한 불이행 기능. 모든 객체 인스턴스 또는 인스턴스 그룹을 원하든 라벨 또는 주석, 컨테이너 환경 변수 또는 장착 볼륨과 같은 특정 측면을 공유하려면 HULL은 불필요한 구성 반복을 피하는 객체 인스턴스 필드의 기본값을 효율적으로 정의 할 수 있도록 지원합니다.

    자세한 내용은 차트 디자인 조언을 참조하십시오.

  • 대상 YAML의 실제 값이 values.yaml 의 구성을받는보다 복잡한 시나리오의 경우 values.yaml 의 값 대신에 정의 된 GO 템플릿 표현식을 주입하여 값을 동적으로 채우는 지원이 있습니다. 예를 들어, 콘크리트 컨테이너 인수가 values.yaml 의 다양한 다른 설정에 의존하는 경우 yaml은 인수 계산에 조건을 주입하거나 간단히 values.yaml 의 다른 필드를 참조 할 수 있습니다.

    자세한 내용은 변환에 대한 문서를 참조하십시오.

  • 참조 된 구성 및 비밀의 자동 해싱을 활성화하여 필요할 때 구성 변경에 대한 포드 재시작을 용이하게합니다.

    자세한 내용은 포드 문서를 참조하십시오.

선체 라이브러리의 일반적인 아키텍처 및 기능에 대한 자세한 내용은 아키텍처 개요를 참조하십시오.

중요한 정보

도서관을보다 자세히보기 전에 먼저 언급해야 할 중요한 사항 :

켈 Hull 라이브러리를 통해 Yaml을 렌더링하는 데 몇 가지 이점이있을 수 있지만 Helm 차트에 추가되지 않은 추가 사항이라는 점에 유의하십시오. /templates 폴더에서 YAML 템플릿 렌더링과 관련된 일반 헬름 워크 플로우는 HULL 라이브러리 차트의 통합에 의해 완전히 영향을받지 않습니다. 때로는 선체 라이브러리가 충족하지 않는 구성 또는 객체 사양에 대해 매우 구체적인 요구 사항이있을 수 있으므로 동일한 헬름 차트에서 쉽게 평행하게 평행하게 필요한 경우 일반 헬름 워크 플로 및 HULL 라이브러리를 사용할 수 있습니다. 켈

켈 단일 정적 파일 인 hull.yaml 은 내장 된 선체 차트에서 부모 차트 /templates 폴더로 수정하지 않고 'as-is'를 복사하여 hull을 통해 YAML을 렌더링 할 수 있어야합니다. HULL 렌더링 파이프 라인을 시작하는 코드가 포함되어 있으며 자세한 내용은 HULL 라이브러리 차트를 Helm 차트에 추가하는 것을 참조하십시오! 켈

켈 현재 헐 릴리스는 기존의 비 베타 및 비 알파 헬름 3 CLI 버전에 대해 테스트됩니다. Helm CLI 버전 3.0.x Hull과 호환되지 않으며 현재 존재하는 다른 모든 비 베타 및 비 알파 버전은 호환됩니다. 켈

켈 해당 선체 릴리스와 함께 최신 3 개의 주요 Kubernetes 릴리스를 지원하기위한 것입니다. 현재 Kubernetes 버전 1.29 및 1.30 및 1.31 은 헐 릴리스와 일치하고 유지 관리합니다. 켈

새로운! 선체 튜토리얼

접근 방식을 좋아한다면 Dev.to의 New Hull Tutorials 시리즈를 살펴 보도록 초대받습니다! Eigth Part 튜토리얼은 헬름을 설정하고 선체 기반 차트를 만들기 시작하여 실제 헐 기반 헬름 차트를 단계별로 마무리하기 위해 시작됩니다. 일반 헬름 차트 워크 플로의 차이점을 강조하려면 튜토리얼은 인기있는 kubernetes-dashboard Helm 차트를 소스로 가져 와서 기능적으로 동등한 선체 기반 헬름 차트로 전송합니다. 결국, 작성 및 유지 관리를 위해 구성 라인을 줄이는 것은 정기적 인 헬름 스타일의 쓰기 차트 대신 선체 기반 접근법을 사용할 때 50% 이상 줄일 수 있음을 보여줍니다!

선체 기반 차트 작성 및 구성

선체 기반 헬름 차트를 작성하고 구성하는 작업은 동일한 코인의 양면으로 간주 될 수 있습니다. 양쪽은 동일한 인터페이스 (선체 라이브러리)와 상호 작용하여 생성해야 할 객체를 지정합니다. 제작자/관리자 관점의 작업은 최우선입니다. 헬름 차트로 싸여있는 특정 응용 프로그램을 구성하는 객체의 접지 구조를 제공합니다. 차트의 소비자는 자신의 시스템 별 컨텍스트를 지상 구조에 적절하게 추가하여 목표를 달성하기 위해 필요에 따라 개체를 추가하거나 삭제할 수있는 자유가 있습니다. 배포 시간에 Creators 기본 구조는 소비자 시스템 별 YAML 파일과 병합되어 전체 구성을 구축합니다. 동일한 라이브러리 인터페이스를 통해 상호 작용하면 양쪽에서 라이브러리에서 작업하는 방법에 대한 일반적인 이해를 촉진하고 대부분의 지루한 복사 및 페이스트 제작 및 검사 무거운 구성 프로세스를 제거 할 수 있습니다.

따라서 선체를 기반으로 한 헬름 차트를 작성하는 데 필요한 모든 것은 표준 스캐 폴드 헬름 차트 디렉토리 구조입니다. 선체 라이브러리 차트를 하위 차트로 추가하고 hull.yaml Hull 라이브러리 차트에서 부모 헬름 차트 /templates 폴더로 복사하십시오. 그런 다음 values.yaml 을 통해 배포 할 기본 오브젝트를 구성하면 완료됩니다. 배포 패키지에 대해 얼마나 많은 유형을 생성하는지에는 제한이 없습니다.

그러나 선체로보다 복잡한 응용 프로그램을 정의 할 수있는 것 외에도 간단한 kubernetes 객체를 랩핑하는 데 사용하여 kubectl을 통해 배치하거나 (Helm 릴리스와의 관리 관점에서 나오지 않음) 상당한 양을 작성해야합니다. 이를 달성하기 위해 보일러 플레이트 템플릿.

Hull이 이해하는 values.yaml 의 기본 구조는 다음 섹션에서 여기에 제공됩니다. 이것은 본질적으로 선체 기반 차트를 생성하고 소비하기위한 단일 인터페이스를 형성합니다. 모든 객체는 values.yaml 에서 정의되고 활성화 된 경우에만 생성됩니다. yaml, 이는 소비자가 사용하려면 활성화 해야하는 소비자를 위해 사전 구성된 개체를 원할 수 있음을 의미합니다.

YAML 구조의 최상위 레벨에서 선체는 config 과 objects 를 구별합니다. config 하위 구성은 메타 데이터 및 제품 설정과 같은 차트 특정 설정을 처리하기위한 것이지만 렌더링 할 콘크리트 Kubernetes 객체는 objects 키 아래에 지정됩니다. 추가 세 번째 최상위 키 명명 된 version 허용됩니다. 예를 들어 상위 Helm 차트 릴리스 파이프 라인과 같은 Hull 차트 버전으로 설정되면 HULL 버전을 나타내는 모든 개체에 vidispine.hull/version 이 자동으로 채워집니다. 그것은 물체를 렌더링하는 데 사용되었습니다.

config 섹션

config 섹션 내에서 Helm 차트의 일반 설정을 구성 할 수 있습니다. config.general 및 config.specific 의 두 하위 섹션으로 나뉩니다.

config.general 섹션

config.specific 섹션과 달리 단일 헬름 차트에만 특정한 임의의 데이터로 채워져 있어야합니다. config.general 섹션을 사용하여 고유 한 응용 프로그램에 특별한 모든 것을 정의해야합니다. 한편으로는 모든 선체 기반 차트와 관련된 구성 옵션을 보유하고 있지만 다른 헬름 차트에서 이상적으로 동일한 방식으로 모델링되는 config.general.data Entry Entry에서 공간을 남겨 둡니다. 예를 들어, 제품 제품군의 여러 응용 프로그램이 동일한 엔드 포인트에 의존하는 경우 모든 관련 차트의 general.data 속성에서 이러한 엔드 포인트를 균일하게 모델링 할 수 있으므로 Helm 차트가 연속 배포 파이프 라인과 동일한 방식으로 동일한 방식으로 인터페이스 할 수 있습니다.



config.general 에는 다음 하위 필드 만 있습니다.

nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata

매개 변수 설명 기본 예
nameOverride 이름 오버라이드는 메타 데이터 레이블 app.kubernetes.io/name 값에 적용됩니다. 설정하면이 차트 이름이 여기에서 효과적으로 대체됩니다.
fullnameOverride 값으로 설정되면 FullName Override는 모든 객체 이름에 대한 접두사로 적용되며 객체 이름의 표준 <release>-<chart> 접두사 패턴을 대체합니다. myapp
namespaceOverride 값으로 설정되면 생성 된 모든 개체의 네임 스페이스 가이 값으로 설정됩니다. 이것이 정의되지 않으면 모든 객체 인스턴스의 네임 스페이스는 각 헬름 명령에 제공된 릴리스 네임 스페이스에 기본값을 표시합니다. my-namespace
noObjectNamePrefixes 설정된 경우 객체 인스턴스 키는 직접 Kubernetes 객체의 이름으로 사용되며 접두사가 없습니다. 이것은 기술적으로 각 객체에서 staticName true를 설정하는 것과 같습니다. 이것을 true 로 설정함으로써 config.general.fullnameOverride 의 값은 관련이 없습니다. false true
createImagePullSecretsFromRegistries 사실 인 경우, 이미지 풀 비밀은이 헬름 차트에 정의 된 모든 등록 기관에서 생성되며 모든 포드에 추가됩니다. true false
globalImageRegistryServer 비어 있지 않으면 모든 컨테이너 image 필드의 registry 필드가 여기에 주어진 값으로 설정됩니다. 이 필드가 비어 있지 않으면 config.general.globalImageRegistryToFirstRegistrySecretServer 의 설정은 무시됩니다. image 에 대한 정의 된 모든 명시 적 registry 설정은이 값으로 덮어 씁니다.

이에 대한 의도 된 사용법은 배포 시나리오와 같은 에어 갭의 경우 Central Docker 레지스트리에서 모든 이미지를 편리하게 가져 오는 것입니다.

globalImageRegistryToFirstRegistrySecretServer true 로 설정하는 것과는 달리,이 경우 레지스트리 비밀은 일반적 으로이 헬름 차트 외부에서 정의되며 Registry Secret의 서버는 이름으로 직접 참조됩니다. 이 기능을 사용 하고이 헬름 차트 외부에서 Docker Registry Secret을 정의하는 경우, 참조 된 Docker Registry가 안전하지 않은 경우 POD에 imagePullSecrets 추가해야 할 수도 있습니다.		 "" mycompany.docker-registry.io
globalImageRegistryToFirstRegistrySecretServer True 및 globalImageRegistryServer 가 비어 있으면 모든 컨테이너 image 필드의 registry 필드가 처음 발견 된 registry 객체의 server 필드로 설정됩니다. 여러 registry OBEJCTS를 제공하는 경우 영숫자 키 이름이 가장 낮은 레지스트리입니다. 일반적으로 true 과 함께 createImagePullSecretsFromRegistries 설정하여자가 인구 화 된 imagePullSecrets 의 혜택을 받고 그에 따라 registry 설정해야합니다. image 의 명시 적 registry 설정은이 값으로 덮어 씁니다.

이 설정의 의도 된 사용법은 배포 시나리오와 같은 에어 갭의 경우 Central Docker 레지스트리에서 모든 이미지를 편리하게 가져 오는 것입니다.		 false true
errorChecks

HULL을 결정하는 옵션 HULL은 helm install 또는 helm template 에서 오류를 생성합니다. 자세한 내용은 오류 확인 구성에 대한 자세한 문서도 참조하십시오.

다음 하위 필드 만 있습니다.

objectYamlValid
hullGetTransformationReferenceValid
containerImageValid
virtualFolderDataPathExists
virtualFolderDataInlineValid
errorChecks.objectYamlValid 깨진 YAML이 렌더링되지 않음을 확인하십시오 true
errorChecks.hullGetTransformationReferenceValid 모든 _HT* 참조가 values.yaml 의 기존 키를 가리 키는지 확인하십시오. true
errorChecks.containerImageValid 모든 pod 의 containers 및 initContainers image 섹션이 존재하고 최소한 repository 세트가 있는지 확인하십시오. true
errorChecks.virtualFolderDataPathExists ConfigMap 및 Secret의 data path 필드에서 참조되는 모든 파일이 물리적으로 존재하는지 확인하십시오. true
errorChecks.virtualFolderDataInlineValid Configmap 및 Secret의 data inline 필드에 대해 null 값이나 결 측값 (빈 문자열로 변환)이 설정되어 있음을 확인하십시오. false
debug

차트 문제를 디버깅하는 데 도움이되는 옵션. 대부분 쓸모없고 errorChecks 에서 구성된 기본 오류 메시지를 말하면 대체됩니다.

다음 하위 필드 만 있습니다.

renderBrokenHullGetTransformationReferences
renderNilWhenInlineIsNil
renderPathMissingWhenPathIsNonExistent
debug.renderBrokenHullGetTransformationReferences 활성화 된 경우 문자열을 인쇄하는 글로벌 스위치 :

HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <xyz> was not found

변환이 기존 사전 키를 참조하는 경우 _HT*/hull.util.transformation.get 참조 ( xyz ) 및 누락 된 키 ( y )를 포함합니다. 이는 차트 렌더링을 디버그하는 데 유용하며 일반적으로 설치가 깨진 참조에 오류가 발생하여 파괴 된 참조에 대한 오류가 발생하기 때문에 고장난 참조를 검색하는 데 유용합니다 (문제가있는 참조를 고정하기가 어려울 수 있음).

메모:

이제 깨진 GET 참조는 기본적으로 말하기 헬름 오류에 의해 신호를 보내 므로이 스위치는 대부분 깨진 참조를 디버깅하는 데 쓸모 없게됩니다. 이 옵션을 비활성화하고 Broken Get 참조에서 열심히 실패하여 오류 메시지에서 직접 문제를 분석하는 것이 권장됩니다.		 false true
debug.renderNilWhenInlineIsNil 활성화 된 경우 문자열을 인쇄하는 글로벌 스위치 :

<nil>

inline 사양이 nil 포인터를 구성 또는 비밀로 참조 할 때 data 필드 값으로 값. False로 설정되면 nil 값은 ConfigMap 또는 비밀 data 필드에서 빈 문자열로 인쇄됩니다.

메모:

이제는 잘못된 인라인 필드가 기본적으로 말하기 헬름 오류에 의해 신호를받습니다 (의미 hull.config.general.errorChecks.virtualFolderDataInlineValid true ). 이 스위치를 활성화하는 것은 대부분 디버깅에 더 이상 사용되지 않으며이 옵션을 비활성화하고 유효하지 않은 인라인 필드에서 열심히 실패하도록 권장됩니다.		 false true
debug.renderPathMissingWhenPathIsNonExistent 활성화 된 경우 문자열을 인쇄하는 글로벌 스위치 :

<path missing: the_missing_path>

파일로 해결되지 않는 the_missing_path 값을 포함하여 구성 맵 또는 비밀 data 필드 값에서. False 인 경우 data 필드 값이 빈 문자열로 해결됩니다.

메모:

이제 경로 필드에서 참조 된 존재하지 않는 파일은 기본적으로 말하기 헬름 오류로 신호를받습니다 (의미 hull.config.general.errorChecks.virtualFolderDataPathExists true ). 이 스위치를 활성화하는 것은 대부분 디버깅에 더 이상 사용되지 않으며이 옵션을 비활성화하고 존재하지 않는 파일 경로 참조에서 열심히 실패하도록 권장됩니다.		 false true
render 선체가 어떻게 물체를 YAML로 렌더링하는지에 영향을 미치는 옵션.

다음 하위 필드 만 있습니다.

emptyAnnotations
emptyLabels
emptyHullObjects
render.emptyAnnotations true 인 경우, false 는 annotations: {} annotations 냅니다. false true
render.emptyLabels true false 경우 Hull은 labels: {} labels 합니다. false true
render.emptyTemplateAnnotations true false 경우, 선체 template annotations annotations: {} 렌트합니다. false true
render.emptyTemplateLabels true 인 경우 template 는 labels: {} if no labels exist for an object, if the . false true
render.emptyHullObjects true 인 경우 선체가 처리 한 일부 필드에 대한 요소가 없으면 배선이 빈 배열로 배열을 렌더링합니다. false 인 경우 키 값 쌍이 획득됩니다.

이것은 선체 구성 사전에서 렌더링 된 YAML의 Kubernetes 어레이에 매핑되는 필드에 영향을 미칩니다. 다음은 HULL의 객체 구성에 영향을받는 필드 목록입니다.

  • secret 및 configmap 객체의 data
  • initContainers , containers , volumes 및 imagePullSecrets , cronjob , daemonset , deployment , job 및 statefulset pod 개체
  • cronjob deployment daemonset , containers , job 및 statefulset pod 개체 initContainers ports , env , envFrom 및 volumeMounts volumes
  • service 개체의 ports
  • ingress 대상의 rules 및 tls
  • http.paths ingress 대상의 rules
  • webhooks validatingwebhookconfiguration 및 mutatingwebhookconfiguration 의 WebHooks
  • clusterrole 및 role 의 rules
 false true
postRender Hull이 객체를 완전히 렌더링 한 후 결과적인 YAML 문자열을 조작 할 수 있습니다. 그렇게 할 수있는 가능성은 여기에서 postRender 행동으로 제공됩니다.

경고 : yaml 구조를 손상시킬 수 있으므로주의해서 사용하십시오!
postRender.globalStringReplacements 렌더링 된 물체의 YAML에 적용될 수있는 교체 가능성의 사전. 이를위한 기본 사용 사례는 _HULL_OBJECT_TYPE_DEFAULT_ 의 광범위한 기본값과 함께 인스턴스 특정 문자열을 기본 YAML에 주입 할 수있는 sources 인스턴스와 함께 사용됩니다. 제공된 미리 구성된 매핑이 enabled: true in Demand. 각 매핑은 다음 필드로 구성됩니다.
  • enabled : true 인 경우 매핑을 실행하십시오
  • string : 교체 할 정확한 문자열 부분
  • replacement : string 대신 삽입 된 값 유형. 무료 문자열이 아니라 다음 값 중 하나 : OBJECT_INSTANCE_KEY , OBJECT_INSTANCE_KEY_RESOLVED 또는 OBJECT_INSTANCE_NAME
postRender.globalStringReplacements.instanceKey enabled 되면 string 값은 hull.objects.<object_type>.<instance_key> 에서와 같이 실제 객체의 instance_key 로 대체됩니다. replacement 값은이 매핑의 OBJECT_INSTANCE_KEY 입니다. instanceKey:
enabled: false
string: _HULL_OBJECT_TYPE_DEFAULT_
replacement: OBJECT_INSTANCE_KEY
postRender.globalStringReplacements.instanceKeyResolved enabled 경우 string 값은 hull.objects.<object_type>.<instance_key> 에서와 같이 실제 객체의 instance_key 로 대체됩니다 hull.objects.<object_type>.<instance_key>.metadataNameOverride replacement 값은이 매핑을 위해 OBJECT_INSTANCE_KEY_RESOLVED 입니다. instanceKeyResolved:
enabled: false
string: _HULL_OBJECT_TYPE_DEFAULT_
replacement: OBJECT_INSTANCE_KEY_RESOLVED
postRender.globalStringReplacements.instanceName enabled 되면 string 값이 실제 객체의 렌더링 된 metadata.name 로 대체됩니다. replacement 값은이 매핑의 OBJECT_INSTANCE_NAME 입니다. instanceName:
enabled: false
string: _HULL_OBJECT_TYPE_DEFAULT_
replacement: OBJECT_INSTANCE_NAME
serialization 일반 직렬화 옵션.
serialization.configmap.enabled enabled 경우 fileExtensions 에 따른 매핑 된 파일 확장자는 기본적으로 주어진 직렬화 방법으로 직렬화됩니다. data 키가 매핑 된 확장자 중 하나로 끝나면 값의 직렬화 메소드는 컨텐츠를 문자열에 쓰는 데 사용됩니다. 구성 data 입력의 특정 serialization 필드는 기본 설정을 덮어 씁니다. true
serialization.configmap.fileExtensions 파일 확장에서 직렬화 방법까지 매핑 사전. fileExtensions:
json: toPrettyJson
yaml: toYaml
yml: toYaml
serialization.secret.enabled enabled 경우 fileExtensions 에 따른 매핑 된 파일 확장자는 기본적으로 주어진 직렬화 방법으로 직렬화됩니다. data 키가 매핑 된 확장자 중 하나로 끝나면 값의 직렬화 메소드는 컨텐츠를 문자열에 쓰는 데 사용됩니다. 비밀 data 입력의 특정 serialization 필드는 기본 설정을 덮어 씁니다. true
serialization.secret.fileExtensions 파일 확장에서 직렬화 방법까지 매핑 사전. fileExtensions:
json: toPrettyJson
yaml: toYaml
yml: toYaml
config.general.rbac RBAC 객체를 설치할 수있는 글로벌 스위치.

true 인 경우 모든 활성화 된 RBAC 객체가 클러스터에 배포됩니다. false 없는 경우 RBAC 객체가 전혀 생성됩니다.

배포 가능한 RBAC 객체는 다음과 같습니다.
roles
rolebindings
clusterroles
clusterrolebindings		 true false
config.general.data 이 필드의 서브 필드는 제품 제품군의 맥락에서 명확하게 정의 된 의미를 가져야합니다.

예를 들어, 모든 제품이나 마이크로 서비스 (각각 별도의 헬름 차트로 오는)가 주어진 주어진 엔드 포인트 (인증, 구성, ...)에 따라 다릅니다. 해당 엔드 포인트를 대상으로하는 각 Helm 차트에서 실행 된 공유 Kubernetes 작업이있을 수 있습니다. 이제 작업 사양과 ​​엔드 포인트 정의를 포함하는 외부 선체 values.yaml 지정할 수 있습니다. 여기에는 오버레이 values.yaml 맞추고 구축하는 방식으로 각 배치 위에 렌더링되고 통합 메커니즘이 있습니다.		 {}
config.general.metadata 여기서 정의 된 메타 데이터 필드는 모든 객체 메타 데이터에 자동으로 추가됩니다.

다음 하위 필드 만 있습니다.

labels
annotations
config.general.metadata.labels 모든 객체에 추가되는 레이블. common 레이블은 Kubernetes 및 Helm 공통 레이블을 나타내며 custom 라벨을 자유롭게 지정할 수 있습니다.

다음 하위 필드 만 있습니다.

common
custom
config.general.metadata.labels.common https://helm.sh/docs/chart_best_practices/labels/ 및 https://kubernetes.io/docs/concepts/overview/with-bjects/common-labels/에 정의 된 공통 레이블 사양.

빈 값 ( '' )으로 구체적으로 덮어 쓰지 않는 한 모든 메타 데이터 레이블은 기본 정의에 따라 모든 객체에 자동으로 추가됩니다. Helm 차트가 제품 스위트의 일부인 경우 config.general.metadata.labels.common.'app.kubernetes.io/part-of' 의 값을 설정하는 것으로 간주되어야합니다.
config.general.metadata.labels.common.'app.kubernetes.io/managed-by' 메타 데이터에 의해 관리됩니다. {{ .Release.Service }}
config.general.metadata.labels.common.'app.kubernetes.io/version' 버전 메타 데이터. {{ .Chart.AppVersion }}
config.general.metadata.labels.common.'app.kubernetes.io/part-of' 메타 데이터의 부분. "unspecified"
config.general.metadata.labels.common.'app.kubernetes.io/name' 이름 메타 데이터. {{ printf "%s-%s" .ChartName <hullObjectKey> }}
config.general.metadata.labels.common.'app.kubernetes.io/instance' 인스턴스 메타 데이터. {{ .Release.Name }}
config.general.metadata.labels.common.'app.kubernetes.io/component' 구성 요소 메타 데이터. <hullObjectKey>
config.general.metadata.labels.common.'helm.sh/chart' 헬름 메타 데이터. `{{(printf "%s-%s".chart.name .chart.version) "+" "_"}}`을 교체하십시오
config.general.metadata.labels.custom 지정된 모든 사용자 정의 레이블은이 Helm 차트의 모든 객체에 자동으로 추가됩니다. {}
config.general.metadata.annotations 모든 객체에 추가되는 주석. custom 레이블을 자유롭게 지정할 수 있습니다.

다음 하위 필드 만 있습니다.

custom .
config.general.metadata.annotations.custom 지정된 모든 사용자 정의 주석은이 Helm 차트의 모든 객체에 자동으로 추가됩니다. {}
config.specific Helm 차트에 포함 된 특정 제품에 특정한 구성 옵션을 보유하는 무료 양식 필드. 일반적으로 여기에 지정된 값은 특정 응용 프로그램이 시동시 구성을 읽는 구성 파일의 내용을 채우는 데 사용해야합니다. 따라서 config.specific 필드는 일반적으로 구성 또는 비밀에 소비됩니다. {} maxDatepickerRange: 50
defaultPoolColor: "#FB6350"
updateInterval: 60000

objects 섹션

hull.objects 아래의 최상위 객체 유형은 인스턴스를 생성하려는 지원되는 kubernetes 객체 유형을 나타냅니다. 각 객체 유형은 항목 값이 객체 속성이고 각 객체에는 자체 키가있는 객체 유형에 고유 한 사전입니다. 추가 k8s 객체 유형을 라이브러리에 필요에 따라 추가하여 쉽게 확장 할 수 있습니다.

객체 인스턴스의 키

한 가지 중요한 측면 중 하나는 모든 최상위 객체 유형의 경우 특정 유형의 인스턴스가 항상 인스턴스 및 객체 유형 조합에 고유 한 키로 식별된다는 것입니다. 그러나 다른 객체 유형의 인스턴스에서는 동일한 키를 사용할 수 있습니다.

인스턴스를 식별하는 키가 있으면 다음과 같습니다.

  • values.yaml 쌓아서 객체 속성을 다층 병합하여 서로 위에 파일을 쌓아 놓습니다. 주어진 Helm 차트에 정의 된 응용 프로그램 또는 마이크로 서비스의 기본 객체 구조를 정의하는 것으로 시작할 수 있습니다. 그런 다음 스테이징이나 생산과 같은 특정 환경에 대한 values.yaml 을 추가 할 수 있습니다. 그런 다음 values.yaml 증명에 대한 값을 추가 할 수 있습니다. 등. By uniquely identifying the instances of a particular K8s object type it becomes easy to adjust the objects properties through a multitude of layers.

  • use the key of an instance for naming the instance. All instance names are constructed by the following ground rule: {{ printf "%s-%s-%s" .Release.Name .Chart.Name key }} . This generates unique, dynamic names per object type and release + instance key combination.

    For example, assuming the parent Helm chart is named my_webservice and the release named staging and given this specification in values.yaml : 

     hull :
  objects :
    deployment :
      nginx :
        pod :
          containers :
            nginx :
              repository : nginx
              tag : 1.14.2

    a Kubernetes deployment object with the following metadata.name is created:

    my_webservice-staging-nginx

    Note that you can opt to define a static name for instances you create by adding a property staticName: true to your objects definition. If you do so the objects name will exactly match the key name you chose.

  • each particular instance can have an enabled sub-field set to true or false . This way you can predefine instances of object types in your helm charts values.yaml but not deploy them in a default scenario. Or enable them by default and refrain from deploying them in a particular environment by disabling them in an superimposed system specific values.yaml . Note that unless you explicitly specify enabled: false each instance you define will be created by default, a missing enabled key is equivalent to enabled: true .

  • cross-referencing objects within a helm chart by the instance key is a useful feature of the HULL library. This is possible in these contexts:

    • when a reference to a ConfigMap or Secret comes into play you can just use the key of the targeted instance and the dynamic name will be rendered in the output. This is possible for referencing
    • a ConfigMap or Secret behind a Volume or
    • a Secret behind an Ingress' TLS specification or
    • a ConfigMap or Secret behind an environment value added to a container spec.
    • when referencing Services in the backend of an ingress' host you can specify the key to reference the backend service.

    Note that you can in these cases opt to refer to a static name instead too. Adding a property staticName: true to the dictionary with your reference will force the referenced objects name to exactly match the name you entered.

Values of object instances

The values of object instance keys reflects the Kubernetes objects to create for the chart. To specify these objects efficiently, the available properties for configuration can be split into three groups:

  1. Basic HULL object configuration with hull.ObjectBase.v1 whose properties are available for all object types and instances. These are enabled , staticName , annotations and labels .

    Given the example of a deployment named nginx you can add the following properties of hull.ObjectBase.v1 to the object instance: 

     hull :
  objects :
    deployment :
      nginx : # unique key/identifier of the deployment to create
        staticName : true # property of hull.ObjectBase.v1
                         # forces the metadata.name to be just the <KEY> 'nginx' 
                         # and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which 
                         # would be the better default behavior of creating 
                         # unique object names for all objects.
        enabled : true    # property of hull.ObjectBase.v1
                         # this deployment will be rendered to a YAML object if enabled
        labels :
          demo_label : " demo " # property of hull.ObjectBase.v1
                             # add all labels here that shall be added 
                             # to the object instance metadata section
        annotations :
          demo_annotation : " demo " # property of hull.ObjectBase.v1
                                  # add all annotations here that shall be added 
                                  # to the object instance metadata section
        pod : 
          ... # Here would come the hull.PodTemplate.v1 definition
              # see below for details

  2. Specialized HULL object properties for some object types. Below is a reference of which object type supports which special properties in addition to the basic object configuration.

    Again given the example of a deployment named nginx you would want to add properties of the HULL hull.PodTemplate.v1 to the instance. With them you set the pod property to define the pod template (initContainers, containers, volumes, ...) and can add templateLabels and templateAnnotations just to the pods created metadata and not the deployment objects metadata section: 

     hull :
  objects :
    deployment :
      nginx : 
        staticName : true 
        enabled : true 
        labels : 
          demo_label : " demo " 
        annotations : 
          demo_annotation : " demo " 
        templateLabels : # property of hull.PodTemplate.v1 to define 
                        # labels only added to the pod
          demo_pod_label : " demo pod " 
        templateAnnotations : # property of hull.PodTemplate.v1 to define 
                        # annotations only added to the pod
          demo_pod_annotation : " demo pod "
        pod : # property of hull.PodTemplate.v1 to define the pod template
          containers :
            nginx : # all containers of a pod template are also referenced by a 
                  # unique key to make manipulating them easy.
              image :
                repository : nginx # specify repository and tag
                                  # separately with HULL for easier composability
                tag : 1.14.2
              ... # further properties (volumeMounts, affinities, ...)

  3. Kubernetes object properties. For each object type it is basically possible to specify all existing Kubernetes properties. In case a HULL property overwrites a identically named Kubernetes property the HULL property has precedence. Even if a HULL property overrides a Kubernetes property it is intended to provide the same complete configuration options, even if sometimes handled differently by HULL.

    Some of the typical top-level Kubernetes object properties and fields don't require setting them with HULL based objects because they can be deducted automatically:

    • the apiVersion and kind are determined by the HULL object type and Kubernetes API version and don't require to be explicitly set (except for objects of type customresource ).
    • the top-level metadata dictionary on objects is handled by HULL via the annotations and labels fields and the naming rules explained above. So the metadata field does not require configuration and is hence not configurable for any object.

    Some lower level structures are also converted from the Kubernetes API array form to a dictionary form or are modified to improve working with them. This also enables more sophisticated merging of layers since arrays don't merge well, they only can be overwritten completely. Overwriting arrays however can make it hard to forget about elements that are contained in the default form of the array (you would need to know that they existed in the first place). In short, for a layered configuration approach without an endless amount of elements the dictionary is preferable for representing data since it offers a much better merging support.

    So again using the example of a deployment named nginx you can add the remaining available Kubernetes properties to the object instance which are not handled by HULL as shown below. For a deployment specifically you can add all the remaining properties defined in the deploymentspec API schema from deploymentspec-v1-apps which are minReadySeconds , paused , progressDeadlineSeconds , replicas , revisionHistoryLimit and strategy . If properties are marked as mandatory in the Kubernetes JSON schema you must provide them otherwise the rendering process will fail: 

     hull :
  objects :
    deployment :
      nginx : 
        staticName : true 
        enabled : true 
        labels : 
          demo_label : " demo " 
        annotations : 
          demo_annotation : " demo " 
        pod :
          ... # Here would come the hull.PodTemplate.v1 definition
              # see above for details 
        replicas : 3 # property from the Kubernetes API deploymentspec
        strategy : # property from the Kubernetes API deploymentspec
          type : Recreate
        ... # further Kubernetes API deploymentspec options

Composing objects with HULL

Here is an overview of which top level properties are available for which object type in HULL. The HULL properties are grouped by the respective HULL JSON schema group they belong to. A detailed description of these groups and their properties is found in the documentation of this helm chart and the respective linked documents.

Workloads APIs

선체
Object Type
 선체
속성		 Kubernetes/External
속성
deployment hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 deploymentspec-v1-apps
minReadySeconds
paused
progressDeadlineSeconds
replicas
revisionHistoryLimit
strategy
job hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 jobspec-v1-batch
activeDeadlineSeconds
backoffLimit
completionMode
completions
manualSelector
parallelism
selector
suspend
ttlSecondsAfterFinished
daemonset hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 daemonsetspec-v1-apps
minReadySeconds
revisionHistoryLimit
updateStrategy
statefulset hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 statefulsetspec-v1-apps
podManagementPolicy
replicas
revisionHistoryLimit
serviceName
updateStrategy
serviceName
volumeClaimTemplates
cronjob hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Job.v1
job		 cronjobspec-v1-batch
concurrencyPolicy
failedJobsHistoryLimit
schedule
startingDeadlineSeconds
successfulJobsHistoryLimit
suspend

Service APIs

선체
Object Type
 선체
속성		 Kubernetes/External
속성
endpoints hull.ObjectBase.v1
enabled
annotations
labels
staticName		 endpoints-v1-core
subsets
endpointslice hull.ObjectBase.v1
enabled
annotations
labels
staticName		 endpointslice-v1-discovery-k8s-io
addressType
endpoints
ports
service hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Service.v1
ports		 servicespec-v1-core
allocateLoadBalancerNodePorts
clusterIP
clusterIPs
externalIPs
externalName
externalTrafficPolicy
healthCheckNodePort
internalTrafficPolicy
ipFamilies
ipFamilyPolicy
loadBalancerClass
loadBalancerIP
loadBalancerSourceRanges
publishNotReadyAddresses
selector
sessionAffinity
sessionAffinityConfig
topologyKeys
type
ingress hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Ingress.v1
tls
rules		 ingressspec-v1-networking-k8s-io
defaultBackend
ingressClassName
ingressclass hull.ObjectBase.v1
enabled
annotations
labels
staticName		 ingressclassspec-v1-networking-k8s-io
controller
parameters

Config and Storage APIs

선체
Object Type
 선체
속성		 Kubernetes/External
속성
configmap hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.VirtualFolder.v1
data		 configmap-v1-core
binaryData
immutable
secret hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.VirtualFolder.v1
data		 secret-v1-core
immutable
stringData
type
registry hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Registry.v1
server
username
password		 secret-v1-core
persistentvolumeclaim hull.ObjectBase.v1
enabled
annotations
labels
staticName		 persistentvolumeclaimspec-v1-core
accessModes
dataSource
resources
selector
storageClassName
volumeMode
volumeName
storageclass hull.ObjectBase.v1
enabled
annotations
labels
staticName		 storageclass-v1-storage-k8s-io
allowVolumeExpansion
allowedTopologies
mountOptions
parameters
provisioner
reclaimPolicy
volumeBindingMode

Metadata APIs

선체
Object Type
 선체
속성		 Kubernetes/External
속성
customresource hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.CustomResource.v1
apiVersion
kind
spec
limitrange hull.ObjectBase.v1
enabled
annotations
labels
staticName		 limitrange-v1-core
limits
horizontalpodautoscaler hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.HorizontalPodAutoscaler.v1
scaleTargetRef		 horizontalpodautoscalerspec-v2-autoscaling
behavior
maxReplicas
metrics
minReplicas
mutatingwebhookconfiguration hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.MutatingWebhook.v1
webhooks
poddisruptionbudget hull.ObjectBase.v1
enabled
annotations
labels
staticName		 poddisruptionbudgetspec-v1-policy
maxUnavailable
minAvailable
selector
validatingwebhookconfiguration hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.ValidatingWebhook.v1
webhooks
priorityclass hull.ObjectBase.v1
enabled
annotations
labels
staticName		 priorityclass-v1-scheduling-k8s-io
description
globalDefault
preemptionPolicy
value

Cluster APIs

선체
Object Type
 선체
속성		 Kubernetes/External
속성
clusterrole hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Rule.v1
rules		 clusterrole-v1-rbac-authorization-k8s-io
aggregationRule
clusterrolebinding hull.ObjectBase.v1
enabled
annotations
labels
staticName		 clusterrolebinding-v1-rbac-authorization-k8s-io
roleRef
subjects
namespace hull.ObjectBase.v1
enabled
annotations
labels
staticName		 namespace-v1-core
spec
status
persistentvolume hull.ObjectBase.v1
enabled
annotations
labels
staticName		 persistentvolumespec-v1-core
accessModes
awsElasticBlockStore
azureDisk
azureFile
capacity
cephfs
cinder
claimRef
csi
fc
flexVolume
flocker
gcePersistentDisk
glusterfs
hostPath
iscsi
local
mountOptions
nfs
nodeAffinity
persistentVolumeReclaimPolicy
photonPersistentDisk
portworxVolume
quobyte
rbd
scaleIO
storageClassName
storageos
volumeMode
vsphereVolume
role hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Rule.v1
rules		 role-v1-rbac-authorization-k8s-io
rolebinding hull.ObjectBase.v1
enabled
annotations
labels
staticName		 rolebinding-v1-rbac-authorization-k8s-io
roleRef
subjects
serviceaccount hull.ObjectBase.v1
enabled
annotations
labels
staticName		 serviceaccount-v1-core
automountServiceAccountToken
imagePullSecrets
secrets
resourcequota hull.ObjectBase.v1
enabled
annotations
labels
staticName		 resourcequotaspec-v1-core
hard
scopeSelector
scopes
networkpolicy hull.ObjectBase.v1
enabled
annotations
labels
staticName		 networkpolicyspec-v1-networking-k8s-io
egress
ingress
podSelector
policyTypes

Other APIs

선체
Object Type
 선체
속성		 Kubernetes/External
속성
servicemonitor hull.ObjectBase.v1
enabled
annotations
labels
staticName		 ServiceMonitor CRD
spec

Testing and installing a HULL based chart

To test or install a chart based on HULL the standard Helm v3 tooling is usable. See also the Helm documentation at the Helm website.

Testing a HULL based chart

To inspect the outcome of a specific values.yaml configuration you can simply render the templates which would be deployed to Kubernetes and inspect them with the below command adapted to your needs:

<PATH_TO_HELM_V3_BINARY> template --debug --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> --output-dir <PATH_TO_OUTPUT_DIRECTORY> <PATH_TO_CHART_DIRECTORY>

Install or upgrade a release:

Installing or upgrading a chart using HULL follows the standard procedures for every Helm chart:

<PATH_TO_HELM_V3_BINARY> upgrade --install --debug --create-namespace --atomic --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> <RELEASE_NAME> <PATH_TO_CHART_DIRECTORY>

First Examples

Using the nginx deployment example from the Kubernetes documentation https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment as something we want to create with our HULL based Helm chart: 

 apiVersion : apps/v1
kind : Deployment
metadata :
  name : nginx
  labels :
    app : nginx
spec :
  replicas : 3
  selector :
    matchLabels :
      app : nginx
  template :
    metadata :
      labels :
        app : nginx
    spec :
      containers :
      - name : nginx
        image : nginx:1.14.2
        ports :
        - containerPort : 80

To render this analogously using the HULL library your chart needs to be setup for using HULL. In the following section we assume the parent Helm chart is named hull-test and we use the helm template command to test render the values.yaml 's.

Minimal Example

A minimal example of creating the expected result from above would be to create a values.yaml like below in your parent chart (commented with some explanations). Note that some default features of HULL such as RBAC and dynamic naming are explicitly disabled here to obtain the output matching the above example closely: 

 hull :
  config :
    general :
      rbac : false # Don't render RBAC objects. By default HULL would provide 
                  # a 'default' Role and 'default' RoleBinding associated with 
                  # a 'default' ServiceAccount to use for all pods.
                  # You can modify this as needed. Here we turn it off to not 
                  # render the default RBAC objects.
  objects :
    serviceaccount :
      default :
        enabled : false # The release specific 'default' ServiceAccount created
                       # for a release by default is disabled here. In this case 
                       # it will not be rendered out and automatically used as 
                       # 'serviceAccountName' in the pod templates. 
    deployment :
      nginx : # all object instances have a key used for naming the objects and 
             # allowing to overwrite properties in multiple values.yaml layers
        staticName : true # forces the metadata.name to be just the <KEY> 'nginx' 
                         # and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which 
                         # would be the better default behavior of creating 
                         # unique object names for all objects.
        replicas : 3
        pod :
          containers :
            nginx : # all containers of a pod template are also referenced by a 
                   # unique key to make manipulating them easy.
              image :
                repository : nginx
                tag : 1.14.2
              ports :
                http : # unique key per container here too. All key-value structures
                      # which are finally arrays in the K8S objects are converted to 
                      # arrays on rendering the chart.
                  containerPort : 80

This produces the following rendered deployment when running the helm template command (commented with some brief explanations): 

 apiVersion : apps/v1 # derived from object type 'deployment'
kind : Deployment # derived from object type 'deployment'
metadata : 
  annotations : {}
  labels : # standard Kubernetes metadata is created always automatically.
    app.kubernetes.io/component : nginx 
    app.kubernetes.io/instance : release-name
    app.kubernetes.io/managed-by : Helm
    app.kubernetes.io/name : hull-test
    app.kubernetes.io/part-of : undefined
    app.kubernetes.io/version : 1.31.0
    helm.sh/chart : hull-test-1.31.0
  name : nginx # default name would be 'release-name-hull-test-nginx' 
              # but with staticName: true in the HULL spec it is just the key name
spec :
  replicas : 3
  selector : # selector is auto-created to match the unique metadata combination 
            # found also in the in the object's metadata labels.
    matchLabels :
      app.kubernetes.io/component : nginx
      app.kubernetes.io/instance : release-name
      app.kubernetes.io/name : hull-test
  template :
    metadata :
      annotations : {}
      labels : # auto-created metadata is added to pod template 
        app.kubernetes.io/component : nginx
        app.kubernetes.io/instance : release-name
        app.kubernetes.io/managed-by : Helm
        app.kubernetes.io/name : hull-test
        app.kubernetes.io/part-of : undefined
        app.kubernetes.io/version : 1.31.0
        helm.sh/chart : hull-test-1.31.0
    spec :
      containers :
      - env : []
        envFrom : []
        image : nginx:1.14.2
        name : nginx
        ports :
        - containerPort : 80
          name : http # name 'http' derived from the key of the port 
                     # object defined in the values.yaml
        volumeMounts : []
      imagePullSecrets : {}
      initContainers : []
      volumes : []

고급 예

Now to render the nginx deployment example showcasing extra features of the HULL library you can could create the below values.yaml file in your parent chart. Note that this is a very advanced example of what is possible using this library chart.

This example highlights:

  • hierarchical metadata handling
  • default RBAC setup of objects
  • dynamic naming mechanism
  • transformations
  • easy inclusion of ConfigMaps and/or Secrets 
 hull :
  config :
    general :  # This time we are not setting rbac: false 
              # so RBAC default objects are created. 
              # If the default objects don't match the use-case
              # you can tweak all aspects individually if needed
      metadata :
        labels :         
          custom : # Additional labels added to all K8S objects
            general_custom_label_1 : General Custom Label 1
            general_custom_label_2 : General Custom Label 2
            general_custom_label_3 : General Custom Label 3
        annotations : 
          custom : # Additional annotations added to all K8S objects
            general_custom_annotation_1 : General Custom Annotation 1
            general_custom_annotation_2 : General Custom Annotation 2
            general_custom_annotation_3 : General Custom Annotation 3
    specific : # Put configuration options specific to this chart here
      nginx_tag : 1.14.2 # You can also use entries here to globally 
                        # define values that are referenced in multiple
                        # places in your chart. See how this field 
                        # is accessed below in the deployment.

  objects :
    deployment :
      _HULL_OBJECT_TYPE_DEFAULT_ : # A special object key available for
                                  # all object types allowing defining 
                                  # defaults for properties of all object 
                                  # type instances created.
        annotations :  
          default_annotation_1 : Default Annotation 1
          default_annotation_2 : Default Annotation 2
          general_custom_annotation_2 :  Default Annotation 2  # overwriting this 
                                                              # general annotation for
                                                              # all deployments
          
        labels :
          default_label_1 : Default Label 1
          default_label_2 : Default Label 2
          general_custom_label_2 :  Default Label 2 # overwriting this 
                                                   # general label for
                                                   # all deployments
          
      nginx : # specify the nginx deployment under key 'nginx'
        # This time we're not setting the metadata.name to be static so 
        # name will be created dynamically and will be unique
        annotations :
          general_custom_annotation_3 : Specific Object Annotation 3 # overwrite a
                                                                    # general annotation
          default_annotation_2 : Specific Object Annotation 2 # overwrite a default annotation
          specific_annotation_1 : Specific Object Annotation 1 # add a specific annotation 
                                                              # to the all this object's metadata
        labels : 
          general_custom_label_3 : Specific Object Label 3 # overwrite a
                                                          # general label
          default_label_2 : Specific Object Label 2 # overwrite a default label
          specific_label_1 : Specific Object Label 1 # add a specific label 
                                                    # to the all this object's metadata
        templateAnnotations :
          specific_annotation_2 : Specific Template Annotation 2 # this annotation will only appear 
                                                                # in the pod template metadata
        templateLabels :
          specific_label_2 : Specific Template Label 2 # this label will only appear 
                                                      # in the pod template metadata
        replicas : 3
        pod :
          containers :
            nginx : # all containers of a pod template are also referenced by a 
                   # unique key to make manipulating them easy.
              image :
                repository : nginx
                tag : _HT!{{ (index . "$").Values.hull.config.specific.nginx_tag }}
                  # Applies a tpl transformation allowing to inject dynamic data based
                  # on values in this values.yaml into the resulting field (here the tag
                  # field of this container).
                  # _HT! is the short form of the transformation that applies tpl to
                  # a given value. This example just references the value of the field 
                  # which is specified further above in the values.yaml and will 
                  # produce 'image: nginx:1.14.2' when rendered in the resulting 
                  # deployment YAML but complex conditional Go templating logic is 
                  # applicable too. 
                  # There are some limitations to using this approach which are 
                  # detailed in the transformation.md in the doc section.
              ports :
                http : # unique key per container here too. All key-value structures
                      # which are array in the K8S objects are converted to arrays
                      # on rendering the chart.
                  containerPort : 80
    configmap : # this is to highlight the secret/configmap inclusion feature
      nginx_configmap : # configmap objects have keys too
        data : # specify for which contents a data entry shall be created
              # within only a few lines of configuration. Contents can come from ...
          an_inline_configmap.txt : # ... an inline specified content or ...
            inline : |- 
              Top secret contents
              spread over 
              multiple lines...
          contents_from_an_external_file.txt : # ... something from an external file.
            path : files/my_secret.txt

This produces the following rendered objects when running the helm template command (commented with some brief explanations): 

---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
kind : ServiceAccount
metadata :
  annotations :
    general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
    general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
    general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
  labels :
    app.kubernetes.io/component : default
    app.kubernetes.io/instance : release-name
    app.kubernetes.io/managed-by : Helm
    app.kubernetes.io/name : hull-test
    app.kubernetes.io/part-of : undefined
    app.kubernetes.io/version : 1.31.0
    general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
    general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
    general_custom_label_3 : General Custom Label 3 # default or specific instance
    helm.sh/chart : hull-test-1.31.0
  name : release-name-hull-test-default # This is the default ServiceAccount created for this chart.
                                       # As all object instances by default it will be assigned a 
                                       # dynamically created unique name in context of this object type.
                                       # In the simple example we disabled this rendering by 
                                       # setting enabled: false for this object's key.
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : Role
metadata :
  annotations :
    general_custom_annotation_1 : General Custom Annotation 1
    general_custom_annotation_2 : General Custom Annotation 2
    general_custom_annotation_3 : General Custom Annotation 3
  labels :
    app.kubernetes.io/component : default
    app.kubernetes.io/instance : release-name
    app.kubernetes.io/managed-by : Helm
    app.kubernetes.io/name : hull-test
    app.kubernetes.io/part-of : undefined
    app.kubernetes.io/version : 1.31.0
    general_custom_label_1 : General Custom Label 1
    general_custom_label_2 : General Custom Label 2
    general_custom_label_3 : General Custom Label 3
    helm.sh/chart : hull-test-1.31.0
  name : release-name-hull-test-default # A default Role for RBAC. 
rules : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : RoleBinding
metadata :
  annotations :
    general_custom_annotation_1 : General Custom Annotation 1
    general_custom_annotation_2 : General Custom Annotation 2
    general_custom_annotation_3 : General Custom Annotation 3
  labels :
    app.kubernetes.io/component : default
    app.kubernetes.io/instance : release-name
    app.kubernetes.io/managed-by : Helm
    app.kubernetes.io/name : hull-test
    app.kubernetes.io/part-of : undefined
    app.kubernetes.io/version : 1.31.0
    general_custom_label_1 : General Custom Label 1
    general_custom_label_2 : General Custom Label 2
    general_custom_label_3 : General Custom Label 3
    helm.sh/chart : hull-test-1.31.0
  name : release-name-hull-test-default
roleRef :
  apiGroup : rbac.authorization.k8s.io/v1
  kind : Role
  name : release-name-hull-test-default
subjects :
- apiGroup : rbac.authorization.k8s.io/v1
  kind : ServiceAccount
  name : release-name-hull-test-default # A default RoleBinding for RBAC. It connects the 
                                       # default ServiceAccount with the default Role.
                                       # By default RBAC is enabled in charts.
---
# Source: hull-test/templates/hull.yaml
apiVersion : apps/v1
kind : Deployment
metadata :
  annotations :
    default_annotation_1 : Default Annotation 1 # non-overwritten default_annotation
    default_annotation_2 : Specific Object Annotation 2 # overwritten default_annotation by instance
    general_custom_annotation_1 : General Custom Annotation 1 # non-overwritten general_custom_annotation
    general_custom_annotation_2 : Default Annotation 2 # overwritten general_custom_annotation 
                                                      # by default_annotation
    general_custom_annotation_3 : Specific Object Annotation 3 # overwritten general_custom_annotation 
                                                              # by specific_annotation
    specific_annotation_1 : Specific Object Annotation 1 # added annotation for instance metadata only
  labels :
    app.kubernetes.io/component : nginx
    app.kubernetes.io/instance : release-name
    app.kubernetes.io/managed-by : Helm
    app.kubernetes.io/name : hull-test
    app.kubernetes.io/part-of : undefined
    app.kubernetes.io/version : 1.31.0
    default_label_1 : Default Label 1 # non-overwritten default_label
    default_label_2 : Specific Object Label 2 # overwritten default_label by instance
    general_custom_label_1 : General Custom Label 1 # non-overwritten general_custom_label
    general_custom_label_2 : Default Label 2 # overwritten general_custom_label by default_label
    general_custom_label_3 : Specific Object Label 3 # overwritten general_custom_label 
                                                    # by specific_label
    helm.sh/chart : hull-test-1.31.0
    specific_label_1 : Specific Object Label 1 # added label for instance metadata only
  name : release-name-hull-test-nginx
spec :
  replicas : 3
  selector :
    matchLabels :
      app.kubernetes.io/component : nginx
      app.kubernetes.io/instance : release-name
      app.kubernetes.io/name : hull-test
  template :
    metadata :
      annotations :
        default_annotation_1 : Default Annotation 1
        default_annotation_2 : Specific Object Annotation 2
        general_custom_annotation_1 : General Custom Annotation 1
        general_custom_annotation_2 : Default Annotation 2
        general_custom_annotation_3 : Specific Object Annotation 3
        specific_annotation_1 : Specific Object Annotation 1
        specific_annotation_2 : Specific Template Annotation 2 # this annotation was added only 
                                                              # for the pod template's metadata
      labels :
        app.kubernetes.io/component : nginx
        app.kubernetes.io/instance : release-name
        app.kubernetes.io/managed-by : Helm
        app.kubernetes.io/name : hull-test
        app.kubernetes.io/part-of : undefined
        app.kubernetes.io/version : 1.31.0
        default_label_1 : Default Label 1
        default_label_2 : Specific Object Label 2
        general_custom_label_1 : General Custom Label 1
        general_custom_label_2 : Default Label 2
        general_custom_label_3 : Specific Object Label 3
        helm.sh/chart : hull-test-1.31.0
        specific_label_1 : Specific Object Label 1
        specific_label_2 : Specific Template Label 2 # this label was added only 
                                                    # for the pod template's metadata
    spec :
      containers :
      - env : []
        envFrom : []
        image : nginx:1.14.2
        name : nginx
        ports :
        - containerPort : 80
          name : http
        volumeMounts : []
      imagePullSecrets : {}
      initContainers : []
      serviceAccountName : release-name-hull-test-default # the dynamically created name
      volumes : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
data :
  an_inline_configmap.txt : " Top secret contents n spread over n multiple lines... "
  contents_from_an_external_file.txt : " Whatever was in this file ... "  
kind : ConfigMap
metadata :
  annotations :
    general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
    general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
    general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
  labels :
    app.kubernetes.io/component : nginx_configmap
    app.kubernetes.io/instance : release-name
    app.kubernetes.io/managed-by : Helm
    app.kubernetes.io/name : hull-test
    app.kubernetes.io/part-of : undefined
    app.kubernetes.io/version : 1.31.0
    general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
    general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
    general_custom_label_3 : General Custom Label 3 # default or specific instance
    helm.sh/chart : hull-test-1.31.0
  name : release-name-hull-test-nginx_configmap

Read the additional documentation in the documentation folder on how to utilize the features of the HULL library to the full effect.

확장하다
추가 정보
관련 애플리케이션
추천
관련 정보 전체