为什么Kubernetes Flux需要多个配置间隔？
我是新来的助手。 我很难理解间隔配置。我正在关注原始文档 flux
flux create source git podinfo \
--url=https://github.com/stefanprodan/podinfo \
--branch=master \
--interval=30s \
--export > ./clusters/my-cluster/podinfo-source.yaml
flux create kustomization podinfo \
--target-namespace=default \
--source=podinfo \
--path="./kustomize" \
--prune=true \
--interval=5m \
--export > ./clusters/my-cluster/podinfo-kustomization.yaml
以前的间隔（30s）应该控制磁通量的频率，而新提交的git频率应控制，而后一个间隔（5m）控制磁通量的频率将在git中应用于群集中的频率，而不管新提交如何。例如，这种使用其他方式删除的资源将被重新创建。
问题：有2个间隔有什么意义？我最好的猜测是：这是因为没有以前的间隔kustomize将有 no 最终更新其观察道路上的清单吗？相反，它将只能能够调和K8S群集中的手动更改？
I am new to Flux.
I struggle to understand the interval configuration. I am following the original doc Flux
flux create source git podinfo \
--url=https://github.com/stefanprodan/podinfo \
--branch=master \
--interval=30s \
--export > ./clusters/my-cluster/podinfo-source.yaml
flux create kustomization podinfo \
--target-namespace=default \
--source=podinfo \
--path="./kustomize" \
--prune=true \
--interval=5m \
--export > ./clusters/my-cluster/podinfo-kustomization.yaml
The former interval (30s) should control how often flux looks at Git for new commits, whereas the latter interval (5m) controls how often flux will apply what’s in git to the cluster, regardless of new commits. This is how, for example, a resource deleted using other means will be re-created.
Question: what's the point to have 2 intervals? My best guess: is it because without the former interval Kustomize would have no way to eventually update the manifests in the path it is observing? Rather it will only be able to reconcile manual changes in the k8s cluster ?!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在第一个命令中，您要创建一个GIT存储库（Kubernetes CRD），这将仪器通量检查所有30s是否以获取定义的存储库中的更新。
如果发生更改，它将应用于集群中的所有参考项目。
与GIT级别的变化无关，群集可能会漂移（通过手动更改事物。）
您的第二个命令正在创建磁通量，间隔为5m。 Kustomization间隔与GIT间隔无关。即使在最后5M内没有推动GIT的更改，Flux也会调和路径，并且每个涉及的资源每5m。
请记住，这不包括Helmreales资源输出。 （这真的很难理解，我个人想知道为什么要重新审议kustomization级别后事情不会得到和解））以进一步阅读和配置以进行磁通量helm helm Drift检测和校正检查文档： https://fluxcd.io/flux/flux/components/helm/helm/helmreleases/phelmreleases/#drift-detection/#drift-detection
In the first command you are creating a git repository (kubernetes CRD) this will instrument flux to check all 30s for updates on the defined repository.
If there is a change it will be applied to all referenced items in the cluster.
Independent of changes on git level, there can be drifts in your cluster (f.e. by changing things manually.)
Your 2nd command is creating a flux kustomization, with an interval of 5m. The kustomization interval is independent of the git interval. Even if no changes in git are pushed within the last 5m, flux will reconcile the path and all involved resources each 5m.
Keep in mind that this does not include HelmReleases resources output. (This is really hard to understand at the begining and I personally wonderd a lot why things dont get reconciled after reconsiling the kustomization level) For further reading and configuration for flux helm drift detection and correction check the documentation: https://fluxcd.io/flux/components/helm/helmreleases/#drift-detection
好吧，我想我在这里找到了答案 https://fluxcd.io/docs/docs/flux-e2e /。
从本质上讲，Kustomize控制器是唯一对群集应用更改的负责人，包括来自源控制器的新提交。因此，他们完成了2个独立任务。
Ok, I think I have found the answer here https://fluxcd.io/docs/flux-e2e/.
Essentially the Kustomize controller is the only responsible to apply changes to the cluster including the new commits coming from the Source Controller. Hence they fulfill 2 independent tasks.