fluxcd-community / helm-charts Goto Github PK
View Code? Open in Web Editor NEWCommunity maintained Helm charts for Flux
License: Apache License 2.0
Community maintained Helm charts for Flux
License: Apache License 2.0
no
generate imageTags for all controller:
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L18
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L28
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L68
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L90
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L112
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L153
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L175
since #45 we have a generator in-place to fetch all crds from flux2 upstream - add function to generate imageTags out of URLs in kustomization.yaml https://github.com/fluxcd/flux2/blob/main/manifests/crds/kustomization.yaml#L4-L9
eg. set imageTags in values.yaml with yq
for FILE in `cat .work/flux2/manifests/crds/kustomization.yaml | grep -Eo "(http|https)://[a-zA-Z0-9./?=_%:-]*"`
do
tag=$(cat version from ${FILE}) yq e -i '.controller.tag = env(tag)' ./charts/flux2/values.yaml
done
yq expression for each controller:
.cli. tag
.helmcontroller.tag
.imageautomationcontroller.tag
.imagereflectorcontroller.tag
.kustomizecontroller.tag
.notificationcontroller.tag
.sourcecontroller.tag
no
No response
Given that these charts are community maintained, what's the expected time frame from the moment a Flux release is published to the moment flux2
and flux2-sync
charts are updated and released?
Should we add a notice to the main readme and to each chart readme that delays are expected and there are no guarantees about keeping up with upstream?
Support passing in extraEnv variables to helmController, notificationController, kustomizationController, sourceController
Support passing in extraEnv variables to helmController, notificationController, kustomizationController, sourceController
.
No response
While using flux2-sync
chart the naming of the file kustomization.yaml
is causing problems during automations where by convention it is considered to be kustomization file of apiVersion: kustomize.config.k8s.io/v1beta1
.
So, we get the error: json: unknown field \"spec\"
We could rename the file kustomization.yaml
to sync-kustomization.yaml
or something else.
After the manifests are generated using helm template
, manually renaming the file kustomization.yaml
fixes the problem.
One example would be,
we could give the path of flux2-sync-templates
as the kustomization path for a flux deployment, in such cases kustomization.yaml
generated by flux2-sync helm chart.
In such cases, we get the error
couldn't make target for path '/tmp/kustomization-3076028919/development/application/flux2/charts/flux2-sync/templates': json: unknown field \"spec\"
I'd like to migrate from using flux install --export
to using the flux2 helm chart. However our usage of flux
currently takes advantage of some of the extra flags that flux install
supports. Specifically we do not download containers from the internet, so the container images need to come from an internal repository and need to use an image-pull-secret (which is already available in the k8s cluster).
it would stand to reason that there is a need for the optional flux
arguments, i.e. being able to set these values will be needed by other users who would like to migrate.
The flux 0.24.1 version currently supports
option | description | helm chart 0.8.0 equivalent (if present) |
---|---|---|
--cluster-domain | internal cluster domain (default "cluster.local") | |
--components | list of components, accepts comma-separated values (default [source-controller,kustomize-controller,helm-controller,notification-controller]) | create boolean values |
--components-extra | list of components in addition to those supplied or defaulted, accepts comma-separated values | create boolean values |
--image-pull-secret | Kubernetes secret name used for pulling the toolkit images from a private registry | |
--network-policy | deny ingress access to the toolkit controllers from other namespaces using network policies (default true) | |
--registry | container registry where the toolkit images are published (default "ghcr.io/fluxcd") | image setting for each controller |
--toleration-keys | list of toleration keys used to schedule the components pods onto nodes with matching taints | tolerations array values |
--version | toolkit version, when specified the manifests are downloaded from https://github.com/fluxcd/flux2/releases | chart version |
--watch-all-namespaces | watch for custom resources in all namespaces, if set to false it will only watch the namespace where the toolkit is installed (default true) | watchallnamespaces boolean value |
At a minimum I'd like a new value variable defined for the image-pull-secret
setting which would apply to all controllers.
Although for my use case it would be sufficient to add a stanza to the sa-*
(service account) templates, the flux install
manifests add the stanza to the deployment specs, so probably that would be the way to do it so it doesn't assume use of serviceaccount: create: true
.
A more general solution would cover the other empty cases in the table above: cluster-domain
and network-policy
flux install --export
.Relevant abridged snippet of a manifest generated by flux install --export --image-pull-secret mysecret --registry myartifactory.mycompany.net/fluxcd
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: helm-controller
namespace: flux-system
spec:
template:
spec:
containers:
- args:
- --watch-all-namespaces=true
image: myartifactory.mycompany.net/fluxcd/helm-controller:v0.14.1
imagePullSecrets:
- name: mysecret
In our environments, we do not use the default cluster domain of cluster.local -- this either needs to be a variable, or allow resolv search domains to be used by dropping the domain.
I'm struggling setting a multiline git ignore configuration like:
gitRepository:
spec:
url: repository_url
ref: {"branch": "branch"}
ignore: |
# exclude all
/*
# include deploy dir
!/cluster-name/fluxcd-applications
This results in:
Error: YAML parse error on flux2-sync/templates/flux-gitrepository.yaml: error converting YAML to JSON: yaml: line 20: could not find expected ':'
3.9.4
v1.24.3
1.0.0
No response
No response
No response
gitRepository:
spec:
ignore: |
# exclude all
/*
# include deploy dir
!/cluster-name/fluxcd-applications
helm upgrade -n flux-system -f x fluxcd-apps fluxcd-community/flux2-sync
No response
Currently, after #102 was merged, it is now possible to allow the flux-sync
helm chart create (using the flux-cli
) the SSH keys that would be used to push and pull to Git. However, for use in Crossplane (where I am using it), there is no way of getting the identity.pub
where I can pass it to a Gitlab
provider to create the Deploy key.
In spirit of "if you don't ask you don't get" (although in this case, I think I know what the answer is), do people feel it would be possible to create another wrapper around the flux-cli
where it only creates the deploy key to gitlab / github based on the SSH keys it created previously? Currently, reading the docs, it doesn't seem that there is a dedicated command on the flux-cli
and only possible via the flux bootstrap
command?, but wondering if there was another way someone felt this would be possible? This would reduce complexity in the flavours of Crossplane compositions (see below) that attempts to install Flux, and the SSH keys and create the DK in the relevant Git repository. Instead, there would only need to be a flux-install
and a flux-sync
step, and no others.
Several flavours in Crossplane
connectionDetailsSecret
flux-sync
resource - but not possible to do yet as connectionDetailsSecret
aren't referenceable in Crossplane resources yet. crossplane/crossplane#2772flux-sync
create the SSH keysflux-sync
Chart to create the keys and known_hosts
in remote clusteridentity.pub
from remote cluster and share it with a Gitlab crossplane provider in order to create the deploy keyObjects
from remote clusters crossplane-contrib/provider-kubernetes#41No response
With Helm OCI being GA, I think we should also publish the charts to GitHub Container Registry. An example of how to push to GHCR from GH Actions can be found here: https://github.com/stefanprodan/podinfo/blob/master/.github/workflows/release.yml#L71
PS. After we push the charts to GHCR, we need to use the GH UI and make the images public.
I will like to have an option like this jetstack/cert-manager@master/deploy/charts/cert-manager/values.yaml#L42
Created this issue to remind me about #1 (comment)
See this issue: fluxcd/helm-controller#542
The problem is that the CRD is not up2date:
See
https://github.com/fluxcd-community/helm-charts/blame/main/charts/flux2/templates/helm-controller.crds.yaml#L723
vs
https://github.com/fluxcd/helm-controller/blame/main/config/crd/bases/helm.toolkit.fluxcd.io_helmreleases.yaml#L708
v3.9.4
v3.9.4
1.6.0
No response
No response
No response
No response
N/A
No response
With latest release I get an error in pre-hook that only 1.19 is supported.
Can you support 1.18?
is there some feature that is not supported in 1.18? if yes, could you do some if logic to support both?
Also, please add this kind of information in the main readme.
Thanks.
Support 1.18 release as well.
We think to migrate newer version, but until that, we would be blocked to use this chart until that if you cannot support 1.18.
No response
Please update the flux2 chart to match the v0.30.2 release. Note that v0.30 comes with RBAC, CRDs and controller's flag changes.
Check if the chart comply to all best practices:
https://helm.sh/docs/chart_best_practices/conventions/
When installing the chart on an AKS cluster with an Azure Firewall as egress, the Helm install fails with the following log in the flux-check job:
Kubernetes API call failed: Get "https://10.0.0.1:443/version": EOF
The IP address 10.0.0.1 is being pulled from the KUBERNETES_SERVICE_HOST env variable that is set.
To set the env variables to use the FQDN instead of IP addresses, Microsoft has released an annotation:
kubernetes.azure.com/set-kube-service-host-fqdn: "true"
The ability to add annotations in the Flux2 Chart pre-install-job.yaml file under spec.template.metadata.
Setting environment variables directly which also isn't supported and a bit more challenging as that would require the API address to be passed in.
No response
@dwerder has been contributing significant features to helm-charts
over the past few weeks He has also been responsive and reactive to opened issues and fixes.
This issue proposes adding @dwerder as a helm-charts
maintainer. Existing maintainers should indicate votes in the comments.
Currently, when we use the flux-sync
chart, we are given the option of creating the secret in the desired cluster. When we use Crossplane, we have to provide the secret data that we want the chart to create. But it isn't possible to create those keys in the Crossplane composition and pass them into the flux-sync
chart.
Can we implement functionality that allows this chart to create those keys if specified? We could then use a kubernetes
provider in Crossplane to retrieve the public
key to then use it further in the composition when creating deploy keys in Gitlab / Github.
I've tried to use the terraform
Crossplane provider, with the tls
provider in Terraform to generate those keys.
forProvider:
source: Inline
module: |
// Outputs are written to the connection secret.
output "private_key" {
value = tls_private_key.flux_deploy_keys.private_key_pem
sensitive = true
}
output "public_key" {
value = tls_private_key.flux_deploy_keys.public_key_pem
sensitive = false
}
resource "tls_private_key" "flux_deploy_keys" {
algorithm = "ECDSA"
ecdsa_curve = "P256"
}
However, the private_key
(because it is marked as sensitive) is output into the connection details secret which means I cannot retrieve the value for the flux-sync
Chart. Pending crossplane/crossplane#2772.
We are trying to create clusters and install Flux onto those clusters with Crossplane. We can create the cluster, install Flux on it, but we cannot create / give the asymmetric keys to the flux-sync
Helm Chart that is used to create the flux-system
secret that the source-controller
needs in order to clone the repo.
While using flux-sync
helm chart, to deploy the flux changes.
I either use helm template
to get the k8s manifests and do k apply -Rf folder-name-of-generated-manifests
or do a helm release. In both the cases, I get the error:
esource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "GitRepository" in version "source.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first
resource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "Kustomization" in version "kustomize.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first
However, when I re-run kubectl apply
it works. So, I suspect that the order in which the crds and crd instances are tried to create or incorrect.
To fix this, we could have a helm hook that ensures that the crds are installed first before the crd instances are created.
Note: I would have raised a fix for this myself but I couldn't find any .crds.yaml
file for kustomization or gitrepository crds.
3.8.2
1.24.1
0.4.0
Getting the error:
resource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "GitRepository" in version "source.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first
resource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "Kustomization" in version "kustomize.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first
The CRDs should be installed before the crd instance are tried to be created.
See the section "what happened?" it has steps to reproduce.
flux2:
enabled: false
flux2-sync:
gitRepository:
spec:
url: "https://github.com/suryapandian/podinfo"
spec:
targetNamespace: sample
helm upgrade --install flux2 ./charts/flux2
or
helm template flux-templates ./charts/flux2 \
--namespace sample \
--values tests/flux2/values.yaml \
| kubectl apply -f -
No response
no
add in ci
make generate
make helmdocs
make check-diff
so we can check that generate and helmdocs was executed in the commit and no file is changed
no
No response
Please update the Flux chart to v0.34.0 change log here https://github.com/fluxcd/flux2/releases/tag/v0.34.0
In flux-sync in values.yaml in gitRepository, the ref field expects a string value,
but in gitRepository templates it expects a map value.
ref: mybranch
Also I tried to put a map in values.yaml, for example:
ref:
branch: mybranch
but I got the same error as specifying just an string.
Error: Failed to render chart: exit status 1: coalesce.go:202: warning: destination for ref is a table. Ignoring non-table value
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(GitRepository.spec.ref): invalid type for io.fluxcd.toolkit.source.v1beta1.GitRepository.spec.ref: got "string", expected "map"
version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.16.9"}
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:41:28Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"darwin/amd64"}
flux2-sync-0.1.1
In flux-sync in values.yaml in gitRepository, the ref field expects a string value,
but in gitRepository templates it expects a map value.
ref: mybranch
Also I tried to put a map in values.yaml, for example:
ref:
branch: mybranch
but I got the same error as specifying just an string.
Error: Failed to render chart: exit status 1: coalesce.go:202: warning: destination for ref is a table. Ignoring non-table value
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(GitRepository.spec.ref): invalid type for io.fluxcd.toolkit.source.v1beta1.GitRepository.spec.ref: got "string", expected "map"
I expect following command is success:
helm diff upgrade -n flux2 -f flux2-sync-values.yaml flux2-sync fluxcd-community/flux2-sync
Specify a string value for ref field.
ref: mybranch
or
ref:
branch: mybranch
helm diff upgrade -n flux2 -f flux2-sync-values.yaml flux2-sync fluxcd-community/flux2-sync
No response
I am trying to wrap my head around flux and how it works and then once I am there work out what the best installation method is for our situation. Right now this helm chart and the terraform method are both appealing to me because we have an extensive Terraform base.
Most howto's and instructions on how to setup a clusters take you to the CLI, which is something I won't be able to do: example:
https://github.com/fluxcd/flux2-kustomize-helm-example#bootstrap-staging-and-production
flux bootstrap github \
--context=staging \
--owner=${GITHUB_USER} \
--repository=${GITHUB_REPO} \
--branch=main \
--personal \
--path=clusters/staging
Is there a way in this chart to complete this setup?
Some sort of secret that one the chart is applied I can create that creates this config or better yet a secret in the chart.
so far apart from the CLI method, I have only found this method in the terraform provider.
https://registry.terraform.io/providers/fluxcd/flux/latest/docs/guides/github
https://registry.terraform.io/providers/fluxcd/flux/latest/docs/data-sources/sync
Ohhhhhhhhhhhhhhh, it just dawned on me..... Is that what the flux2-sync chart is for in this repo? Please confirm. Maybe some doco and examples should be created in this repo and you can use my feature request here as a corner stone for an example.
When you have PSPs or anything equivalent set up in the cluster which denies Pods from running as root, the Installation of the helm chart will fail, because of the failing Pre-install hook (fux-cli seems to be running as root by default). There is currently also no workaround for this (ok, one very dirty of giving the default service account those privileged rights), because postrender scripts are not evaluated for helm hooks because of a bug in helm (helm/helm#7891).
v3.7.0
v1.22.2
flux2-0.8.6
Installation fails
Installation succeeds
NONE
helm install flux2 fluxcd-community/flux2 -n flux-system
There should be some easy solutions for this like
i could also help implementing it
No problem, just keep up with the latest version released.
Update the chart to use the new version
None
Thanks for these charts. I always found the flux bootstrap a bit of magical complex install process and the terraform flux provider unable to handle upgrades.
Currently helm3 when doing an upgrade doesn't upgrade custom resources which can lead to deployment failures because custom resources are not upgraded.
I suggest creating in the repo a crds directory and a crds_0.24.0.yaml file with the crds definitions for each chart release.
then it will be possible to just download the file and then do a
helm apply -f crds_0.24.0.yaml
before doing the helm upgrade
if you think thats a good idea then i can create a PR.
alternatively you need to download the chart and extract the crds into file(s) and apply them not a big deal i guess but easy to forget.
We could just add docs in the readme of that process to remind folks instead of providing the crds file/
No response
Flux images should come from ghcr.io
:
$ flux install --export | grep ghcr
image: ghcr.io/fluxcd/helm-controller:v0.12.1
image: ghcr.io/fluxcd/kustomize-controller:v0.16.0
image: ghcr.io/fluxcd/notification-controller:v0.18.1
image: ghcr.io/fluxcd/source-controller:v0.17.1
We use just the kustomize-controller and source-controller, and we have disabled notifications controller.
however, event-addr
has a default value which is rendered
Hence, the logs are populated with the error
POST http://notification-controller/ giving up after 5 attempt(s): Post \"http://notification-controller/\": dial tcp: lookup notification-controller on 169.254.20.10:53: no such host
As a fix, we can set event-addr
to empty string when notification-controller
is set as false
3.8.2
1.24.1
1.4.0
Kustomize controller tried to make post call to notification controller even though notification controller did not exist.
kustomize controller should not try making the API call to notification controller when notification controller does not exist.
Disable notification controller and run with just source and kustomize controller.
set notification controller as false
kubectl logs of kustomize controller.
No response
Please update the Flux chart to v0.36.0 change log here https://github.com/fluxcd/flux2/releases/tag/v0.36.0
To ensure the cluster is compatible with Flux, we could use the ghcr.io/fluxcd/flux-cli:v0.23.0
image in a Kubernetes Job that runs flux check --pre
. The job could be configured as a pre-install hook.
since #55 we have issues with kustomization / kustomizationlist
values.yaml:
values:
gitRepository:
spec:
url: https://github.com/xxx.git
ref:
branch: master
kustomizationlist:
- spec:
interval: 5m
path: ./flux2-kustomize/test
prune: true
timeout: 5m
- spec:
dependsOn:
- path: ./flux2-kustomize/test
interval: 5m
path: ./flux2-kustomize/configuration
prune: true
timeout: 5m
results in: 3 kustomizations
flux-system xxx False Cluster/xxx namespace not specified, error: the server could not find the requested resource (patch clusters.xxx.io xxx)... 41m
flux-system xxx-flux2-kustomize-configuration True Applied revision: feature/flux2/a98f8afc6581d421c1e8e8b063a0191d4e7075d1 41m
flux-system xxx-flux2-kustomize-crossplane True Applied revision: feature/flux2/a98f8afc6581d421c1e8e8b063a0191d4e7075d1 41m
side note:
we have also issues if dependsOn Path and Release Name is more then 63 characters long: https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2-sync/templates/kustomization.yaml#L75
version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.17.2"}
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:31:32Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-eks-06eac09", GitCommit:"5f6d83fe4cb7febb5f4f4e39b3b2b64ebbbe3e97", GitTreeState:"clean", BuildDate:"2021-09-13T14:20:15Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}
0.3.6
No response
No response
No response
No response
kubectl
No response
Please include a secret.data: {} example as I cannot get a secret to work. This is due to the fact that It doesn't appear that data: {} accepts a multi line string which is needed to accept an ssh private key, I don't believe json accepts multiline values. can this be changed to be more multi line string friendly?
latest stable
latest stable
latest stable
json only accepts string
I expect to be able to paste an ssh key in as a string in the value and have it work
secret:
create: true
data: {"foo": "SSH KEY"}
secret:
create: true
data: {} <-- this is the problem value
i'm running via terraform via a helm_release resource but this is the same as the helm install command listed here
no
When the chart is sufficiently mature it must be published on artifacthub.io
If needing to use an Azure service principal to decrypt sops secrets, there doesn't currently exist an option to configure one via the helm values.
Following a similar approach used in the flux v1 helm chart, would like to propose these values exposed and the kustomize controller template updated (see https://github.com/MxNxPx/helm-charts/tree/kustomize-envFrom).
Updated these files:
NONE
The following branch should be ready for submitting a PR if sign off is given: https://github.com/MxNxPx/helm-charts/tree/kustomize-envFrom
We need configure https_proxy
for source controller to get those sources, but the deployment does't accept extra env vars.
Add value extraEnv
in the controller deployment.
None
No response
Please update the Flux chart to v0.32.0
Flux v0.32.0 comes with support for distributing Kubernetes manifests, Kustomize overlays and Terraform code as OCI artifacts.
For more information please see the Flux OCI documentation.
flux push|pull|tag artifact
for publishing OCI Artifacts to container registries.Please update the Flux chart to appVersion
v0.33.0
Updated to v0.33.0: https://github.com/fluxcd/flux2/releases/tag/v0.33.0
NONE
No response
https://github.com/haarchri/helm-charts-1/runs/4497426608?check_suite_focus=true
disable release step in/for forks
no
No response
Can they be separated to have a single manifest template?
helm-charts/charts/flux2/templates/helm-controller.yaml
Lines 2 to 10 in dbd6c6a
Created this issue to remind me about #1 (comment)
no
generate helmchart version with semVersion via Makefile/pre-commit
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/Chart.yaml#L5
implement checks that we can consider the version bump
example for version bump via script:
RE='[^0-9]*\([0-9]*\)[.]\([0-9]*\)[.]\([0-9]*\)\([0-9A-Za-z-]*\)'
step="$1"
if [ -z "$1" ]
then
step=patch
fi
base=$(cat charts/flux2/Chart.yaml | grep "version:" | cut -c10-)
MAJOR=`echo $base | sed -e "s#$RE#\1#"`
MINOR=`echo $base | sed -e "s#$RE#\2#"`
PATCH=`echo $base | sed -e "s#$RE#\3#"`
case "$step" in
major)
let MAJOR+=1
let MINOR=0
let PATCH=0
;;
minor)
let MINOR+=1
let PATCH=0
;;
patch)
let PATCH+=1
;;
esac
echo "$MAJOR.$MINOR.$PATCH"
in all cases the testfiles needs to be updated as well:
example for one testfile:
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/tests/__snapshot__/helm-controller_test.yaml.snap#L10
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/tests/__snapshot__/helm-controller_test.yaml.snap#L12
no
No response
Notification controller receivers allow forges like github or gitlab to send events when the repository state changes, allowing to reduce latency without unreasonable polling frequencies.
For the notification controller to be reachable, most clusters will require an ingress object in addition to the service (especially since it is hardcoded to ClusterIP
).
I believe it will be great if the flux2 helm chart allowed to configure an ingress object from values.yaml
. This object would be disabled by default to prevent accidental exposure of the notification controller.
Adding the ingress object separately from the helm chart is something possible, but causes friction as in order to locate the service from the ingress object, you need to know labels and release names that are defined inside the chart. Having to duplicate these to a separate point makes easy to accidentally misconfigure the ingress object.
If this is a feature you want to add, please LMK. I have some experience working with charts and I'm open to implement it here.
I want to run Flux with MultiTenancy Lockdown enabled. Still that is not enough for the security posture I'm looking for. Mainly because kustomize-controller and helm-controller service accounts have cluster-admin ClusterRoleBinding.
I would like to run Flux with as least privilege as possible, thus I don't want the flux service accounts to become cluster admins.
This would be fixable by adding a flag to the cluster-admin ClusterRoleBinding, the problem is that doing that, Flux wouldn't be able to do service account impersonation due to lack of permissions.
I figured out a way to do it by just adding cluster-reconciler-impersonator ClusterRole to the kustomize-controller and helm-controller.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reconciler-impersonator
rules:
- apiGroups: [""]
resources: ["serviceaccounts"]
verbs: ["impersonate"]
I would add a privileged flag to the multi-tenancy section on flux chart, like:
# -- Both kustomize-controller and helm-controller service accounts run privileged
# with cluster-admin ClusterRoleBinding. Disable if you want to run them with a
# minimum set of permissions.
privileged: true
And then give kustomize-controller / helm-controller service accounts the cluster-admin ClusterRoleBinding if Flux runs in privileged mode or give the cluster-reconciler-impersonator ClusterRoleBinding if it runs unprivileged.
I've tested this myself and it works nicely.
Doing Helm Post Render to remove cluster-admin ClusterRoleBinding and making use of extraObjects to render out the impersonator ClusterRole and ClusterRoleBinding.
No response
Great thank you. Now we can add OCI as an alternative install method to the main readme and all chart readmes.
Originally posted by @stefanprodan in #94 (comment)
Unable to use flux helm chart out of the box when targeting a corporate GitRepository (corporate ca for tls access)
Same for notification controller when targeting corporate mattermost
Id like to be able to set wether;
Currently using a Kyverno policy to set the additional volume / volumeount for our corporate ca.
This is quite specific to our environement and requires kyverno before installing flux helm chart ....
No response
We use the spec targetNamespace for some of our helm releases to install them in a particular namespace.
but the release shows up when we query kube-infrastructure namespace.
ex- helm list -n kube-infrastructure should list only the releases installed under namespace kube-infrastructure. But we get some that are installed in different namespaces.
version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.18.2"}
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-15T14:14:10Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"darwin/amd64"}
flux2-0.20.0
helm list -n kube-infrastructure list helmreleases that are not installed in kube-infrastructure namespace.
helm list -n kube-infrastructure should list only helmreleases that are installed in kube-infrastructure namespace.
No response
No response
helm list -n kube-infrastructure
No response
Sometimes, accessory to the installation there may be manifest to be installed (for example a SecretProviderClass).
It would be nice to be able to do this directly via the Chart using the approach that ArgoCD also uses.
I don't think there are alternatives
No response
prepare helm-chart for upstream flux2 0.26 release
fluxcd/flux2#2308
The flux2-sync chart is using a deprecated API for GitRepositories, please update it to v1beta2.
I think it will be nice to see in this chart a possibility to add additional args to containers. Sometimes Flux developers add new flags to services but describe everything can be not so good, so maybe it will be a good option for such cases.
I can create a pull request for it.
Something like this
containers:
- args:
- --events-addr={{ .Values.eventsaddr }}
- --watch-all-namespaces={{ .Values.watchallnamespaces }}
- --log-level={{ .Values.loglevel | default "info" }}
- --log-encoding=json
- --enable-leader-election
{{- range .Values.imagereflectorcontroller.container.additionalargs }}
- {{ . }}
{{- end}}
Maybe it is worth to add it across all containers.
No response
To reflect breaking changes in a chart you would start to increase the major semver number. So all chart version are a 0.x at the moment thats a problem. PR #61 is a good example.
I would like to release a version 1.x of each chart. So we can make it obvios, if we release a chart with breaking changes and increase the major numbers.
Maybe we collect some features we want to provide in the first 1.x releases. (IMHO we use this charts already, so I would just give it a 1.x)
No response
lables for most of the deployments not working
version.BuildInfo{Version:"v3.6.0", GitCommit:"7f2df6467771a75f5646b7f12afb408590ed1755", GitTreeState:"dirty", GoVersion:"go1.16.4"}
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-12T14:11:29Z", GoVersion:"go1.16.3", Compiler:"gc", Platform:"darwin/arm64"} Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-eks-0389ca3", GitCommit:"8a4e27b9d88142bbdd21b997b532eb6d493df6d2", GitTreeState:"clean", BuildDate:"2021-07-31T01:34:46Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}
0.4.0
message: 'create failed: failed to install release: YAML parse error on flux2/templates/kustomize-controller.yaml:
error converting YAML to JSON: yaml: line 20: mapping values are not allowed
working labels
sourcecontroller:
labels:
crossplane.io/claim-name: test
crossplane.io/claim-namespace: test
crossplane.io/composite: test
sourcecontroller:
labels:
crossplane.io/claim-name: test
crossplane.io/claim-namespace: test
crossplane.io/composite: test
crossplane composition rollout
No response
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.