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
1. Node status is NotReady 之一
Container Runtime Version: docker://Unknown
查看node 状态,发现是节点的状态是 Notready
kubectl get nodes NAME STATUS ROLES AGE VERSION vm1 Ready master 13d v1.12.5 vm2 NotReady <none> 13d v1.12.5
查看node 状态,发现是节点上的docker 版本有问题
kubectl describe node vm2 System Info: ...... Container Runtime Version: docker://Unknown
登录node , 发现docker 被删除了,重装node 的docker , 重启 docker
systemctl restart docker systemctl status docker
再回到master ,查看node 的状态,变成 ready 。 System Info 下 的 container runtime....
$ kubectl get nodes NAME STATUS ROLES AGE VERSION vm1 Ready master 13d v1.12.5 vm2 Ready <none> 13d v1.12.5 $ kubectl describe node vm2 Name: vm2 ....... System Info: ..... Container Runtime Version: docker://18.6.3
2. Node status is NotReady 之二
runtime network not ready: NetworkReady=false
查看node 状态,发现是节点的状态是 Notready
Conditions: Type Status LastHeartbeatTime LastTransitionTime
https://rancher.com/docs/rancher/v2.x/en/
https://rancher.com/docs/rancher/v2.x/en/overview/architecture-recommendations/
https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
当启动后无法访问查看容器log,发现以下error 时,加一个--privileged
Error: rancher can not be ran without --privileged flag outside kubernetes.
docker container ls docker container logs 3aa2569cda85 docker container stop 3aa2569cda85 docker run --privileged -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher docker container logs c554478d2aaa554565d29bf2ef6a32b45f920592b719057f7e8722bf6b6d559e
第一次打开:https://172.0.11.153/
设置管理员密码,url 之后进入网页界面:
通过Rancher 创建一个集群:
From the Clusters page, click Add Cluster.
Choose Custom.
Enter a Cluster Name.
Skip Member Roles and Cluster Options. We’ll tell you about them later.
Click Next.
From Node Role, select all the roles: etcd, Control, and Worker.
Optional: Rancher auto-det
基于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
设置的位置 Gitlab project 的settings
repository -> Push Rules -> Commit message:
示例:
^(I|i)ssue \d{4,6} \/*
^(Issue|issue|bug|Bug) #\d{1,7} \/*
示例含义:
^(I|i)ssue 开头
\d{4,6} 表示4-6位数字
\/* 表示任意内容
即以上示例匹配以下格式:
[I|i]ssue空格4-6位数字空格任意内容
如
Issue 1234 gfdg dgdfgdfgdff
Issue 124455 ggfdgd gd
其他匹配细节可参考:
https://github.com/google/re2/wiki/Syntax
不符合commit message匹配规则的commit 无法被push , 此时gitlab 会给出匹配提示,以实际项目中设置的格式为准,比如:
remote: GitLab: Commit message does not follow the pattern '^(I|i)ssue \d{4,6} \/*'
以下介绍如何处理修正不匹配规则的commit message。
三种情况
- [1] gitlab web 页面直接提交时(即直接在远程push 一条commit)
- [2] 提交一个merge request 时,merge request 本身产生一条合并的commit
- [3] 本地仓库的commit 推送到远程仓库时
以上情况,在push时,会对commit message , 对merge reuqest 的title 进行上方设置规则的匹配校验,检验不成功则push 不成功。
本地仓库的commit message 不符合匹配规则,导致在push这些不合规的commit到remote repo时报错:
--push failed: r
Gitlab 的release 功能不止将源代码快照(tag) 与版本对应记录,其他版本信息,如目标产物,修改说明,相关文档链接等,都可以在一个release 里跟踪。
目前在GitLab 11.7 以上版本已经包含了release 的功能,但是现在(2019-11-1)为止,Release 的入口只支持API接入。
更新信息:
Gitlab 的 release 现在已支持在界面上直接以 “new release” 进入编辑。
以下说明皆为使用 api 新建release 的方法:(此句更新于2021.5.6)
一个release 可以包含两大块资源: 代码和链接。后续会支持更多资源的关联,包含容器等
Release assets
You can currently add the following types of assets to each Release:
Source code: state of the repo at the time of the Release
Links: to content such as built binaries or documentation
GitLab will support more asset types in the future, including objects such as pre-built packages, compliance/security evidence, or container images.
Source code
实际是映射到 tag 对应的源码版本 ,tag 信息是需要在创建release 时提供。
link
目前支持 http, https, ftp 链接。一个release 里可以有多个link , 每个link 用字典管理,分别有自己的 id tag_name n
User setting and access
User Settings
登录gitlab.XX-company.com 之后在页面右上角头像处点击∨展开菜单,进入setting。
可以设置相关用户信息,常用的包括profile(基本配置),Account(帐户),Preferences(偏好设置),密码,SSH Keys,Notifications(邮件通知范围),Active Session(有效的连接)
Profile
可以在profile 里修改头像,邮箱,状态,及各平台关联帐号
Account
可以在account里修改用户名,用户名标识着与用户id 唯一关联的名称空间。一般不建议修改,如果修改,可能引起一些未知的影响,如必要修改,请严格按照修改页面的learn more 到“changing-your-username”根据提示做足步骤。
https://gitlab.XX-company.com/help/user/profile/index#changing-your-username
Notifications
全局通知设置:先在全局设置里可以设置通知的级别,然后在然后组/项目里分别设置为不同级别。默认为全局设置,展开可选其他。
Password
密码页面,修改密码后,会收到一个邮件,点击链接可以使用新密码登录(稍有延迟)
SSH Keys
SSH密钥允许您在计算机和GitLab之间建立安全连接,使用较多的情况是,当我们使用SSH 来 Clone 一个项目时,需要先在gitlab里配置好ssh keys。
一般我们在项目主页里展开clone 选项时,有两种方式,一种是clone with SSH,一种是Clone with HTTPS
当我们使用clone with SSH 时,我们需要先配置好ssh keys。
https://gitlab.XX-company.com/help/ssh/README#generating-a-new-ssh-key-pair
步骤是,先在一台linux 设备上生成一个密钥对,公钥拷到gitlab设置页面里,私钥放到需要clone 项目的设置上的默认ssh 配置路径。然后就可以直接使用这样的链接进行clone
Git clone git@gitlab.XX-company.com:vmc/products.git
另有直接使用用户/密码
gitlab 的CI/CD ,即持续集成,持续构建并部署测试的过程,实质上是
1. 将持续集成的过程阶段(编译构建/打包/部署/测试)写在gitlab.yml中
2. 并将准备执行gitlab.yml脚本内容的服务器配置为gitlab服务器的一个runner。
3. 当gitlab 库中的提交时,便会自动触发一次在runner 上的持续集成过程。
注意: gitlab.yml 是一个yaml文件,对缩进非常严格,需要始终使用空格,而非制表符。
https://gitlab.${company}.com/help/ci/yaml/README.md
具体格式及构成可参考gitlab help/ci/yaml/README.md 文件
在库中的根目录下,创建一个名为.gitlab.yml的文件
1. 通过 CI-CD --> jobs --> CI Init 直接编辑初始化文件
2. 在库中的根目录下,创建一个名为.gitlab.yml的文件
在库的设置中Setting--> CI/CD --> runners 展开
使用共享 runner 去运行 : Shared Runners
使用指定 runner 去运行 : Specific Runners //如从新配置一台服务器作为gitlab.yml 中脚本运行的runner,请按如下配置runner执行
安装GitLab Runner
# Linux x86-64
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
赋执行权限
sudo chmod +x /usr/local/bin/gitlab-runner
创建 GitLab CI 用户: