机器人 救救瓜
Toggle navigation
Home
SCM-tool
Linux
Jenkins
SVN
other
About Me
Archives
Tags
FluxCD
? k8s ?
2020-04-14 10:54:42
916
0
0
gua_l
? k8s ?
</br> fluxCD https://fluxcd.io/ The GitOps operator for Kubernetes ---------- 填补了构建和监控之间的空白 ,持续监控git库中的yaml和 registry的镜像 It fills the automation void that exists between building and monitoring. Automated git->cluster synchronisation ---------- ### 配置存储库的同步 Flux的主要特性是版本控制存储库和集群之间的自动同步。如果对存储库进行任何更改，这些更改将自动部署到集群中。 所有配置都存储在版本控制中，并且本质上是最新的。在任何时候，任何人都可以完全以完全相同的配置状态重新创建集群。 对集群的更改对所有相关方都是立即可见的。 在事后分析期间，git日志为审计提供了完美的历史记录。 端到端，代码到生产管道不仅变得可能，而且容易。 ---------- ### 配置容器的自动部署 另一个特性是容器的自动部署。它将持续监控一系列容器注册中心，并在适用的地方部署新版本。 这对于使存储库和集群保持最新非常有用。它允许单独的团队拥有自己的部署管道，因为Flux能够看到新映像并相应地更新集群。 可以禁用此功能，并将图像锁定到特定的版本。 ---------- ### 集成其他配置工具，内置支持Kustomize和Helm 对于跨环境和集群的配置自定义，Flux提供了对Kustomize和Helm的内置支持。 对于高级部署模式，如Canary版本、A/B测试和蓝/绿部署，Flux可以和Flagger一起使用。 ---------- ### 要求和局限性： Requirements and limitations 1. 目前一次只能处理一个库，技术限制，不会是永久问题 2. 会忽略 heml/chart ，文件夹包含Chart.yaml and values.yaml 就会被跳过。 3. 只能处理yaml 文件，会递归目录中的yaml 文件，不会解析文件夹结构意义 4. 由于Flux在集群中的一个容器中运行，所以它可能无法解析您或Kubernetes能够解析的所有主机名。特别是，它将无法在localhost上提供的私有图像注册表中获取图像的图像元数据 ---------- ### 常见问题与官网说明 https://docs.fluxcd.io/en/latest/faq/ ---------- flux实际上可以做到完全自动检测git仓库中yaml文件的变化以及registry中镜像的更新，进而自动部署。这与bash脚本有什么不同？ Flux中包含的功能数量保证了一个专用的应用程序/服务。相同的脚本很容易变得太大而无法维护和重用。 ---------- 它只在一个git存储库中工作吗? 目前，是的，它只能在一个包含Kubernetes清单的git仓库中工作。需要说明的是，您可以拥有任意数量的带有应用程序代码的git存储库——参见下面。这没有什么原则性的原因，这只是时间和精力有限的结果。如果您需要使用多个git repo支持，请在https://github.com/fluxcd/flux/issues/1164中进行评论。同时，对于某些用例，您可以运行多个Flux守护进程，并将它们指向不同的repos。如果您这样做，请考虑削减您为每个守护进程的服务帐户授予的RBAC权限。这个Flux (daemon)操作符项目可能用于管理多个守护进程。 https://github.com/justinbarrick/flux-operator ---------- 我必须把我的应用程序代码和配置放在同一个git repo？ 没有，但如果你想让他们在一起，他们可以。Flux不需要知道你的应用程序代码，因为它处理的是容器的图像(例如，，一旦应用程序代码已经构建完成)。 ---------- 我需要在我的git repo?中进行特殊的目录布局吗？ 不。Flux在目录结构上没有任何意义，它会下降到搜索YAMLs的子目录中。虽然kubectl处理JSON文件，但Flux将忽略JSON。它避免了看起来像舵轮图的目录。 如果您在repo中有YAML文件，而这些文件并不适用于Kubernetes，那么可以使用——git-path来约束Flux开始查找的位置。 ---------- Flux检查新图像的频率是多少? 在给定速率限制的情况下，Flux尽可能快地扫描图像注册中心的元数据;而且, 默认情况下，检查是否有自动工作负载需要每五分钟更新一次。 后一种默认值非常保守，所以您可以尝试降低它(它使用标记——automatic -interval设置)。 请不要增加速率限制数字(—注册号-rps和—注册号-burst)—如果您用请求发送垃圾邮件，可能会被图像注册中心列入黑名单。 ---------- Flux检查新git提交的频率是多少(我能让它同步得更快吗)? 简短的回答:每五分钟;是的。 有两个标志控制Flux与git同步集群的频率。他们是 ——git-poll-interval，它控制查找新提交的频率 ——sync-interval，它控制在没有新提交的情况下，将git中的内容应用到集群的频率。 它们都有5分钟的默认时间。当有新的提交时，它会在那时和那里运行同步，所以在实践中，同步比——同步间隔更频繁 如果您想对新的提交做出更快速的响应，那么—git-poll-interval的持续时间应该更短，这样它就会更频繁地进行检查。 缩短——sync-interval的持续时间用处不大，因为它只控制在没有新提交的情况下同步的频率。将其减少到一分钟以下可能会阻碍流量，因为同步可能需要几十秒，没有多少时间做其他操作 ---------- ### **官网的简单部署例子** ---------- > https://docs.fluxcd.io/en/latest/tutorials/get-started/ **安装fluxctl 1.19** wget https://github.com/fluxcd/flux/releases/download/1.19.0/fluxctl_linux_amd64 mv fluxctl_linux_amd64 fluxctl mv fluxctl /usr/bin/ **创建namespace: flux** kubectl create ns flux **部署 flux** 并指定需要同步配置的github库，库中含yaml文件，flux 会自动更新并部署。 注意，比较旧的fluxctl 版本是不含install 命令的，请下载最新的版本，1.19.0 是可用的。 fluxctl install \ --git-user=GuaKing \ --git-email=490667945@qq.com \ --git-url=git@github.com:GuaKing/test1 \ --namespace=flux | kubectl apply -f - 例子： https://github.com/GuaKing/test1 此库中放置了两个yaml , 一个deployment 一个service 可以fork 此repo 到自己名下。再进行修改。 实践的时候把官网的 --git-path 去掉了，简单例子的两个yaml 就放在git-repo 的根目录下，不限定指定子路径查找 --git-path=namespaces,workloads \ **等待flux 部署就绪**： kubectl -n flux rollout status deployment/flux **使用fluxctl 生成公钥** 把生成的公钥添加到github的个人帐号setting - ssh - key fluxctl identity --k8s-fwd-ns flux **同步github 的代码**： fluxctl sync --k8s-fwd-ns flux **等待pod 状态到running**: kubectl get pods -n flux --watch **查看github中的yaml, 查看对应的service** kubectl get svc # kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 12d nginx-service NodePort 10.104.46.227 <none> 80:30009/TCP 43m nginx-service 的Nodeport是30009 **查看集群有哪些node** root@vm1:~/k8s/flux/flux/deploy# kubectl get nodes NAME STATUS ROLES AGE VERSION vm1 Ready master 12d v1.17.3 vm2 Ready <none> 12d v1.17.3 **使用任意一个节点和节点端口进行访问** https://nodeip:30009 或命令行查看 -I, --head Show document info only curl -I vm2:30009 curl -I vm1:30009 可以看到nginx的版本是1.17.9 root@vm1:~/k8s/flux/flux/deploy# curl -I vm1:30009 HTTP/1.1 200 OK Server: nginx/1.17.9 Date: Tue, 14 Apr 2020 03:34:52 GMT Content-Type: text/html Content-Length: 612 Last-Modified: Tue, 03 Mar 2020 14:32:47 GMT Connection: keep-alive ETag: "5e5e6a8f-264" Accept-Ranges: bytes 此时，最初的部署已完成，下面是验证flux 自动同步更新并部署的情况： ### **修改配置库** 修改github中使用的代码库的代码，可查看nginx 的版本号有哪些---： https://hub.docker.com/_/nginx 将github的中部署的yaml中的nginx的image tag 改为官网中已有的其他release 版本号，然后提交 - name: nginx -image: nginx:1.17.9 +image: nginx:1.13.12 ### **查看同步** 默认的同步时间是5分钟，重新查看部署的nginx版本： curl -I vm1:30009 ### **或手动同步** fluxctl sync --k8s-fwd-ns flux 可以看到，提交到github 的修改，已经由flux自动同步到k8s中。 ---------- ## **使用github 之外的内部版本库** 由于上文提到的限制性的第4点，除了github之后，当我们使用企业私库或个人搭建的git 库时，需要一些对know_host 和 hostname 的修改。 > 由于Flux在集群中的一个容器中运行，所以它可能无法解析您或Kubernetes能够解析的所有主机名。特别是，它将无法在localhost上提供的私有图像注册表中获取图像的图像元数据 https://docs.fluxcd.io/en/latest/guides/use-private-git-host/ 将git-url等信息替换为私库，并使用上述方法部署flux。 删除flux namespace ,部署在其上的资源会删除 kubectl delete sn flux kubectl delete service/ kubectl delete deployment.app/ 然后重新将上述库fork 到gitlab , 使用gitlab 的相关帐号和git url 进行 fluxctl install. 到kubectl sync 这一步时，会显示无法同步代码，找不到hostname。 思路是进入到容器中去验证并解决问题，然后想办法把解决的操作在初始化pod 时加入。使这些修改永久化。无需人工在部署之后再介入。 查找flux 使用的pod kubectl get pods -n flux | grep flux 使用这个podname ,进入到它使用的容器，flux-7dd57d9b9d-dzc95 kubectl exec -n flux flux-7dd57d9b9d-dzc95 -ti -- env PS1="container$ " /bin/sh 在container$ 容器环境下，执行git clone git@XXXXXXXX 报can't resolve hostname , 需要加入gitlab 主机的host ip和域名的映射 vi /etc/hosts 172.25.2.42 gitlab.xxxx.com registry.gitlab.xxxxx.com 再执行clone ， 报known_hosts相关的错误 container$ git clone $GITREPO Cloning into <repository name>... No ECDSA host key is known for <GITHOST> and you have requested strict checking. Host key verification failed. fatal: Could not read from remote repository 需要在known_hotst 中加入主机key ssh-keyscan gitlab.xxxxxx.com >> ~/.ssh/known_hosts 再 clone , 成功 总结，是进行代码检出的容器的环境需要增加以下操作，才能解决这两个问题： 修改 ~/.ssh/known_hosts 修改 添加hosts ---------- 如何使两个修改在 pod 初始化时就能应用到容器中呢？ 对于known_hosts，使用configmap 对于hosts,使用 hostAliases 查看flux的源码，install 时创建的资源模板在如下目录： > https://github.com/fluxcd/flux/blob/master/cmd/fluxctl/install_cmd.go > https://github.com/fluxcd/flux/blob/master/pkg/install/install.go > https://github.com/fluxcd/flux/tree/master/pkg/install/templates  ---------- 我们使用kustomization及flux 项目的deploy 目录来自定义资源，将以上两点修改注入其中： https://github.com/fluxcd/flux/tree/master/deploy 查看deploy目录下的文件结构，比fluxctl install 的templates 多了两个yaml文件， 一个是flux-ns.yaml,即是对namespace的创建，即使用flux install 之前的create ns 一个是kustomization.yaml，其中内容是各个资源模板的list，当在kustomization.yaml所在的deploy目录执行``kubectl apply -k .`` 时，相当于将对kustomization.yaml所列的所有yaml 按所排顺序进行kubectl apply -f **.yaml </br>  https://github.com/fluxcd/flux/tree/master/deploy </br> ---------- clone flux 的项目代码： git clone https://github.com/fluxcd/flux ---------- </br> #### **添加一个configmap** cd flux/deploy ssh-keyscan gitlab.xxxxxx.com >> ~/.ssh/known_hosts cat ~/.ssh/known_hosts | grep gitlab.xxxxxx.com ## 将私库主机记录加到下方的yaml 中 cat << EOF >flux-configmap.yaml apiVersion: v1 data: known_hosts: gitlab.xxxxxx.com ssh-rsa AAAAB3NXXXXXXXXX0Y AAAAB3NXXXXXXXXX0Ys3E5QNKC3e7snuMioLD2v2iTT0Uw== kind: ConfigMap metadata: name: flux-ssh-config namespace: flux EOF vi kustomization.yaml 把flux-configmap.yaml 加到flux-ns.yaml 之后，flux-deployment.yaml 之前。 以下三步与上方创建configmap等效，但注意如果用下面的方法在命令行 create configmap 要先创建namespace,后面执行执行全部时就存在了，为了统一，全部使用yaml配置。 ssh-keyscan gitlab.xxxxxx.com >> ~/.ssh/known_hosts kubectl create ns flux kubectl create configmap flux-ssh-config --from-file=$HOME/.ssh/known_hosts -n flux 在flux-deployment.yaml 中使用flux-ssh-config flux-deployment.yaml 把模板中的ssh-config注释打开,注意缩进 - name: ssh-config configMap: name: flux-ssh-config - name: ssh-config mountPath: /root/.ssh ---------- </br> #### **添加一条host 到/etc/hosts** 在flux-deployment.yaml 中，找到deployment spec的template的spec下，添加hostAliases,将对应的host记录加进去。 这是pod初始化使用模板中的功能，往/ect/hosts 中追加一条记录。 hostAliases: - ip: "172.25.2.42 " hostnames: - "gitlab.xxxx.com" - "registry.gitlab.xxxxx.com"  ---------- </br> #### **将fluxctl install --git-url 等需要传参的git相关选项也在deploy 中先设置好** </br> 这两个fix 都增加到deploy 下的yaml 之后，我们如果执行kubectl apply -k . 就相当于不改参数执行fluxctl install ,所以执行前，把我们的git-url 信息也在deploy 中修改好。 + - --git-url= + - --git-branch= ---------- </br> 综上我们总共对这些文件作了修改： modified: flux-deployment.yaml modified: kustomization.yaml add: flux-configmap.yaml 作了以下修改： known_hosts hosts git-url 综上修改后，应用这些资源，相当于执行上文的fluxctl install, 但是预置了一些pod 的初始化修改。 cd deploy/ kubectl apply -k . 之后就是与前方一样的，设置公钥，同步，访问，修改，同步验证 kubectl -n flux rollout status deployment/flux fluxctl identity --k8s-fwd-ns flux 在gitlab的帐户setting中设置ssh key fluxctl sync --k8s-fwd-ns flux kubectl get svc curl -I vm1:<port> Flux 的 主打是监控并自动更新 git里的yaml 文件 及自动监控 registry 的更新。 ---------- **Flux CD 如何做自动更新镜像，更新哪些镜像** https://docs.fluxcd.io/en/latest/references/automated-image-update/ Flux periodically scans the pods running in your cluster and builds a list of all container images. Flux定期扫描集群中运行的pod，并构建一个所有容器映像的列表。 (**即所有通过flux 自动apply 的yaml 里的image**) Note: that Flux only works with immutable image tags (:latest is not supported). Every image tag must be unique, for this you can use the Git commit SHA or semver when tagging images. 注意:Flux只对不可变的图像标签有效(最新的不受支持)。每个图像标记必须是唯一的，为此，您可以在标记图像时使用Git提交SHA或semver。 开启： fluxcd.io/annotations:automated 关闭： fluxcd.io/automated: "false" 更新范围： ``` fluxcd.io/tag.<CONTAINER>: <TYPE>:<EXPRESSION>. fluxcd.io/tag.sidecar: regex:^stg.* fluxcd.io/tag.app: glob:dev-* fluxcd.io/tag.app："semver: >= 1.0.0-rc.0, <1.0.1" ``` ``` apiVersion: apps/v1 kind: Deployment metadata: annotations: fluxcd.io/automated: "true" fluxcd.io/tag.app: "semver: >= 1.0.0-rc.0, <1.0.1" spec: template: spec: containers: - name: app image: docker.io/org/my-app:1.0.0-rc.1 ``` 查看flux 收集到的更新列表： ``` root@vm1:~/k8s/flux/fluxcd# fluxctl list-workloads --k8s-fwd-ns flux WORKLOAD CONTAINER IMAGE RELEASE POLICY root@vm1:~/k8s/flux/fluxcd# fluxctl list-workloads --k8s-fwd-ns flux WORKLOAD CONTAINER IMAGE RELEASE POLICY ``` ---------- 打开nginx deployment 的自动更新镜像的开关 ``` root@vm1:~/k8s/tekton/tektontest/deployments# cat deploynginx.yaml| grep -E "true|image" fluxcd.io/automated: "true" image: nginx:1.14.2 ``` 5分钟之后查看扫描到的mages list ``` root@vm1:~/k8s/tekton/tektontest/deployments# fluxctl list-images --k8s-fwd-ns flux WORKLOAD CONTAINER IMAGE CREATED default:deployment/guatask-deployment mytask-app image data not available '-> (untagged) ? default:deployment/nginx-deployment nginx nginx '-> 1.18-alpine-perl 24 Apr 20 13:00 UTC 1.18.0-alpine-perl 24 Apr 20 13:00 UTC stable-alpine-perl 24 Apr 20 13:00 UTC 1.18-alpine 24 Apr 20 12:59 UTC 1.18.0-alpine 24 Apr 20 12:59 UTC stable-alpine 24 Apr 20 12:59 UTC 1.18-perl 24 Apr 20 12:59 UTC 1.18.0-perl 24 Apr 20 12:59 UTC stable-perl 24 Apr 20 12:59 UTC 1.18 24 Apr 20 12:59 UTC ``` list 里最新指向1.18-alpine-perl 这个tag 的镜像，查看实际deployment 里用到的镜像，已经更新为最新版本。 ``` root@vm1:~# kubectl describe deploy nginx-deployment | grep Image Image: nginx:1.18-alpine-perl ``` 把yaml 里的文件更新看看，最新的镜像标签已经被修改到git repo 里 push 到配置库里 ``` root@vm1:~/k8s/tekton/tektontest/deployments# cat deploynginx.yaml| grep -E "true|image" fluxcd.io/automated: "true" image: nginx:1.18-alpine-perl ``` 可以看到git commit history 里有一条flux操作的自动提交。  同步的最新的yaml 库版本标签，也自动更新到最新的commit 上 以上是当打开自动更新镜像的标签之后，flux 会对 配置的git repo 做的操作。 当deploy 的yaml 写得有问题时，会有一个不友好的报错，已经拿到最新的版本号3f65cbd，但是拉取yaml文件时却报超时，亲测网络畅通，查找diff 发现是 yaml 文件写得有问题，image 后成的标签应该紧跟着冒号，多了一个空格，导致内部apply 不成功，但是报错信息却显示超时。去掉空格后同步正常 ``` root@vm1:~/k8s/flux/flux/deploy# fluxctl sync --k8s-fwd-ns flux Synchronizing with ssh://git@gitlab.xxxxxx.com/xxxxxx/tektontest.git Revision of master to apply is 3f65cbd Waiting for 3f65cbd to be applied ... Error: timeout Run 'fluxctl sync --help' for usage. ```  ---------- 自动更新私人镜像注册库 的 调研： 可能是镜像库时间戳处理 或是私有库访问 https://docs.fluxcd.io/en/latest/references/blueprint/ > In order to access private registries, credentials may be required. https://docs.fluxcd.io/en/latest/references/fluxctl/ > Controlling image timestamps with labels > > Some image registries do not expose a reliable creation timestamp for > image tags, which could pose a problem for the automated roll-out of > images. > > To overcome this problem you can define one of the supported labels in > your Dockerfile. Flux will prioritize labels over the timestamp it > retrieves from the registry. > Supported label formats > > org.opencontainers.image.created date and time on which the image was built (string, date-time as defined by RFC 3339). > org.label-schema.build-date date and time on which the image was built (string, date-time as defined by RFC 3339).
Pre:
搭建DNS服务 dnsmasq
Next:
ConfigMap
0
likes
916
Weibo
Wechat
Tencent Weibo
QQ Zone
RenRen
Submit
Sign in
to leave a comment.
No Leanote account?
Sign up now.
0
comments
More...
Table of content
gua_l
No Leanote account? Sign up now.