Cloudcasa Deployment Generating Undesired Deployment and Proxy Configuration

[jbbsch]

When deploying Cloudcasa, it automatically generates a second deployment that is not defined in the applied configuration.

Steps to Reproduce:

1. Apply the deployment using the provided manifest:
   kubectl apply -f https://api.cloudcasa.io/kubeclusteragents/*****.yaml

2. Modify the cloudcasa-kubeagent-manager deployment by adding proxy environment variables:

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  ...  
spec:  
  ...  
  selector:  
    matchLabels:  
      app: cloudcasa-kubeagent-manager  
  ...  
  template:  
    metadata:  
      ...  
      labels:  
        app: cloudcasa-kubeagent-manager  
    spec:  
      containers:  
        - args:  
            - /usr/local/bin/kubeagentmanager  
            - '--server_addr'  
            - agent.cloudcasa.io:443  
            - '--tls'  
            - 'true'  
            - '--skip_tls_verification'  
            - 'false'  
          env:  
            - ...  
            - name: KUBEMOVER_IMAGE  
              value: catalogicsoftware/amds-kagent:3.1.0-prod.358  
            - name: DEPLOYMENT_PLATFORM  
              value: yaml  
            - name: HTTP_PROXY  
              value: *****  
            - name: HTTPS_PROXY  
              value: *****  
            - name: NO_PROXY  
              value: *****  
          image: catalogicsoftware/amds-kagent:3.1.0-prod.358  
          ...  

After applying this change, a second deployment named kubeagent appears. This deployment is not defined in the cluster-register.yaml file and lacks the required proxy environment variables.

While it is possible to manually add the proxy environment variables to the new kubeagent deployment, this approach conflicts with our infrastructure-as-code practices, particularly as we rely on Helm charts for consistent deployments.

Impact:
The absence of proxy environment configuration in the auto-generated kubeagent deployment prevents communication with our existing Velero deployment.

Could you please provide guidance on how to address this issue? Specifically:

• How can we ensure that the proxy environment variables are automatically applied to the kubeagent deployment?
• Is there a way to configure this behavior directly within the Helm chart or through other configuration methods?

Looking forward to your response.

[draghuram]

Hi, Thanks for trying CloudCasa. As you observed, kubeagent manager comes up first and then downloads kubeagent deployment from the server. We do it this way so that we can auto update the agent without user involvement. The downside of it is that any environment specific configuration needs to be applied in CloudCasa UI so that we can build the right deployment manifest. As of today, users can configure few things such as image registry, image pull secret, cpu/memory requests and limits etc.

We are working on other configuration such as adding labels to cloudcasa-io namespace and setting security context. I am going to add the requirement you brought up to that list.