标签： kubernetes

kubernetes的又一次尝试

之前使用docker-swarm，刚开始觉得还不错，但发现经过一段时间后，或者timeout,或者内存过高崩溃，总之，各种各样。

因此，这段时间，我一直使用的是传统的方式，开了一大堆端口号。

这两天又重新拾起了kurbernetes, 使用的环境是ubuntu 16.04, kubeadm的版本是1.7.4。

整个的安装也还是哗哗的，很顺利的结束了。

calico的安装也是哗哗的，很顺利的样子。

pod 同样的结果。

开测！！！

悲剧的挂了，测试静态的页面访问，无问题，一切正常。

但涉及到数据库/redis就timeout了。看了日志，无法连接上。

进入容器，发现无法连接上数据库，redis,过程略，总之，无法连接主机所在的局域网上的主机,当然，除了部署所在的主机除外。

数据库在局域网上，redis也在局域网上。

calico查了许久，不知道如何解决。

iptables 看了下，这个我没有研究过，更加不懂。

总之，经过了一天的研究，反复重装了N次，一直如此。最后没办法了，iptables转发吧，这总可以了吧。

iptables转发很快的配置好了，在主机上测试，竟然不通，该开的都开了啊。

最终发现，这个测试不能在开转发本机上测试，使用其他主机访问转发的端口就无问题，但主机自身不可，泪奔阿。

然后，发现pod中也可以访问数据库了，也可以访问redis了，一切正常了。

从理论上而言，可能要将指定的端口打开，但我将iptables的所有的INPUT, OUTPUT, FORWARD都接受了，还是不可以。只有使用iptables转发指定的端口内容才可以。

总之，目前都正常了。小测了一下，在相同的环境下，和docker bridge的效率几乎不相上下，甚至会更好些。剩下的就看能撑多久了。之前测试时发现网络经常连着连着就不通了。这次还有待时间检验

kubernetes or docker swarm

之前一直在部署kubernetes, 费了九牛二虎之力，前后差不多1个月，查遍各种资料，终于在1M+2N的上面部署成功了，三个节点通讯分布通讯也无问题了，然后，抽了个时间，将生产环境的一部分访问量引导进来， 没想到，仅检查了两天，节点之前的通讯再次无法访问了，光看那些云里雾里的资料，完全没有头绪，然后算了吧，还是试试其他的吧

docker swarm 的部署，头一天学习，模拟下，检查下，然后就简单部署可以了，然后进行service部分的各种参数尝试，观察效果，第二天，部署正式服务器，这个时候，已经快要休假了，导入一部分的访问量， 简单看下访问，没啥大问题，就休假了。

休完假，上去检查下各个服务器，结果发现其中的一个僵住了，反正就是docker ps 无反映了，从模拟客户端访问，发现偶尔下会有超时的现象存在，估计是访问这个僵住的节点了，然后搜索下，没找到特别明显的 故障点，重启下之后，接着跑数据。

现在，两种方式都尝试过，我再也不想碰kubernetes了。

  1. 部署对比

kubernetes相比docker swarm，要麻烦很多，更多的问题是关于网络互联的，虽然最新的kubeadm解决了一部分，但很多的情况下，你就是偏偏无法访问。而没有完全深入kubernetes的情况下，每分钟成M级别 的日志里找问题是件非常痛苦的事情。而docker swarm在这部分接省略好多，几乎没有碰到什么问题就解决了，唯一不足的是，全都是命令行部署，连个配置文件都没有。

  1. 速度对比

我没有对kubernetes进行过大量的测试，仅是在准备卸载的时候进行了下测试。从我这自己的测试来看，200次访问，大约用了40秒的样子，而docker swarm 用了23秒的样子，由于用来管理的服务器配置非常垃圾， 在取消部署在管理服务器上的配置之后，只用了8秒的样子。虽然样本太小，但也说明了不少问题了。从国外的测试资料来看，应该和架构有关系，kubernetes将系统设计的非常的复杂，而docker swarm一直秉承着 简单的原则，在网络处理方面，比kubernetes要少好多个量级，并且，问题的复杂度也小很多个量级

  1. 系统结构对比

