欢迎光临,若觉得本博客的内容对您有帮助,请多点击边栏的Google广告,并提供意见及建议,谢谢!
Jul 23
    不为什么,就为了方便搜索,特把红帽EL 5、EL6、EL7、EL8 的各版本整理一下,共享出来。( EL8 和 EL 8.1 上传中)

正式发布 7.7 :
RedHat Enterprise Server 7.7 for x86_64:
rhel-server-7.7-x86_64-dvd.iso
SHA-256 Checksum:
88b42e934c24af65e78e09f0993e4dded128d74ec0af30b89b3cdc02ec48f028
百度云(密码:6jfz)

RedHat Enterprise Server 7.7 Boot for x86_64:
rhel-server-7.7-x86_64-boot.iso
SHA-256 Checksum:
2d4fac3cdf416975d8335933bee3c88729bfd3d0537da427a36a1db60a4d955e
百度云(密码:iy2b)

Tags: ,
Jan 17
好久没有更新了,遇到个问题,简单记录一下吧。

创建 k3s 时,默认 CA 证书有效期 10 年,Client 证书 1 年。在 Client 证书到期前,可以通过重启 k3s 服务来自动延期(不影响运行中 Pod)。但如果是 CA 证书到期,那就麻烦多了,官方的轮换证书的方式相当的复杂。

所以,网上才有了通过自定义 100 年时效的 CA 证书,以及修改系统时间,生成更长 Client 证书的方式。

参考:
K3s生成100年CA证书
K3s生成100年非CA证书

这方式不用修改 k3s 源码,可以通过脚本来处理,但调整系统时间可能会引发其他的问题,而且步骤也比较多。

既然证书是 k3s 生成的,那么应该从 k3s 代码中会有这部分的处理逻辑。经过分析,其实 k3s 是引用 dynamiclistener 这个库来生成证书的。

查看 dynamiclistener 的说明,其原来就有提供一个 CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS 来控制生成 Client 证书的有效期时间。但 k3s 的 install.sh 脚本中没有引用(首次启动 k3s 服务时)。

沿用类似的方法,对 dynamiclistener 做了简单的修改,增加一个环境变量 CATTLE_NEW_SIGNED_CA_EXPIRATION_YEARS ,可以定义 CA 证书的有效期,单位是年,默认 100 年。
具体 commit 见这里,tag 对应 v0.3.6-ske.3 。

然后,可以修改 k3s 项目的 go.mod ,替换为修改过的 dynamiclistener。

replace github.com/rancher/dynamiclistener => github.com/qkboy/dynamiclistener v0.3.6-ske.3
require github.com/rancher/dynamiclistener v0.0.0-00010101000000-000000000000


保存后,手动运行一下 go mod tidy 生成新的 go.sum ,重新编译 k3s 即可。
# SKIP_VALIDATE=true make


从源码编译 k3s 也没什么复杂的,只要当前环境装了 docker ,可以科学上网,直接运行就能搞掂。

最后一步,改改 instal.sh ,让在首次启动 k3s 时可以读到新增的两个环境变量:
# --- capture current env and create file containing k3s_ variables ---
create_env_file() {
    info "env: Creating environment file ${FILE_K3S_ENV}"
    $SUDO touch ${FILE_K3S_ENV}
    $SUDO chmod 0600 ${FILE_K3S_ENV}
    sh -c export | while read x v; do echo $v; done | grep -E '^(K3S|CONTAINERD)_' | $SUDO tee ${FILE_K3S_ENV} >/dev/null
    sh -c export | while read x v; do echo $v; done | grep -Ei '^(NO|HTTP|HTTPS)_PROXY' | $SUDO tee -a ${FILE_K3S_ENV} >/dev/null
    sh -c export | while read x v; do echo $v; done | grep -E '^(CATTLE_NEW_SIGNED_CA_EXPIRATION_YEARS|CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS)' | $SUDO tee -a ${FILE_K3S_ENV} >/dev/null
}


用修改后的 install.sh 运行安装 k3s:
# INSTALL_K3S_SKIP_DOWNLOAD=true CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=3650 CATTLE_NEW_SIGNED_CA_EXPIRATION_YEARS=50 ./install.sh


结果:
root@env2-node01:~# for i in `ls /var/lib/rancher/k3s/server/tls/*.crt`; do echo $i; openssl x509 -enddate -noout -in $i; done
/var/lib/rancher/k3s/server/tls/client-admin.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt
notAfter=Jan 13 07:46:06 2034 GMT <-- 客户端 10年
/var/lib/rancher/k3s/server/tls/client-ca.crt
notAfter=Jan  3 07:46:06 2074 GMT <-- 根 CA 50 年
/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt
notAfter=Jan  3 07:46:06 2074 GMT
/var/lib/rancher/k3s/server/tls/client-controller.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/client-k3s-cloud-controller.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/client-k3s-controller.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/client-kube-proxy.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/client-scheduler.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/client-supervisor.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/request-header-ca.crt
notAfter=Jan  3 07:46:06 2074 GMT
/var/lib/rancher/k3s/server/tls/server-ca.crt
notAfter=Jan  3 07:46:06 2074 GMT
/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt
notAfter=Jan  3 07:46:06 2074 GMT
/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt
notAfter=Jan 13 07:46:06 2034 GMT
root@env2-node01:~# for i in `ls /var/lib/rancher/k3s/server/tls/etcd/*.crt`; do echo $i; openssl x509 -enddate -noout -in $i; done
/var/lib/rancher/k3s/server/tls/etcd/client.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
notAfter=Jan  3 07:46:06 2074 GMT
/var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
notAfter=Jan 13 07:46:06 2034 GMT
/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
notAfter=Jan  3 07:46:06 2074 GMT
/var/lib/rancher/k3s/server/tls/etcd/server-client.crt
notAfter=Jan 13 07:46:06 2034 GMT


结束语,如果你觉得上面修改比较复杂。可以使用我修改过的两个 k3s 版本:
v1.24.17+k3s1
v1.29.0+k3s1

下载对应的分支后,直接编译即可。
相关的修改已经提了 PR(#90),等待回复。
有空我再把编译好的二进制文件放上来吧。
Tags: ,
Mar 30
    生产环境发现不定时 Java 应用出现 coredump 故障,测试环境不定时出现写入 /cgroup/memory 报  no space left on device 的故障,导致整个 kubernetes node 节点无法使用。设置会随着堆积的 cgroup 越来越多,docker ps 执行异常,直到把内存吃光,机器挂死。
    典型报错:
引用
kubelet.ns-k8s-node001.root.log.ERROR.20180214-113740.15702:1593018:E0320 04:59:09.572336 15702 remote_runtime.go:92] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to start sa
ndbox container for pod "osp-xxx-com-ljqm19-54bf7678b8-bvz9s": Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration
for process caused \"mkdir /sys/fs/cgroup/memory/kubepods/burstable/podf1bd9e87-1ef2-11e8-afd3-fa163ecf2dce/8710c146b3c8b52f5da62e222273703b1e3d54a6a6270a0ea7ce1b194f1b5053: no space left on device\""

或者
引用
Mar 26 18:36:59 ns-k8s-node-s0054 kernel: SLUB: Unable to allocate memory on node -1 (gfp=0x8020)
Mar 26 18:36:59 ns-k8s-noah-node001 kernel: cache: ip6_dst_cache(1995:6b6bc0c9f30123084a409d89a300b017d26ee5e2c3ac8a02c295c378f3dbfa5f), object size: 448, buffer size: 448, default order: 2, min order: 0

    该问题发生前后,进行过 kubernetes 1.6 到 1.9 的升级工作。怀疑问题与 kubernetes 、内核有关。
Mar 16
    用 python subprocess 捕获命令行输出结果失去响应,怀疑是 pipe size 太小,尝试修改。
    但报错:
# ulimit -p 16
-bash: ulimit: pipe size: cannot modify limit: Invalid argument
Tags:
Nov 13
1.问题
因误操作,把磁盘中部分的文件删除了,需要进行恢复。
※ 注意:
在进行恢复前,不要对需要恢复的分区进行写入的操作。
如果分区在单独的磁盘上,应该把该磁盘卸载后,进行修复。(非 mount 状态)
如果分区与根分区在同一个磁盘上,那么,可以把分区挂载为 ro 只读状态;


