Skip to main content
  • EN

hi everyone

 

I tryd install kasten in openshift 4.11(kubernetes 1.24.6) using helm

Kasten version is 6.0.9

customer environment is airgap

install option is ================

helm install k10 k10-4.5.14.tgz --namespace kasten-io \
--set scc.create=true \                                                                                                            
--set route.enabled=true \                                                                                                       
--set route.tls.enabled=true \                                   
--set auth.openshift.enabled=true \                               
--set auth.openshift.serviceAccount=k10-dex-sa \
--set auth.openshift.clientSecret=${DEX_TOKEN} \                           
--set auth.openshift.dashboardURL=https://k10-route-kasten-io.${APPS_BASE_DOMAIN}/k10/ \  
--set auth.openshift.openshiftURL=https://${API_BASE_DOMAIN}:6443 \                       
--set auth.openshift.insecureCA=true \                                                
--set global.airgapped.repository=material.ocp4.local/kasten-images \             
--set global.persistence.storageClass=thin-csi \
--set metering.mode=airgap \                                                                                                  
--set cacertconfigmap.name=custom-ca-bundle-store \
=============================

 

All pods were normal, but an error occurred in the auth-svc pod,

I checked and the dex container continued to crashloopbak.

I approached the dex container shell with the debug function provided by the opensfit console

/etc/dex/cfg/config.yaml was logged abnormally as shown in the figure, so dexserve /etc/dex/cfg/config.All pods were normal, but an error occurred in the auth-svc pod,

I checked and the dex container continued to crashloopbak.

I approached the dex container shell with the debug function provided by the opensfit console

/etc/dex/cfg/config.yaml was recorded abnormally as shown in the figure and the dex server /etc/dex/cfg/config.yaml command was not executed

Maybe first oauth-sa.I think it's because there's a typo in the announcement part in the Yaml writing,

As it became Kuberenets 1.24, the token generation for sa was not automatically generated, so it was created separately, but the service account for the token value was 

I checked the problem that is not recorded in dex container config.yaml..

How should I solve this problem?

 

Hi @tamama3 ,

I took a look at the helm chart and found that the field you mentioned about the serviceAccount name is actually got from the value .Values.auth.openshift.serviceAccount and this should reflect the correct value  if it is set without any typo’s

    connectors:
    - type: openshift
      id: openshift
      name: OpenShift
      config:
        issuer: {{ .Values.auth.openshift.openshiftURL }}
        clientID: {{printf "system:serviceaccount:%s:%s" .Release.Namespace .Values.auth.openshift.serviceAccount }}
        clientSecret: {{ .Values.auth.openshift.clientSecret }}

Do you mind sharing the helm values from the K10 installation ?(Please redact any sensitive values in it before posting it here)

helm get values k10 -n kasten-io -o yaml

@jaiganeshjk 

 

hi jai

 

I want to show the steering value, but I am not currently visiting the customer site.

There is no scheduled date, but I will visit as soon as possible.

auth.openshfit among Helm's chart values.serviceAccount 
I told you that the value was wrong, but I don't know exactly which part is the problem.

I don't think it's a problem of typos because I created a service account called 'k10-dex-sa' in the customer company, and other settings were provided in the Kasten guide.

Can you explain it more specifically?

 

 

@tamama3 I meant that unless `--set auth.openshift.serviceAccount=k10-dex-sa` is not set, the clientID in the configmap shouldn’t end up empty or with partial name.

Would you be able to verify the currently set helm values and see if this value reflects the correct serviceAccount name ?

helm get values k10 -n kasten-io -o yaml

@jaiganeshjk 

 

hi 

I checked the set value value.

And normally, you could see the item marked serviceaccount: k10-dex-sa.

However, the dex container is still in the crashloop state.

 

 

Is it possible that it's a bug?

 

@jaiganeshjk 

 

Among the volume of the dex container included in the auth-svc pod, the config volume is mounting k10-config in kastne-io namespace.

 After checking the configmap called k10-dex

clientID.system:serviceaccount:kasten-io:same content as previously uploaded screenshots 

k10-dex-sa was missing.

Modify configmap to edit 

Verified that auth-svc pod is running normally.

Is this the case?

I think this is most likely a bug.

From the values screenshot you shared above, There seems to be a typo in the auth.openshift.serviceAccount value. 

It should be serviceAccount in camel case and not serviceaccount in lower case.

@jaiganeshjk 

 

Thank you. I didn't see the case.

Comment


Terms & Conditions