kubernetes的结构图我自己研究了好久，才弄懂一点点，我都不知道如何对运维说这个组织，我想，需要对他们说，等他们博士后毕业后再学部署吧。大部分的集群，都需要从一个点慢慢的变成一条线，一个面， kubernetes的起步就直接是一个面了，而docker swarm要简单的多，几乎不需要解释。简单的来说，kubernetes这玩意太复杂，咱们那疙瘩农村人不懂

  1. 优缺点

kubernetes相对而言，文档很多，插件很多，内容很多，总之，一个字：多，两个字：华丽，三个字：不管用。每个人碰到的问题几乎都是独立的，每个人解决问题的方法也几乎是独立的，尤其涉及到网络部分， 我在部署的时候，虚拟机碰到的是一种问题，局域网部署又是另外一种问题，到了生产环境又是一个新的问题，而最后，有些问题得以解决，有些问题重装了系统都没有解决。但kubernetes部署起来非常的优雅， 通过ui去看部署的每个组件的结构也很方便，给你一种想要立马使用的节奏。而docker swarm的部署就非常的痛苦，通过docker service create等等命令来部署，各种插件不全，文档不全，即使通过Shipyard 这种ui去部署也会不尽人意，还不如命令行来的方便，但docker swarm胜在问题相对比较少，碰到问题解决起来也简单。

kubernetes 部署私有registry

既然已经部署好了kubernetes基础了，就想着将所有的内容都部署到kubernetes上， 对于我这种懒人而言，尽可能使用公开的镜像是最好的，维护镜像也是一键很累人的事情。

废话少说，下面就是私有registry并且支持https的部署方式： 

kubectl create -f https://gitlab.4096.info/rix/kubernetes_repo/raw/master/registry/registry.yaml

上面的涉及宣传了。

其实我将自己已经部署到kubernetes的内容都使用自建的gitlab来管理，然后记录下碰到的相关问题。 这样以后可以方便自己使用。

kubernetes 快速安装

这段时间我一直在折腾kubernetes，我讨厌了在不同的电脑上不断的部署，撤销，部署的循环了。 并且，将尽可能的将所有docker化的服务部署到kurbernetes上。

环境准备

ubuntu 16.04 x86_64

安装

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt-get update
# Install docker if you don't have it already.
apt-get install -y docker.io
apt-get install -y kubelet kubeadm kubectl kubernetes-cni

配置

master上运行,其他节点直接join就可以 

kubeadm init --api-advertise-addresses=192.168.228.129

ip地址为本地的可访问外网的地址

经过长时间的，坚持不懈的努力，终于在某天，良心发现，99%的梯子能力+1%的运气， 成功下载了所有的镜像，并运行起来了

kubernetes的各种坑开始

kubectl get pods -n kube-system

无法启动

8080端口是否被占用了？

dns 的pod一直无法启动

上述的配置中不含网络配置，网络需要另外安装关于网络的插件，目前有weave和calico等， 据说calico逼格比较高，所以选择calico开始

calico 各种坑开始

  • calico yaml的选择
    1. 上述的安装使用的是kubeadm安装，因此，选择使用kubeadm/calico.yaml配置
    2. /etc/kubernetes/manifests/etcd.json中关于etcd的配置，默认”–listen-client-urls” 为 “http://127.0.0.1:2379“, “–advertise-client-urls”为”http://127.0.0.1:2379“, 至少修改为外网可访问的，幸运的是，不用重启，过一会kubernetes会自动加载这个
    3. 删除下载下来的配置中的etcd的配置和etcd服务的配置
    4. 修改下载下来的配置中的etcd的地址为kubeadm启动的etcd的地址，没记错的话，直接搜索6666就可以找到这个了
    5. 可能是防火墙影响，一直pull不下来，然后一直重拾
  • calico pool 未知命令( 这个已经不需要了)
    1. 下载的calico.yaml可能比较老，使用最新的版本
    2. 老版本的pool命令已经需要了，新版本中是apply命令
    3. 如果不想更新calico的配置的话，自己pull一个老版本的，然后打tag
    4. 修改calico配置中的calico/ctl的版本为较老的版本
    5. 这个非常坑，我尝试了十几次才找到可以支持的，结果发现官网中的kubeadm/calico.yaml更新了
  • kube-dns 出现 2/3 runing的状态

    基本上，上述pool的问题解决了之后，这个一般不会出现，但不幸，我碰到了， 重启下docker服务试试?

  • calico-* 等在node加入后的各种不正常现象
    1. 要求各节点的主机名称不能相同，(修改/etc/hosts,/etc/hostname等文件)
    2. etcd监听的为127.0.0.1,修改( 上述提到过)
    3. calico的yaml中修改etcd的地址，重新create,未试过apply
    4. 去掉各节点的docker启动服务参数中的dns为127.0.0.1(简单的理解，这个dns要可以解析各个自节点的主机名)
    5. 重启docker服务试试？

