线上用的k8s版本是1.6.7非常老，而且HA有问题，上个月研发想把里面的一些服务迁出来到一个新集群里，新集群的搭建是我负责的。上周开始陆陆续续的迁移过来了，但是同等limit下部分pod在测试环境上(测试环境和老环境部署是一样的,下文的老环境和测试环境可以理解为一样)启动非常快，在我搭建的新k8s环境上启动非常慢，研发他们应用都是java+springboot，这里不谈jvm无法识别cgroup，已经加选项识别到了还有那个随机熵的选项肯定也是加了的。因为之前一次有个用户反映他们本地虚机启动springboot应用20s，我们云上启动就三分钟，后面漠然大佬教我加java的启动参数输出lo...
线上的k8s环境普遍版本很低，今天同事心血来潮去一个新节点上去看了下发现根分区满了,清理了后发有一个pod没有创建出来。清理后把因为文件系统满了而down掉的k8s相关进程起来后发现kubelet的log一直报错cannot remove /var/lib/kubelet/xxxxconfig/key resource busy now 啥的。查看了下describe对应rc还没有任何Event
1234567891011121314151617181920212223242526272829303132333435363738$ kub...
前言这几天给线上搭建 k8s 集群，文件和 systemd 参数大多是从 kubeadm 的 staticPod 的 yml 里扣出来的，起初是除了 flanneld 全部是 systemd 管理二进制。脚本问题导致 kube-proxy 的 kubeocnfig 少执行了 use-context 所以显示的是匿名用户无法 list node 信息，kube-proxy 是在运行但是无法维持 svc 的网络，flanneld 因为是 pod 要 watch 节点是通过 kubernetes 这个 svc 走的连接导致不通，然后 pod 状态变成退出，而 kubelet 在不手动清理掉退出...
etcd 就不说了,奇数个副本,可以坏 (n-1)/2 个,但是不可能同时坏那么多,这里不讨论 etcd 单独不单独跑。推荐个文档 https://github.com/etcd-io/etcd/tree/master/Documentation/op-guide
管理组件先说说 k8s 组件, kubelet 和 kube-proxy 啥的肯定写 LB 或者 VIP:HA_port,如官方的图和 https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/ 里的，这里的文档内容...
本次采用二进制文件方式部署,本文过程写成了更详细更多可选方案的ansible部署方案 https://github.com/zhangguanzhang/Kubernetes-ansible和之前的步骤差不多都是和kubeadm步骤一样,不过这次所有kubelet全部走bootstrap不会像之前master上的kubelet生成证书,另外证书换成openssl生成
不建议使用secureCRT这个ssh软件复制本篇博客内容的命令,因为它的部分版本对包含多条命令的处理结果并不完美,可能很多命令不是预期结果
本文命令里有些是输出,不要乱粘贴输入(虽然也没影响)
本文命令全部是在k8s-m1...
记录下这几天搭建的过程jira和confluence是分别两台，数据库也是分开的,数据库是用mysql的rpm的repo添加后安装的,jira和confluence是docker跑的,把破解的jar加到镜像里然后改了下别人的Dockerfile本次安装的版本：
jira-software 8.0.0
confluence 6.14.1
Docker CE 18.06.02
OS CentOS 7.5.1804
系统基本设置
所有防火墙与SELinux 已关闭：123systemctl disable --now firewalld NetworkManagersetenforce...
详细的讲解下部署dashboard，比市面上更详细和更多场景的选择，本文dashboard的暴露不会用nodeport(不喜欢使用它)和apiserver的web proxy代理也就是/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/这种
讲下四种场景方式：
纯dashboard http和https不惨合外部证书
openssl 证书给dashboard当https
个人向域名使用https小绿锁
ingress tls 代理http[s]的dashboard以及最后讲解的如何定义带权...
每次挂nfs,iscsi，cifs改fstab都心惊胆颤，怕改错了开机hang在那影响业务。每次都是改之前去搜第四列列的所有选项值。写下今天趁线上挂了cifs的一台机器可能重启之前在我自己虚机上做了测试和一些问题搜到的见解虚机桥接网络，宿主机共享一个目录，折腾了半天autofs都没配置起来，而且网上普遍的samba的fstab为下面这样
1//10.0.23.85/test /mnt cifs username=zhangguanzhang@xxxxx.com,password=xxxxxxxxx,iocharset=utf8 0 0
但是我在宿主机把445端口屏蔽...
cloud-init的镜像模板制作模板制作记录下proxmox制作带有 cloud-init 的虚机模板过程因为刚开始制作虚机模板的硬盘是固定大小,后面通过克隆后调整硬盘大小就会自动 growpart ,需要安装 cloud-utils-growpart。好像只能往大的扩,我个人也倾向于最小 20G,所以这里我开的是20G硬盘的虚机另外查了下和实际试了下 cloud-utils-growpart 好像只支持 ext3 和 ext4 不支持 lvm 自动扩,其他的文件系统可以考虑试试 lvm 自己写个脚本去开机启动自动扩。这里我分区不带 swap,标准分区+ext4安装完后进系统里自行配制...
常规的各种 exporter 都是和需要监控的机器一起安装的，如果需要监控一些 tcp 端口和七层应用层的状态呢，这个时候就需要黑盒监控了，不需要安装在目标机器上即可从外部去监控。
9115 是它的 http 默认监听端口，blackbox.yml 它的配置文件里以基础的 http、dns、tcp、icmp 等 prober 定制配置出各种监测模块(module)，在 prometheus server 的配置文件里声明用哪个模块去探测哪个 targets，下面以 docker-compose 启动一组实例，docker 的网络自带 dns，所以里面全部用名字替代 ipdocker-co...
主要还是简单说下kubeadm
说说一些现象无论docker还是K8s群看见过太多人盲目了有些是赶鸭子上来的,有的是跟风盲目进来乱学的.其中较多的分类为:
不学docker直接学k8s的跟风狗
没有熟悉Linux操作和一些基础知识的开发
Docker学得不怎么样就迫不及待来学的跟风狗
入门最具有争议的问题就是如何开始,k8s各个组件对于小白来说搭建方式和配置文件对于入门的人来说太庞大了,对于环境来学习一般分为下面两种
按照别人博客或者文章去手动搭建一个环境后学习
找个简易部署的方案来部署环境来学(kubeadm或者ansible之类的懒人搭建)
看过无数小白也怼过不少...
年初的时候就考虑过搭建个在线编辑excel的,之前试过很多owncloud，seafile,nextcloud,kodexplorer基本都是纯网盘或者不免费
这几天又有需求多人同时在线编辑office文件,同事找了个onlyoffice的用docker跑起来了. dockerhub上看了下镜像挺大的而且没有跳转到github上Dockerfile的超链接
稍微用docker history看了下发现里面一堆各种数据库都放同一个镜像里,根本没有解耦
于是便有了解耦这个镜像的冲动
先找官方的例子跑跑看
地址：https://api.onlyoffice.com/editors/demopr...
周五网络组同事告知几个租户的session过大,建议我把租户这几台机器关机了我进去后把网卡down了后开始看稍微看了下是好几个十个字符的进程一直杀不完,叫存储同事把快照挂载了准备周一恢复
结果今天挂载上去后开机发现还是有,好吧,手动查杀结合猜想和状态输出想了下逻辑是如下思路
crontab加计划(/var/spool/cron/用户名文件,/etc/crontab里,/etc/cron.hourly/x.sh)
进程互相守护,杀掉一个生成一个新的在/usr/bin/...
方式总得来讲有两种创建 kubeconfig，证书的话市面上很多教程，要注意下面事项为以下:
要注意 CN(Common Name) 与 O(Organization) 等内容是会影响 Kubernetes 认证的。具体可见 https://kubernetes.io/docs/setup/best-practices/certificates/CN Common Name, apiserver 会从证书中提取该字段作为请求的用户名 (User Name)O Organization, apiserver 会从证书中提取该字段作为请求用户所属的组 (Group)
CA (Certif...
写这篇文章原因所有的监控的agent底层最终都是查询的/proc和/sys里的信息推送(如果错了轻喷),因为收集宿主机信息方面也想用pod跑,会面临到问题常见的zabbix_agent默认读取fs的/proc和/sys,容器跑agent会导致读取的不是宿主机的/proc和/sys而prometheus的node-exporter有选项--path.procfs和--path.sysfs来指定从这俩选项的值的proc和sys读取,容器跑node-exporter只需要挂载宿主机的/proc和/sys到容器fs的...
