Skip to content

document workaround for bitnami registry deprecation #1956

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 14, 2025
Merged

document workaround for bitnami registry deprecation #1956

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6018c5e
document workaround for bitnami registry deprecation
SimonTheLeg Aug 14, 2025
ef94c52
remove main, as this issue will not occur in newer versions
SimonTheLeg Aug 14, 2025
File filter

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions content/kubermatic/v2.26/architecture/known-issues/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,3 +52,42 @@ For an explanation how to configure an other oidc provider than dex take a look
### security implications regarding dex solution

For dex this has some implications. With this configuration a token is generated for each user session. The number of objects stored in kubernetes regarding refresh tokens has no limit anymore. The principle that one refresh belongs to one user/client pair is a security consideration which would be ignored in that case. The only way to revoke a refresh token is then to do it via grpc api which is not exposed by default or by manually deleting the related refreshtoken resource in the kubernetes cluster.

## Workaround for the Bitnami registry changes if upgrade is not possible

Customers who are completely unable to upgrade to KKP patch version 2.26.12 or above, may use a workaround.
This should be treated as a last resort method and comes with downsides on future upgrades. Specifically, with the patch releases, we are also moving to mirrored helm-charts to ensure stability and independence going forward. This workaround will not migrate to the mirrored charts, it will only switch images.

Workaround in detail:

1. Add the following to your mla values.yaml at the top level:

```yaml
cortex:
memcached-blocks-index:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
memcached-blocks:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
memcached-blocks-metadata:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
```

2. Re-run the mla installation process in accordance with the [official documentation](../../tutorials-howtos//monitoring-logging-alerting//user-cluster/admin-guide/#installing-mla-stack-in-a-seed-cluster) with a kubermatic installer matching your current KKP version.
39 changes: 39 additions & 0 deletions content/kubermatic/v2.27/architecture/known-issues/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,3 +52,42 @@ For an explanation how to configure an other oidc provider than dex take a look
### security implications regarding dex solution

For dex this has some implications. With this configuration a token is generated for each user session. The number of objects stored in kubernetes regarding refresh tokens has no limit anymore. The principle that one refresh belongs to one user/client pair is a security consideration which would be ignored in that case. The only way to revoke a refresh token is then to do it via grpc api which is not exposed by default or by manually deleting the related refreshtoken resource in the kubernetes cluster.

## Workaround for the Bitnami registry changes if upgrade is not possible

Customers who are completely unable to upgrade to KKP patch version 2.27.7 or above, may use a workaround.
This should be treated as a last resort method and comes with downsides on future upgrades. Specifically, with the patch releases, we are also moving to mirrored helm-charts to ensure stability and independence going forward. This workaround will not migrate to the mirrored charts, it will only switch images.

Workaround in detail:

1. Add the following to your mla values.yaml at the top level:

```yaml
cortex:
memcached-blocks-index:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
memcached-blocks:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
memcached-blocks-metadata:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
```

2. Re-run the mla installation process in accordance with the [official documentation](../../tutorials-howtos//monitoring-logging-alerting//user-cluster/admin-guide/#installing-mla-stack-in-a-seed-cluster) with a kubermatic installer matching your current KKP version.
39 changes: 39 additions & 0 deletions content/kubermatic/v2.28/architecture/known-issues/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -112,3 +112,42 @@ spec:
```

This sets `--xfr-channel-size=300` flag for Konnectivity Agent, which runs on the user cluster.

## Workaround for the Bitnami registry changes if upgrade is not possible

Customers who are completely unable to upgrade to KKP patch version 2.28.2 or above, may use a workaround.
This should be treated as a last resort method and comes with downsides on future upgrades. Specifically, with the patch releases, we are also moving to mirrored helm-charts to ensure stability and independence going forward. This workaround will not migrate to the mirrored charts, it will only switch images.

Workaround in detail:

1. Add the following to your mla values.yaml at the top level:

```yaml
cortex:
memcached-blocks-index:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
memcached-blocks:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
memcached-blocks-metadata:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached
metrics:
image:
registry: quay.io
repository: kubermatic-mirror/images/memcached-exporter
```

2. Re-run the mla installation process in accordance with the [official documentation](../../tutorials-howtos//monitoring-logging-alerting//user-cluster/admin-guide/#installing-mla-stack-in-a-seed-cluster) with a kubermatic installer matching your current KKP version.