mount -o remount,ro /dev/sdX1

如果需要修复的就是根分区所在的分区,那么,只能把机器关闭后,把磁盘挂载到其他的机器上进行修复。
◎ 修复的原理:
通过遍历文件系统的 journal ,找到对应的 inode 位置,然后组成正常的文件。
所以,若使用 mkfs.ext4 等格式化的磁盘,superblock 全部被刷写,则是无法修复的。
Tags: ,
Jun 7
    在Windows 下调试 Python 还是挺麻烦的。通过PyCharm 来安装个MySQL-python 的库都搞了大半天。分别尝试 1.2.3、1.2.4 和 1.2.5 都有不同的错误。+_+
    最后确定还是在 1.2.5 版本下来解决,需要解决的问题就是这个:
“Cannot open include file: 'config-win.h': No such file or directory” while installing mysql-python

上面是在 1.2.4 版本上的,后来在 1.2.5 上面应该是解决的。但实际上,1.2.5 在Windows 64 位环境下还是有问题的,原因见后面的说明。
Tags: ,
Jun 5
    通过修改nova 的源码,在nova client 和 nova server 支持 migrate 离线迁移指定目标主机。
   (仅适用于RDO icehouse openstack-nova-2014.1.3-3 版本更新)
※ 注意:在2015-06-10 前提供的patch 有Bug,打入patch 后,执行resize 会报“NoValidHost: No valid host was found.”。原因是 compute/api.py 中 resize() 方法参数顺序的问题,下面的 patch 已经修改。
Tags: ,
May 7
在配置br-ex 桥接到eth0 网卡后,重启neutron-openvswitch-agent 服务后,一直提示报错,无法创建patch-int 和 patch-tun 网卡(极少时候是可以的)。
这导致openvswitch 在不断的重启,而对外的网络(与RabbitMQ 连接)也在不断的重启中。

日志:
引用
2015-05-06 23:40:43.299 18254 ERROR neutron.agent.linux.ovs_lib [req-9ec5d95e-3626-4494-b043-35d5211747d8 None] Unable to execute ['ovs-vsctl', '--timeout=10', 'add-port', 'br-int', 'patch-tun', '--', 'set', 'Interface', 'patch-tun', 'type=patch', 'options:peer=patch-int']. Exception:
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-vsctl', '--timeout=10', 'add-port', 'br-int', 'patch-tun', '--', 'set', 'Interface', 'patch-tun', 'type=patch', 'options:peer=patch-int']
Exit code: 242
Stdout: ''
Stderr: '2015-05-06T15:40:43Z|00002|fatal_signal|WARN|terminating with signal 14 (Alarm clock)\n'
2015-05-06 23:40:45.936 18254 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server on 192.168.209.137:5672 is unreachable: [Errno 113] EHOSTUNREACH. Trying again in 9 seconds.
2015-05-06 23:40:53.530 18254 ERROR neutron.agent.linux.utils [req-9ec5d95e-3626-4494-b043-35d5211747d8 None]
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-vsctl', '--timeout=10', 'add-port', 'br-tun', 'patch-int', '--', 'set', 'Interface', 'patch-int', 'type=patch', 'options:peer=patch-tun']
Exit code: 242
Stdout: ''
Stderr: '2015-05-06T15:40:53Z|00002|fatal_signal|WARN|terminating with signal 14 (Alarm clock)\n'2015-05-06 23:40:53.530 18254 ERROR neutron.agent.linux.ovs_lib [req-9ec5d95e-3626-4494-b043-35d5211747d8 None] Unable to execute ['ovs-vsctl', '--timeout=10', 'add-port', 'br-tun', 'patch-int', '--', 'set', 'Interface', 'patch-int', 'type=patch', 'options:peer=patch-tun']. Exception:
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-vsctl', '--timeout=10', 'add-port', 'br-tun', 'patch-int', '--', 'set', 'Interface', 'patch-int', 'type=patch', 'options:peer=patch-tun']
Exit code: 242
Stdout: ''
Stderr: '2015-05-06T15:40:53Z|00002|fatal_signal|WARN|terminating with signal 14 (Alarm clock)\n'
2015-05-06 23:40:53.638 18254 ERROR neutron.plugins.openvswitch.agent.ovs_neutron_agent [req-9ec5d95e-3626-4494-b043-35d5211747d8 None] Failed to create OVS patch port. Cannot have tunneling enabled on this agent, since this version of OVS does not support tunnels or patch ports. Agent terminated!2015-05-06 23:48:13.179 18701 INFO neutron.common.config [-] Logging enabled!
2015-05-06 23:48:13.728 18701 ERROR neutron.agent.linux.utils [-]
May 5
采用corosync 构成Pacemaker 集群。但发现启动corosync 服务后,不会自动启动pacemaker 服务。
经确认,在CentOS 7 的corosync 2.3.3 下,pacemaker 默认是disable 的,需要自行激活。