webui 安装

满怀信心的打开http://127.0.0.1:8080/ui/ ， 结果无法访问。webui 需要安装才能使用 

kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml

经过上述坑，kubernetes终于算是比较正常了，可以运行了

ceph 安装记录

这个是我再ubuntu 16.04上安装ceph的记录。以便后续参考

前期准备

  1. 两台以上的主机(我用了两台, node1作为mon,node2作为osd)
  2. 互相可通过主机名访问(ping 主机名)
  3. 建议修改hostname, hosts等，不要用反人类的主机名
  4. 所有电脑上开通含有root权限，并且不需要密码的帐号。不想开通的话直接root上
  5. 所有电脑开通ssh服务，并且root可以免密码登陆

所有电脑上配置ceph的源，并安装ceph-deploy

wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -
echo deb https://download.ceph.com/debian-jewel/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
apt update
apt install ceph-deploy

可能仅再master上安装即可，但为了使用正确的版本，还是安装下比较好

安装ceph

清除老旧的安装(如果有的话)

ceph-deploy purgedata node1 node2
ceph-deploy forgetkeys
ceph-deploy purge node1 node2

PS: 如果节点的用户名不一致的话，使用user@node的形式

安装

大部分的操作都在mon的主机上运行即可

环境准备

  • 存放配置

    新建一个目录，存放安装的相关配置模板 

    mkdir -p cephinstall
cd cephinstall

    ceph-deploy new node1#... (monitor节点)
  • 配置ceph模板(ceph.conf文件)

    ext4 文件名过长的bug, 添加下面的配置 

    osd_max_object_name_len = 256
osd_max_object_namespace_len = 64
osd_check_max_object_name_len_on_startup = false

    和kernel相关的支持，防止rbd info出错，其实是部分特性不支持,下面的这个是最基本的，添加后后续所有的部署都自动使用 

    rbd_default_features=1

    完整的配置: 

    [global]
fsid = 6ee65fe7-760d-4dbb-a401-4babb19d940d
mon_initial_members = node1
mon_host = 192.168.228.129
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
public_network = 192.168.228.0/24
cluster_network = 192.168.228.0/24
rbd_default_features=1
osd_max_object_name_len = 256
osd_max_object_namespace_len = 64
osd_check_max_object_name_len_on_startup = false

    一般public_network等网络会自动识别的，默认是小局域网(255台最多，可以修改成需要的)

部署软件

ceph-deploy install node1 node2 #....

在各个节点中创建ceph存放文件的目录，并且修改为ceph:ceph拥有

  • 初始化monitor节点(仅在monitor节点运行)并运行
    ceph-deploy mon create-initial
  • 初始化osd节点（在monitor节点使用ceph-deploy，可以直接部署所有的节点)
    ceph-deploy osd prepare node1:path node2:path #....

    上述命令，node1同时也被用作osd节点了,我只用了两台服务器，而osd节点要求至少需要两个节点才能工作，因此mon节点同时兼做osd节点了

  • 激活osd节点
    ceph-deploy osd activate node1:path node2:path #....

    如果以上工作正常，已经部署完毕了

检查

ceph-deploy admin node1 node1 node2
ceph osd tree
ceph -s

其他

某个osd节点挂了，要移除

ceph osd out osd.1
ceph osd down osd.1
ceph osd rm osd.1
ceph osd crush rm osd.1

rbd ls 等一直卡住

使用ceph osd tree检查下，是否只剩下一个osd节点了，只有一个osd节点rbd是无法工作的，类似raid1的机制

获取client.admin的keyring值

kubernetes中会用到，kubernetes需要base64编码 

ceph auth get-key client.admin | base64