Deploy kubernetes on centos

一. 先介绍最省事的部署方法，直接从官网下release版本安装:

git clone 代码步骤省略 ...

1. 下载各依赖的release版本

   通过修改配置文件 cluster/centos/config-build.sh， 可自定义（k8s, docker, flannel, etcd）各自的下载地址和版本， 不同的版本的依赖可能会需要小改下脚本（版本变更有些打包路径发生了变化，兼容性问题）

   cd cluster/centos && ./build.sh all
   

2. 安装并启动k8s集群环境

   通过修改配置文件 cluster/centos/config-default.sh，定义你环境里的设备的IP和其他参数，推荐运行脚本前先通过ssh-copy-id做好免密钥认证；

   export KUBERNETES_PROVIDER=centos && cluster/kube-up.sh
   

二. 源码级编译安装

本步骤基于上一大步来说,
先来看下载各依赖的release后，cluster/centos下目录发生了什么变化

多了一个binaries的目录，里面是各master和minion上各依赖的二进制文件， 所以我们只要源码编译的结果，替换到这里来， 然后继续上一大步的第2小步即可。

这里说下，本地编译k8s的话，需要设置安装godep，然后命令本地化。

  export PATH=$PATH:$GOPATH/bin

最后只需要去源码根目录下执行， 编译结果在_output目录下

  make

替换到相应的binaries目录下，重新运行kube-up.sh即可。

离线安装 kubernetes 1.5

经常遇到全新初始安装k8s集群的问题，所以想着搞成离线模式，本着最小依赖原则，提高安装速度

基于Centos7-1511-minimal, 非此版本脚本应该会运行出错，自行修改吧

本离线安装所有的依赖都打包放到了百度网盘

第一步

基本思路是，在k8s-deploy目录下，临时启个http server， node节点上会从此拉取所依赖镜像和rpms

# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

windows上可以用hfs临时启个http server， 自行百度如何使用

master侧

运行以下命令，初始化master

192.168.56.1:8000 是我的http-server, 注意要将k8s-deploy.sh 里的HTTP-SERVER变量也改下

curl -L http://192.168.56.1:8000/k8s-deploy.sh | bash -s master

minion侧

视自己的情况而定

curl -L http://192.168.56.1:8000/k8s-deploy.sh |  bash -s join --token=6669b1.81f129bc847154f9 192.168.56.100

总结

整个脚本实现比较简单， 坑都在脚本里解决了。脚本文件在这里

就一个master-up和node-up， 基本一个函数只做一件事，很清晰，可以自己查看具体过程。

1.5 与 1.3给我感觉最大的变化是网络部分， 1.5启用了cni网络插件
不需要像以前一样非要把flannel和docker绑在一起了（先启flannel才能启docker）。

具体可以看这里
https://github.com/containernetworking/cni/blob/master/Documentation/flannel.md

master侧如果是单核的话，会因资源不足， dns安装失败。

很久没写东西了，大佬最近是在搞区块链嘛，抽时间也更新一下blog罗~

构建生产环境级的docker Swarm集群

此文档适用于不低于1.12版本的docker，因为swarm已内置于docker-engine里。

1. 硬件需求

   这里以5台PC服务器为例, 分别如下作用

   • manager0
   • manager1
   • node0
   • node1
   • node2

2. 每台PC上安装docker-engine

   一台一台的ssh上去执行，或者使用ansible批量部署工具。

   安装docker-engine

   curl -sSL https://get.docker.com/ | sh
   

   启动之，并使之监听2375端口

   sudo docker daemon -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock
   

   亦可修改配置，使之永久生效

   mkdir /etc/systemd/system/docker.service.d
   cat <<EOF >>/etc/systemd/system/docker.service.d/docker.conf
   [Service]
   ExecStart=
   ExecStart=/usr/bin/docker daemon -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --dns 180.76.76.76  --insecure-registry registry.cecf.com -g /home/Docker/docker
   EOF
   

   如果开启了防火墙，需要开启如下端口

   • TCP port 2377 for cluster management communications
   • TCP and UDP port 7946 for communication among nodes
   • TCP and UDP port 4789 for overlay network traffic

3. 创建swarm

   docker swarm init --advertise-addr <MANAGER-IP>

   我的实例里如下：

   [root@manager0 ~]# docker swarm init --advertise-addr 10.42.0.243
   Swarm initialized: current node (e5eqi0lue90uidzsfddeqwfl8) is now a manager.
   
   To add a worker to this swarm, run the following command:
   
       docker swarm join \
       --token SWMTKN-1-3iskhw3lsc9pkdtijj1d23lg9tp7duj18f477i5ywgezry7zlt-dfwjbsjleoajcdj13psu702s6 \
       10.42.0.243:2377
   
   To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

   使用 --advertise-addr 来声明manager0的IP，其他的nodes必须可以和此IP互通，
   一旦完整初始化，此node即是manger又是worker node.

   通过docker info来查看

   $ docker info
   
   Containers: 2
   Running: 0
   Paused: 0
   Stopped: 2
     ...snip...
   Swarm: active
     NodeID: e5eqi0lue90uidzsfddeqwfl8
     Is Manager: true
     Managers: 1
     Nodes: 1
     ...snip...
   

   通过docker node ls来查看集群的node信息

   [root@manager0 ~]# docker node ls
   ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
   e5eqi0lue90uidzsfddeqwfl8 *  manager0  Ready   Active        Leader
   
   

   这里的*来指明docker client正在链接在这个node上。

4. 加入swarm集群

   执行在manager0上产生docker swarm init产生的结果即可

   如果当时没记录下来，还可以在manager上补看
   想把node以worker身份加入，在manager0上执行下面的命令来补看。

   docker swarm join-token worker
   

   想把node以manager身份加入，在manager0上执行下面的命令来来补看。

   docker swarm join-token manager
   

   为了manager的高可用，我这里需要在manager1上执行

   docker swarm join \
   --token SWMTKN-1-3iskhw3lsc9pkdtijj1d23lg9tp7duj18f477i5ywgezry7zlt-86dk7l9usp1yh4uc3rjchf2hu \
   10.42.0.243:2377
   

   我这里就是依次在node0-2上执行

   docker swarm join \
     --token SWMTKN-1-3iskhw3lsc9pkdtijj1d23lg9tp7duj18f477i5ywgezry7zlt-dfwjbsjleoajcdj13psu702s6 \
     10.42.0.243:2377
   

   这样node就会加入之前我们创建的swarm集群里。

   再通过docker node ls来查看现在的集群情况， swarm的集群里是以node为实例的

   [root@manager0 ~]# docker node ls
   ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
   0tr5fu8ebi27cp2ot210t67fx    manager1  Ready   Active        Reachable
   46irkik4idjk8rjy7pqjb84x0    node1     Ready   Active
   79hlu1m7x9p4cc4npa4xjuax3    node0     Ready   Active
   9535h8ow82s8mzuw5kud2mwl3    consul0   Ready   Active
   e5eqi0lue90uidzsfddeqwfl8 *  manager0  Ready   Active        Leader

   这里MANAFER标明各node的身份，空即为worker身份。

5. 部署服务

   Usage:    docker service COMMAND
   
   Manage Docker services
   
   Options:
         --help   Print usage
   
   Commands:
     create      Create a new service
     inspect     Display detailed information on one or more services
     ps          List the tasks of a service
     ls          List services
     rm          Remove one or more services
     scale       Scale one or multiple services
     update      Update a service
   

   部署示例如下：

   docker service create --replicas 2 --name helloworld alpine ping 300.cn
   

   docker service ls罗列swarm集群的所有services
   docker service ps helloworld查看service部署到了哪个node上
   docker service inspect helloworld 查看service 资源、状态等具体信息
   docker servcie scale helloworld=5来扩容service的个数
   docker service rm helloworld 来删除service
   docker service update 来实现更新service的各项属性，包括滚动升级等。

   可更新的属性包含如下：

   Usage:    docker service update [OPTIONS] SERVICE
   
   Update a service
   
   Options:
         --args string                    Service command args
         --constraint-add value           Add or update placement constraints (default [])
         --constraint-rm value            Remove a constraint (default [])
         --container-label-add value      Add or update container labels (default [])
         --container-label-rm value       Remove a container label by its key (default [])
         --endpoint-mode string           Endpoint mode (vip or dnsrr)
         --env-add value                  Add or update environment variables (default [])
         --env-rm value                   Remove an environment variable (default [])
         --help                           Print usage
         --image string                   Service image tag
         --label-add value                Add or update service labels (default [])
         --label-rm value                 Remove a label by its key (default [])
         --limit-cpu value                Limit CPUs (default 0.000)
         --limit-memory value             Limit Memory (default 0 B)
         --log-driver string              Logging driver for service
         --log-opt value                  Logging driver options (default [])
         --mount-add value                Add or update a mount on a service
         --mount-rm value                 Remove a mount by its target path (default [])
         --name string                    Service name
         --publish-add value              Add or update a published port (default [])
         --publish-rm value               Remove a published port by its target port (default [])
         --replicas value                 Number of tasks (default none)
         --reserve-cpu value              Reserve CPUs (default 0.000)
         --reserve-memory value           Reserve Memory (default 0 B)
         --restart-condition string       Restart when condition is met (none, on-failure, or any)
         --restart-delay value            Delay between restart attempts (default none)
         --restart-max-attempts value     Maximum number of restarts before giving up (default none)
         --restart-window value           Window used to evaluate the restart policy (default none)
         --stop-grace-period value        Time to wait before force killing a container (default none)
         --update-delay duration          Delay between updates
         --update-failure-action string   Action on update failure (pause|continue) (default "pause")
         --update-parallelism uint        Maximum number of tasks updated simultaneously (0 to update all at once) (default 1)
     -u, --user string                    Username or UID
         --with-registry-auth             Send registry authentication details to swarm agents
     -w, --workdir string                 Working directory inside the container
   

自年前一周到现在，我基本都在实践openshift， 下面说下我的总结，

现在社区开源的paas平台，目前只有Cloud Foundry和openshift origin两个，前者是vmware开源的，后者是RedHat开源的。
因为openshift的技术栈和我们比较贴近，技术栈：

1. docker ->提供进程级别的打包隔离应用的能力
2. kuberntees->提供面向集群编排容器的能力
   所以我们选择了openshift。

首先，openshift到现在发展了3代产品，第一，二代是自研的，但自2014年 k8s一经推出，redhat就从对外宣称要推出基于k8s的第三代产品,
下面的链接详细的介绍了红帽为什么要选择基于kubernetes推出互不兼容的第三代产品
https://blog.openshift.com/red-hat-chose-kubernetes-openshift/，
总结起来就3点理由：

1. google根据内部borg系统开源的，自带了容器面向集群编排的生产特性设计。
2. 红帽早期就和google一起合作贡献过内核Cgroups（docker底层依赖）的技术
3. k8s是真正的社区引导的，目前不由任何一家公司主导，是CNCF（云原生基金会）管理的

目前红帽是除google外对kubernetes的贡献排名第一。

现在kubernetes已经release到1.5， 今年3月份1.6也会release出来了。k8s自14年发展到现在，能力已不仅仅限于容器编排那么简单了。
但现在kubernetes里的很多概念确实也是从openshift引入进去的，就我知道的有api group，RBAC模型等 ，下面从方方面面对比下k8s和openshift。

运行环境：都支持x86架构