启动corosync 服务后,发现两个节点无法构成集群,没有Nodes:
引用
[root@gz-controller-209100 ~]# crm status      
Last updated: Mon May  4 14:43:13 2015
Last change: Mon May  4 14:26:45 2015
Current DC: NONE
0 Nodes configured
0 Resources configured
Tags:
Apr 16
    执行 RDO juno openstack-packstack-dev1462 版本部署的时候,执行mongodb 部署失败,报如下的错误:

引用
[root@controller01 ~]# packstack --answer-file=./packstack-answers-20150415-110139.txt  
192.168.209.137_mongodb.pp:                       [ ERROR ]          
Applying Puppet manifests                         [ ERROR ]

ERROR : Error appeared during Puppet run: 192.168.209.137_mongodb.pp
Error: Unable to connect to mongodb server! (192.168.209.137:27017)
You will find full trace in log /var/tmp/packstack/20150415-161743-hbPMV4/manifests/192.168.209.137_mongodb.pp.log

实际错误为访问mongo 服务无法连接:
引用
[root@controller01 ~]# cat /var/tmp/packstack/20150415-161743-hbPMV4/manifests/192.168.209.137_mongodb.pp.log
......
Notice: Failed to connect to mongodb within timeout window of 240 seconds; giving up.
Error: Unable to connect to mongodb server! (192.168.209.137:27017)
Error: /Stage[main]/Mongodb::Server::Service/Mongodb_conn_validator[mongodb]/ensure: change from absent to present failed: Unable to connect to mongodb server! (192.168.209.137:27017)
Notice: /Stage[main]/Mongodb::Server/Anchor[mongodb::server::end]: Dependency Mongodb_conn_validator[mongodb] has failures: true
Warning: /Stage[main]/Mongodb::Server/Anchor[mongodb::server::end]: Skipping because of failed dependencies
Feb 4
    解决在节点和实例VM 较多的情况下,创建实例报错:
引用
Virtual Interface creation failed

对应Neutron OpenvSwitch Agent 的错误:
引用
Timeout while waiting on RPC response


经查询相关资料,在Juno 之前的版本,RPC 存在随节点增加,以指数方式增长的问题。
此外,还有使用iptables 完成security_group  设置需时较长的问题。

创建实例时,没创建一个Port,此时,因为系统中某个安全组有成员变化,所以需要通知到各个节点,传递这样一个信息:一些安全组中的成员有变化,如果你有对这些安全组的引用,请更新对应的iptables规则。对于linux bridge和ovs来说,需要由neutron l2 agent处理更新请求。

这两项结合起来,导致在宿主机节点和VM 较多的情况下,security_group 每个返回时间较长,port 创建rpc timeout:
引用
Timeout: Timeout while waiting on RPC response - topic: "q-plugin", RPC method: "security_group_rules_for_devices" info: ""

最终Nova 在等待Neutron 创建Port 超时,就报Virtual Interface creation failed 错误。
Tags:
Dec 24
    以前写得一份关于Neutron VLAN 和GRE(VXLAN )的PPT,基于OpenStack Havana 或 Icehouse 版本的。在Juno 版本中,Provider VLAN 没什么改变,但VXLAN 和GRE 通过L3 Gateway 是改变比较大的。
    文档中内容是参考一些国外的资料和实践后整理的,仅供参考!
下载文件
这个文件只能在登入之后下载。请先 注册登入


若有疑问,请发:emos#linuxfly.org 沟通。
Tags:
分页: 1/51 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]