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能够看到新映像并相应地更新集群。
可以禁用此功能,并将图像锁定到特定的版本。
对于跨环境和集群的配置自定义,Flux提供了对Kustomize和Helm的内置支持。
对于高级部署模式,如Canary版本、A/B测试和蓝/绿部署,Flux可以和Flagger一起使用。
Requirements and limitations
flagger
https://github.com/weaveworks/flagger
主要是推进
Flagger是Kubernetes公司的运营商,该公司使用Istio、Linkerd、App Mesh、NGINX、等高线或Gloo路由来自动提升canary部署,并使用Prometheus指标进行canary分析。canary分析可以通过webhook进行扩展,以运行验收测试、负载测试或任何其他自定义验证。
https://docs.flagger.app/usage/how-it-works
flagger 可以通过配置一个名为canary的自定义资源,将Kubernetes工作负载的发布过程自动化。
A canary resource can target a Kubernetes Deployment or DaemonSet.
Kubernetes Deployment example:
Based on the above configuration, Flagger generates the following Kubernetes objects:
deployment/<targetRef.name>-primary
hpa/<autoscalerRef.name>-primary
Flagger will detect changes to the target deployment (including secrets and configmaps) and will perform a canary analysis before promoting the new version as primary.
If the target deployment uses secrets and/or configmaps, Flagger will create a copy of each object using the -primary
prefix and will reference these objects in the primary deployment、
Note that the target deployment must have a single label selector in th
https://github.com/tektoncd/pipeline
The Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines.
Tekton管道项目为声明CI/ cd风格的管道提供了k8风格的资源。
kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
curl -LO https://github.com/tektoncd/cli/releases/download/v0.7.1/tkn_0.7.1_Linux_x86_64.tar.gz
# Change destination directory as needed
tar xvzf tkn_0.7.1_Linux_x86_64.tar.gz -C ~/bin
kubectl apply --filename https://github.com/tektoncd/dashboard/releases/download/v0.5.1/tekton-dashboard-release.yaml
默认镜像源安装时的问题解决:
其中:https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
https://github.com/tektoncd/dashboard/releases/download/v0.5.1/tekton-dashboard-release.yaml
两个yaml 中创建资源时,pull 镜像用的镜像库是国外的,gcr.io 需要替换成国内的镜像源:gcr.azk8s.cn
如果使用原来的gcr.io , 资源创建成功后在启动的过程中,pod状态一直是 imagepullbackoff , 查看pod 内部,是无法pull 镜像所致。
get pods --na
基于ubuntu 18.4 已经搭建了一套简单的k8s 集群
kubectl,docker 服务能正常停启
基本环境
lcf@vm1:~/k8s$ kubectl get nodes NAME STATUS ROLES AGE VERSION vm1 Ready master 5d v1.12.5 vm2 Ready <none> 5d v1.12.5
master:vm1
node1:vm2
查看本集群中的node
tips : 查看各种对象列表: kubectl get nodes/svc/pods, 默认-n 是 namespace=default , 如果查找不到,可-n 更详细的namespace
创建一个部署和服务
kubectl create deployment nginx --image=nginx kubectl create service nodeport nginx --tcp 80:80
创建成功后可查看执行中的pod
lcf@vm1:~/Tekton$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-55bd7c9fd-94tj5 1/1 Running 0 4h33m
注: 使用--image=nginx 默认是从docker mirror 中pull 镜像,会默认从国外镜像pull , 如果pull 失败时,看到的pod 的状态为:ImagePullBackOff , 当status 不是running 时,需要进一步查看该pod 的执行情况,可以在describe 中看到实际failed 的原因
kubectl describe pod nginx-55bd7c9fd-94tj5
扩展: 如果是连接超时pull失败,可改docker 镜像为阿里镜像,在/etc/docker/daemon.json中加入,注意如果原来已有内容,新增记录时,需以逗号隔开上下文。否则daemon reload后 会因配置文件语法错误无法restart docker
/etc/docker/daemon.json