nais / aivenator Goto Github PK

Hey there Chainguard here.

We noticed that you are using Chainguard Images, thank you! We wanted to make you aware of an upcoming change that will impact your project.

Starting August 16, 2023 public users will no longer be able to pull images from our registry (cgr.dev/chainguard) by tags other than latest or latest-dev. Please see the announcement for more information.

You are currently using the following.

In https://github.com/nais/aivenator/blob/d45d25d0f322223c313b3faf6fb27a4527d1b3d9/Dockerfile:

• cgr.dev/chainguard/go:1.20

Our goal is to prevent your project from experiencing any disruptions. Please see the migration guide for options.

If there's more we can do to help please reply to this issue or email us at [email protected].

Thank you!

During en masse resynchronizations, the controller/client will slow to a halt. We assume this is due to one or more of the following:

• The MaxConcurrentReconciles controller option is unset, which defaults to 1
• The CreateSecret() method is slow. This can be due to:
  • some form of rate limiting of the kube-client that communicates with the apiserver
  • some form of rate limiting of the aiven operations (create or update service users)

We should investigate and apply remediations.

Da vi skrev Aivenator fant vi ingen måte å generere keystore og truststore for JVM applikasjoner, annet enn å kalle openssl og keytool binaries. Det er litt plagsomt å installere en JRE i containeren vår bare for det toolet.

Nå finnes det alternativer, så se om det er mulig å bytte til å generere disse med Go kode.

Currently, if an AivenApplication does not have any associated ReplicaSets, we set an empty/dummy OwnerReference for the associated Secret:

The OwnerReferences for the Secret are checked during reconciliation:

and the AivenApplication is ultimately requeued none of them match the expected Kind:

This works as intended for Applications that spawn Deployments (and in turn ReplicaSets), where we want to eventually find and assign a matching ReplicaSet.

However, in the case of NaisJobs - this does not work as intended as there is never a Job nor a CronJob being assigned to the Secret's OwnerReferences - and will thus result in the AivenApplication being requeued for processing again and again.

This isn't a huge problem as there shouldn't be any changes in the Secret data between each reconciliation where the AivenApplication generation is unchanged, but we should handle it properly for NaisJobs (Jobs and CronJobs) as well.

Something is complaining that log.SetLogger was never called, but we have lots of logs.
Probably means something in controller-runtime needs to be configured or disabled ...

[controller-runtime] log.SetLogger(...) was never called, logs will not be displayed:
goroutine 148 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x5e
sigs.k8s.io/controller-runtime/pkg/log.eventuallyFulfillRoot()
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/log/log.go:59 +0xcd
sigs.k8s.io/controller-runtime/pkg/log.(*delegatingLogSink).WithValues(0xc000270580, {0xc0033500e0, 0x2, 0x2})
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/log/deleg.go:168 +0x49
github.com/go-logr/logr.Logger.WithValues(...)
	/go/pkg/mod/github.com/go-logr/[email protected]/logr.go:323
sigs.k8s.io/controller-runtime/pkg/builder.(*Builder).doController.func1(0xc0033500c0)
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/builder/controller.go:398 +0x173
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc0003c1180, {0x1be33e0, 0xc000017f90}, {0x17bd380?, 0xc0033500a0?})
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:305 +0x16a
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc0003c1180, {0x1be33e0, 0xc000017f90})
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:265 +0x1c9
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:226 +0x79
created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2 in goroutine 96
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:222 +0x565

Dagens løsning bærer preg av at vi trodde influxdb skulle forsvinne fra Aiven.
Nå har Aiven kommet tilbake og sagt at disse planene ikke lenger stemmer.

Da bør vi forbedre støtten vår litt, slik at de som ønsker å bruke InfluxDB fra Aiven får et litt bedre opplevelse. Blant annet bør vi provisjonere credentials på samme måte som vi gjør for OpenSearch som et minimum.

I samme slengen må vi oppdatere dokumentasjonen.

• Implementere handler for Influx i Aivenator
• Utvide influx biten av Naiserator (resourcecreator/aiven/influx)
• Oppdatere doc

Vi har i dag en alert for å fange opp når vi nærmer oss grensen for hvor mange service users vi kan ha. Grensen er i dag satt til 1500 i nav-prod, og 2000 i nav-dev.

Alerten er definert i nais-yaml i dag, og må implementeres i Aivenator chartet for å være med videre.

Vi har sett en markant økning i antallet Kafka serviceusers i nav-dev, sånn at vi har måttet be Aiven om å øke grensene to ganger siden rett før jul.

Det virker litt rart at det skal øke så mye, og bare i dev, så vi bør undersøke om det er noe som ikke er helt riktig.

Aiven etterlyser også om vi har noen anelse om hva vi kommer til å trenge på sikt, og det hadde nok vært lurt om vi tok et steg tilbake og tenkte gjennom hva vi tror er riktig behov her. Spesielt siden vi har begynt å se performance problemene Aiven påpeker hver gang vi ber dem øke grensen.

Grensene er per i dag 1000 i nav-prod, og 2500 i nav-dev.

Dette handler bare om å implementere handler for Redis credentials, de andre delene er i andre tasks.

Må vurdere om vi skal ha roterende regime ala Kafka, eller statiske brukere ala OpenSearch.