Deployment Plan kodo version expired¶

Description¶

After the Guance 1.93.173 version, when the page reports an expired kodo service version, you can continue using Guance by adding parameters to the service. However, being significantly behind in service versions means new features cannot be used, and when attempting to use a newer version later, due to skipping too many versions, the upgrade process becomes complicated and prone to errors. Therefore, it is recommended that private deployment projects maintain an upgrade frequency similar to SaaS iterations or do not lag more than three iterations behind the latest version.

Problem Description¶

In a private deployment environment, if the kodo service version lags behind the current SaaS version by more than 180 days, the frontend page will throw an error: kodo version older than 60 days, expired, please update, causing some Guance functions to become unavailable.

Problem Resolution¶

Add parameters to the service and restart it.

kubectl -n forethought-kodo edit deploy kodo
kubectl -n forethought-kodo edit deploy kodo-inner

          ...
          env:
            # Add the following content
            - name: KODO_DISABLE_EXPIRED_VERSION_CHECKING
              value: "true"

The latest parameter, replacing KODO_DISABLE_EXPIRED_VESION_CHECKING

          ...
          env:
            # Add the following content
            - name: KODO_DISABLE_EXPIRED_VESION_CHECKING
              value: "true"

After editing, observe whether the kodo and kodo-inner pods have restarted.