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
https://cloudinit.readthedocs.io/en/latest/topics/modules.htm
https://cloudinit.readthedocs.io/en/latest/topics/examples.html
安装工具:
apt-get install cloud-init
使用cloud-localds命令生成一个seed.img , 然后在virt-install qcow2 image 的时候同时指定这个seed.img
即 把初始化镜像时的自定义修改放到seed.img中, 然后将它作为一个参数传给kvm 。
cloud-localds seed.img user-data meta-data
这个命令是指user-data meta-data 中的配置加载到seed.img ,并生成seed.img 。 所以首先我们要编辑user-data meta-data 。格式与yaml相同。用法参见https://cloudinit.readthedocs.io/en/latest/topics/examples.html
注意,write file 是生成新文件,会覆盖。如要修改已有文件的个别部分,应该修改后的全文贴入对应部分
生成seed.img 之后,virt-install 时加上--disk path=/vob/cloud-init/seed.img,bus=virtio,format=raw
qemu-img resize xxxx.qcow2 +30G virt-install -d --connect qemu:///system --name casa-mobile-a -r 61440 --vcpus 4 --cpu host \ --disk path=/vob/cloud-init/xxxxxxx.qcow2,format=qcow2,bus=virtio --import \ --disk path=/vob/cloud-init/seed.img,bus=virtio,format=raw \ --autostart --noautoconsole
user-data 的一个示例,必须是以#cloud-config 开头
还可用于修改root 密码之类的变更,用passwd 。
写
基于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
ubuntu ISO 安装镜像的定制
1. 基本的系统镜像需要哪些组成部分
2.引导部分
3.软件预装设置
https://help.ubuntu.com/16.04/installation-guide/amd64/apb.html
https://help.ubuntu.com/18.04/installation-guide/amd64/index.html
4.preseed
5.isolinux
6.grub.cfg
7. ubuntu 18
支持的架构有4:AMD64, ARM, POWER8, LinuxONE and z Systems
ubuntu 10 及以前, 桌面版和服务器版的内核版本是有作区分。这以后,便合并为一个单独的通用内核版本,以降低维护成本。
Ubuntu 18.04支持六种主要的架构和每一种架构的几种变体,称为“口味”。另一个架构(IBM/Motorola PowerPC)有一个非官方的端口。支持AMD64和Intel 64处理器。
Debian
Debian是一个全志愿组织,致力于开发自由软件和促进自由软件社区的理想。Debian项目开始于1993年,当时Ian Murdock向软件开发人员发出了一个开放的邀请,邀请他们为一个基于相对较新的Linux内核的完整和一致的软件发行版做出贡献。最初由自由软件基金会(Free Software Foundation)资助并受GNU哲学影响的这一小群热心的爱好者,经过多年的发展,已经成长为一个大约有1026名Debian开发人员的组织。
universe 组件?
For users that want access to every known package, Ubuntu provides a "universe" component (set of packages) where users of Ubuntu systems install the latest version of any package that is not in the supported set. Most of the packages in Ubuntu universe are also in Debian, although there are other sources for universe to
背景
1. node 读取label 时只认表达式结果,不认变量
2. pipeline 中 node('label'){} 也同样无法取参数值
mark 解决等解决
1. 设置接收node label 的参数 (有问题,不能匹配变量,只能接收常量正则匹配)
2. 从node插件源码入手,找到label 的结构 和 传输时的类型转换 -- ing
3. 检索是否有对应的已开发私人插件
临时方案:
4. 再添加一个中间层 的job , 在第一次判断使用哪个node , 再根据结果去到中间层的job , 中间层的几个job ,jobname 与 node label 设置为对应。
-------------更新于2020.1.4 已经有 node 参数插件了。在插件管理中搜索node 或agent 或label
设置的位置 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
前面在 “expect:scp/ftp 自动化 ” 这一篇中提到:
interact:执行完毕后保持交互状态,并等待手工输入的操作了。
由于ftp 输入密码时敲错时不能使用ctrl+ backspace 进行回退,于是写了一个脚本用于自动操作登录部分,并在脚本执行结束时,将操作交互权交回给控制台,继续手工执行ftp 命令
loginftp.sh ${yuser} ${ypassword}
#!/usr/bin/expect set timeout 7200 set FTP "ftp>" spawn ftp ftp.xxxx.com expect { "):" { send "${yuser}\n" expect "*assword:" {send "${ypassword}\n"} } "*couldn't execute*no such file*" { print "ftp not install" } } interact