虽然openshift是基于kubernetes，但后者还额外支持arm，ppc，s390等，
当然k8s的这个优势我们是不care的

用户和权限：两者都具备

都有接口和众多认证系统对接，比如ldap，keystone，Oauth2等
授权的话，现在都是RBAC这一套，引入rolebinding和clusterbinding的概念，是openshift贡献给上游的，但目前k8s默认是没有开启的，1.6里就会默认开启了。
易用性上openshift大大的胜出，已经在cli和web console上部分集成了。
理论上，K8s在不做二次开发的情况下，也可以实现openshift的功能，（尚未实践）

项目管理：两者都具备

openshift里有个project的概念，就是基于k8s的namespace加了些注解，
目前两者都可以实现：
基于namespace级别的policy（允许用户能做什么不能做什么）
基于namespace级别的资源配额限制
从易用性上，openshift胜出,其已经集成到cli上了，而k8s目前必须要通过kubect create -f policy.yaml的方式完成

CI&CD: openshift自身集成，k8s要通过第三方实现

目前openshift支持dockerfile，source， jenkins pipeline等方式完成自动编译，自动部署的话，支持人工干预上线（是jenkins pipeline的功能）
openshift还引入了dc的概念，比k8s里的deloyment强大些。
k8s的话，目前第三方案实现有deis，fabric8等
易用性和完成度上，openshift胜出

监控和日志：两者都具备

Kubernetes自身只有heapster项目，可以监控容器基本资源使用和基本的集群状态，应用级监控和告警有第三方prometheus支持，该项目已被列入CNCF（云原生基金会）项目；
目前openshift已集成红帽自家的开源监控方案Hawkular，已集成到web console，该方案支持应用级监控和告警，默认没集成，需要开发调试。
日志方面目前两者都采用efk方案，但openshift已和用户权限结合，用户只能看到自己应用的日志
完成度上openshift胜出

共享存储： 两者都具备

各种接口对接，都具备，目前两者兼容范围很广，包括nfs，ceph RBD， iSCSI等
共享存储业界大都选择ceph，其就是redhat旗下的开源产品。
两者不相上下；

网络SDN：两者都具备

网络部分，k8s社区现在很多支持，主要分为overlay（flannel）和SDN（ovs）两部分
目前openshift的sdn部分是基于ovs+openflow实现的，可以针对project（namespace）实现vxlan级别的隔离,可控制流向和带宽限制等等，当然K8s的networkpolicy也是兼容的；
从集成度上看，openshift胜出，从可选择范围上看，k8s大大的胜出；

生产部署：两者都具备

部署，主要考虑生产级别和调式开发环境搭建，目前两者都有方案支撑；
虽然openshift号称是on top of kuberntes, 但适用于k8s的安装方案，并不适用于前者，openshfit已经耦合进kubernetes了。
调式开发环境，两者都有，一个是minikube和另一个minishift，我自己实践这点，openshift更方便些。
生产环境的话，openshift给出基于ansible的方案，k8s目前有各种方案支撑，比如基于bootkube的自举方式完成部署，基于kops的云上部署方式，我自己也写过基于kubeadm的离线部署的方案
单考虑生产部署的话，k8s胜出；

web console：两者都具备

k8s目前只有dashboard使用，其基本是面向管理员的，基于用户权限管理部分尚在开发中
openshift有自己的web console，集成了监控，ci&cd，用户，存储管理等。
完成度和易用性好，openshift胜出

应用商店（模板）：两者都具备

k8s社区采用helm方案，openshfit一开始也是采用这个，后来为了和自有的console界面结合，自搞了一套template，
目前helm是可以兼容openshfit 自有template的。
两者不好评判高低

社区发展： k8s胜出

两者都有自己的社区，但从规模和活跃度上，k8s都远远高于openshift。
openshfit基本会慢于k8s社区1个大版本，比如有状态服务stateful和异地机房federation，现在openshift还不支持，但也在有计划的引入中。

