Skip to main content

How to override the logging-operator-logging PVC name

Austin Doll
  • Updated

 

In some environments, there may be a need to modify the naming convention of the logging-operator-logging PVC due to the length of the name. To check where these values come from, you can describe the helmrelease object in your cluster such as the below by running:

 kubectl describe hr -n kommander logging-operator-logging

 

The output should resemble the following:

Name: logging-operator-logging
Namespace: kommander
Labels: 
  kustomize.toolkit.fluxcd.io/name=logging-operator
  kustomize.toolkit.fluxcd.io/namespace=kommander
Annotations: <none>
API Version: helm.toolkit.fluxcd.io/v2beta1
Kind: HelmRelease
Metadata:
  Creation Timestamp: 2022-03-23T17:53:18Z
Spec:
  Chart:
    Spec:
      Chart: logging-operator-logging
      Reconcile Strategy: ChartVersion
      Source Ref:
        Kind: HelmRepository
        Name: kubernetes-charts.banzaicloud.com
        Namespace: kommander-flux
      Version: 3.15.0
  Depends On:
    Name: logging-operator
    Namespace: kommander
  Install:
    Remediation:
      Retries: 30
  Interval: 15s
  Release Name: logging-operator-logging
  Upgrade:
    Remediation:
      Retries: 30
  Values From:
    Kind: ConfigMap
    Name: logging-operator-logging-3.15.0-d2iq-defaults
    Kind: ConfigMap
    Name: logging-operator-logging-overrides
    Optional: true

 

In the 'Values From' section of the helmrelease that there is an optional configmap that can be deployed for override values. To deploy this configmap, you can use the following yaml as a guide:

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: kommander-bootstrap
    meta.helm.sh/release-namespace: kommander
  labels:
    app.kubernetes.io/managed-by: Helm
  name: logging-operator-logging-overrides
  namespace: kommander //this namespace may change depending on where you have deployed your logging-operator-logging deployment to
data:
  values.yaml: |
    nameOverride: "<your name>"
    fluentd:
      resources:
        limits:
          memory: 400Mi
          cpu: 1000m
        requests:
          memory: 100Mi
          cpu: 500m
    bufferStorageVolume:
      pvc:
        spec:
          resources:
            requests:
              storage: 10Gi
    fluentbit:
      resources:
        limits:
          cpu: 700m
          memory: 750Mi
        requests:
          cpu: 350m
           memory: 350Mi

 

The responsible entry will be the 'nameOverride' section in the values.yaml, please note that this name will override the naming convention of the PVC, the pods, and deployment associated with the logging-operator-logging. Once you have deployed the configmap the helmrelease should reconcile and update on its own. If you do not see your changes reflected, you can delete the helmrelease to get the controller to reconcile by running kubectl delete hr -n kommander logging-operator-logging. After this, give the controller a few minutes to reconcile and validate the status of your deployment by running kubectl get pods -n kommander -l app.kubernetes.io/name=fluentbit:

NAME READY STATUS RESTARTS AGE
mynameoverride-fluentbit-4bq2k 1/1 Running 0 2m16s
mynameoverride-fluentbit-6bv8z 1/1 Running 0 2m16s
mynameoverride-fluentbit-ngzkr 1/1 Running 0 2m16s
mynameoverride-fluentbit-qk94m 1/1 Running 0 2m16s

 

Troubleshooting

If you have deployed the override configmap but are still not seeing your configuration update. Start by getting the helmrelease by running kubectl get hr -n kommander logging-operator-logging:

NAME                     READY STATUS     
logging-operator-logging False Helm upgrade failed: error validating "": error validating data: ValidationError(Logging.spec.fluentd): unknown field "requests" in io.banzaicloud.logging.v1beta1.Logging.spec.fluentd

In this case, the helmrelease failed due to the configuration of the requests field in the fluentd portion of our yaml. If you run into an error similar to this, you can simply update your configmap to correct the poorly formatted yaml. Wait a few minutes, roughly five, and let the controller reconcile. If there is no progress, you can remove the logging-operator-logging helmrelease and watch it from there. Repeat these steps until all errors are cleared, and you see your changes present in your deployment.