CONFIGURATION.md

Configuration - Helm

^{(Back to Readme)}

The Helm chart follows the library pattern, containing all reusable functions. All variables are parameterized, ensuring there are no hardcoded values or unnecessary volumes within the deployment.

• Helm - Library
• Helm - Values

Configuration - Overlay

^{(Back to Readme)}

The overlay configuration works in conjunction with the source configuration. The source configuration serves as the foundation, while the overlay configuration provides the final adjustments overriding or adding elements to the source configuration. This approach allows you to retain 99% of your original configuration and only modify the 1% that differs from the base.

• $\color{#FAFAD2}{\textsf{Source}}$

  • The source configuration defines a template to be used for the overlays.

    # @kubernetes pod(s) configuration
    Pod:
    - metadata:
        name: bannana-pod 
      spec:
        containers:
        - name: bannana 
          command: [ "tail", "-f", "/dev/null" ]
    
    # @kubernetes pvc(s) configurations
    #PersistentVolumeClaim:
    
    # @kubernetes cm(s) configurations
    #ConfigMap:
    
    # @kubernetes pv(s) configurations
    #PersistentVolume:    
    

• $\color{#EEE8AA}{\textsf{Overlay}}$

  • The overlay configuration overrides the source configuration using the names field as the reference point during the merging process.

    apiVersion: kubeforge.sh/v1
    kind: Overlay
    metadata:
      name: "bannana" 
    spec:
      data:
        Pod:
          - metadata:
              name: bannana-pod 
            spec:
              containers:
              - name: bannana 
                image: busybox 
    

  • $\color{#EE82EE}{\textsf{Examples}}$

    
    

    Here are two examples of overlays, banana and apple, each utilizing the source configuration defined above.
    The resulting outputs will be the pods named mybanana-pod and myapple-pod

    • $\color{#DA70D6}{\textsf{Bannana}}$

      
      

      ---
      apiVersion: kubeforge.sh/v1
      kind: Overlay
      metadata:
        name: "bannana" 
        annotations:
          "helm.sh/hook": test
      spec:
        data:
      # @kubernetes pod(s) configurations
          Pod:
            - metadata:
                # name should match with sourceConfiguration
                name: bannana-pod 
                annotations:
                  # "metal.io/override-name" annotation allows overriding the final Pod's name
                  # during the manifest rendering phase. Since metadata.name is immutable and used
                  # for merging configurations, the annotation is parsed by the rendering tool
                  # to generate the final Pod name before deployment.
                  kubeforge.sh/override-name: "mybannana-pod"
              spec:
                containers:
                  - name: bannana 
                    image: busybox 
                    volumeMounts:
                      - name: bannana-pvc 
                        mountPath: /opt/config
                        subPath: config
                volumes:
                  - name: bannana-pvc 
                    persistentVolumeClaim:
                      claimName: bannana-pvc 
      
      # @kubernetes pvc(s) configurations
          PersistentVolumeClaim:
            - metadata:
                name: bannana-pvc
                annotations:
                  magic: "my-bannana-pvc"
              spec:
                accessModes:
                  - ReadWriteMany
                resources:
                  requests:
                    storage: 20Gi
                storageClassName: storage-local-retain
      
      # @kubernetes cm(s) configurations
          ConfigMap:
            - metadata:
                name: bannana-cm 
                annotations:
                  magic: "my-bannana-cm"
              data:
                config: |
                  lorem-ipsum
      ...
      

    • $\color{#BA55D3}{\textsf{Apple}}$

      
      

      ---
      apiVersion: kubeforge.sh/v1
      kind: Overlay
      metadata:
        name: "apple"
        annotations:
          "helm.sh/hook": test
      spec:
        data:
       
      # @kubernetes pod(s) configurations
          Pod:
            - metadata:
                # name should match with sourceConfiguration
                name: bannana-pod 
                annotations:
                  # "metal.io/override-name" annotation allows overriding the final Pod's name
                  # during the manifest rendering phase. Since metadata.name is immutable and used
                  # for merging configurations, the annotation is parsed by the rendering tool
                  # to generate the final Pod name before deployment.
                  kubeforge.sh/override-name: "myapple-pod"
              spec:
                containers:
                  - name: bannana 
                    image: busybox 
                    volumeMounts:
                      - name: apple-pvc 
                        mountPath: /opt/config
                        subPath: config
                volumes:
                  - name: apple-pvc 
                    persistentVolumeClaim:
                      claimName: apple-pvc 
      
      # @kubernetes pvc(s) configurations
          PersistentVolumeClaim:
            - metadata:
                name: apple-pvc
                annotations:
                  magic: "my-apple-pvc"
              spec:
                accessModes:
                  - ReadWriteMany
                resources:
                  requests:
                    storage: 20Gi
                storageClassName: storage-local-retain
      
      # @kubernetes cm(s) configurations
          ConfigMap:
            - metadata:
                name: apple-cm 
                annotations:
                  magic: "my-apple-cm"
              data:
                config: |
                  lorem-ipsum
      ...