总结：各有利弊。

基于k8s做，方案可选择性更大，各方面都有多种选择，但围绕多租户的方方面面都需要我们统一打通，
比如基于租户的CI&CD，用户只能看到自己的监控告警数据，租户可以自由管理分配给它的空间等等；
基于openshift的话，其提供了完整的caas平台能力，并已开放所有API，可以定制自己的功能，虽号称模块可扩展​，但社区活跃度不高，除了默认集成的，其他可选择性不大，如果真要替换某模块的话，只能自己趟坑了。
比如边界路由，openshift默认采用haproxy，如果我们要采用nginx的话，就得自己针对nginx开发适配好openshift原有的API，不然整体完成度就会大打折扣。
所以选择openshift的话，基本就是围绕红帽给出的方案来转。
根据自己的需求来选择，如果你像做个paas平台，那openshfit拿来就用，如果是只是运维部门来做个部署管理，那k8s会更简单些，不会涉及到太多东西。

github开源项目的正确贡献姿势

原文地址
常见的开源项目贡献指导里都是差不多的样子：
* 要先fork
* 然后change something
* 再然后fetch，rebase
* push origin， 最后发起pull request
具体到不同的项目，可能会要求更多的细节步骤,但大体如上。

这些都没错，但实际操作起来，和习惯不符。因为我一般是先clone一个项目，然后使用中发现有问题，会尝试去修改，fix OK的话，才会想着去贡献代码
可事情到了这一步，再按照一开始的方式操作，会平白无辜耗费很多时间，还涉及到已经修改完代码如何同步过去的问题。
以下是我个人总结的一套方法，屡试不爽乎。

这里我以k8s项目的贡献经历来举例，以备不时之需。git这个东西，不常用，会忘记的，即使你已经理解原理了。。。

• 首先clone K8s的项目代码。

  git clone https://github.com/kubernetes/kubernetes.git
  

• 然后自行编译 make, 使用中发现一些问题

  就会去github的issue里找找看。。。竟然没人提这个问题，问问同事或同行，人家表示没碰到过你的问题，
  好吧，自己尝试去修改... 不断编译 ... 测试... 最终OK了，我要贡献代码！！！
  完啦，没有按照最佳习惯来，改动前忘记新建分支了。。。（这个习惯很重要，可以省掉很多麻烦）
  只能如此操作了，可以来个大挪移到新建分支上

  git stash
  git checkout -b fix_something
  git stash apply
  

• 此时去github上fork下原项目，拿到fork后的项目地址，再来个偷天换日。

  git remote rename origin upstream
  git remote add origin [email protected]:xiaoping378/kubernetes.git
  

• 再然后就可以按一开始介绍的，fetch, rebase, push origin, 发起PR了。

  git fetch upstream
  git rebase upstream/master
  # 有冲突就git mergetool
  git push origin fix_something 
  # 然后去github页面发起pull request即可。
  

• 注意事项
  值的注意的是，以后在master分支上git pull，就是从upstream/master那里拉取的，和一般情况不一样的地方。
  这样会少了烦人的merge msg（-ff可以解决）， 还可以用简单的pull来同步上游代码。
  更可以意淫自己是原项目的核心开发人员了。。。
  以后本地同步fork的项目到上游的最新状态，这样操作：

  git checkout master
  git pull
  git push origin master
  

  其实github上那个fork的项目，只是用来提PR的，这样可以在原项目的分支上任意玩耍了。当然你也可以用来备份一些比较大的feature

• 最后记录下个人的git global配置

  # cat ~/.gitconfig
  [user]
    email = [email protected]
    name = xiaoping378
  [merge]
    tool = meld
  [push]
    default = simple
  [core]
    quotepath = false
  

你好，是不是用puppeth用（clique）PoA产生的创世区块，后面在区块共识的时候用的就是PoA算法？