Centos7.4 Kubernets1.9集群安装部署

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/xiegh2014/article/details/79683038

一、概述

Master组件：

kube-apiserver
Kubernetes API，集群的统一入口，各组件协调者，以HTTP API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。
kube-controller-manager
处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。
kube-scheduler
根据调度算法为新创建的Pod选择一个Node节点。
Node组件：
kubelet
kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、
下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。
kube-proxy
在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。
docker或rocket/rkt
运行容器。

第三方服务：
  etcd 

分布式键值存储系统。用于保持集群状态，比如Pod、Service等对象信息。

架构图

二、集群部署-环境规划

序号	IP	主机名	组件	备注
1	172.16.8.210	devops-k8s-master	kube-apiserver kube-controller-manager kube-scheduler etcd
2	172.16.8.211	devops-k8s-node1	kubelet kube-proxy docker flannel etcd
3	172.16.8.212	devops-k8s-node2	kubelet kube-proxy docker flannel etcd

软件版本

序号	软件	版本	备注
1	操作系统	CentOS Linux release 7.4.1708 (Core)
2	Kubernetes	1.9
3	Docker	18.03.0-ce
4	Etcd	3.0

三、集群部署-安装Docker

安装Docker依赖包
yum install -y yum-utils device-mapper-persistent-data lvm2

使用Docker ce的官方源
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install docker-ce -y

设置开机启动
systemctl start docker
systemctl enable docker

配置Docker的国内的私有镜像

cat << EOF > /etc/docker/daemon.json
{
"registry-mirrors": [ "https://registry.docker-cn.com"]
}
EOF

查看docker版本系统

[root@devops-k8s-node1 ~]# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 18.03.0-ce
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfd04396dc68220d1cecbe686a6cc3aa5ce3667c
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-693.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.781GiB
Name: devops-k8s-node1
ID: EG5G:RUCR:B6Q6:WWTE:S5SR:O7WA:HKOP:SC33:YZYB:6IMO:LQSO:E4LD
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

四、集群部署-部署Etcd集群

安装etcd
yum -y install etcd

修改配置文件
etcd节点1
grep -n '^'[a-Z] /etc/etcd/etcd.conf
1:ETCD_DATA_DIR="/var/lib/etcd/etcd01"
2:ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
3:ETCD_LISTEN_CLIENT_URLS="http://172.16.8.210:2379,http://127.0.0.1:2379"
4:ETCD_NAME="etcd01"
5:ETCD_INITIAL_ADVERTISE_PEER_URLS="http://172.16.8.210:2380"
6:ETCD_ADVERTISE_CLIENT_URLS="http://172.16.8.210:2379"
7:ETCD_INITIAL_CLUSTER="etcd01=http://172.16.8.210:2380,etcd02=http://172.16.8.211:2380,etcd03=http://172.16.8.212:2380"
8:ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
9:ETCD_INITIAL_CLUSTER_STATE="new

etcd节点2
grep -n '^'[a-Z] /etc/etcd/etcd.conf
1:ETCD_DATA_DIR="/var/lib/etcd/etcd02"
2:ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
3:ETCD_LISTEN_CLIENT_URLS="http://172.16.8.211:2379"
4:ETCD_NAME="etcd02"
5:ETCD_INITIAL_ADVERTISE_PEER_URLS="http://172.16.8.211:2380"
6:ETCD_ADVERTISE_CLIENT_URLS="http://172.16.8.211:2379"
7:ETCD_INITIAL_CLUSTER="etcd01=http://172.16.8.210:2380,etcd02=http://172.16.8.211:2380,etcd03=http://172.16.8.212:2380"
8:ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
9:ETCD_INITIAL_CLUSTER_STATE="new

etcd节点3
grep -n '^'[a-Z] /etc/etcd/etcd.conf
1:ETCD_DATA_DIR="/var/lib/etcd/etcd03"
2:ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
3:ETCD_LISTEN_CLIENT_URLS="http://172.16.8.212:2379"
4:ETCD_NAME="etcd03"
5:ETCD_INITIAL_ADVERTISE_PEER_URLS="http://172.16.8.212:2380"
6:ETCD_ADVERTISE_CLIENT_URLS="http://172.16.8.212:2379"
7:ETCD_INITIAL_CLUSTER="etcd01=http://172.16.8.210:2380,etcd02=http://172.16.8.211:2380,etcd03=http://172.16.8.212:2380"
8:ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
9:ETCD_INITIAL_CLUSTER_STATE="new

注意：先启动etcd节点2,在启动etcd节点1，有可能会报错。
systemctl restart etcd.service 
systemctl enable etcd.service

查看监听端口
netstat -tnlp |grep etcd
tcp        0      0 172.16.8.210:2379       0.0.0.0:*               LISTEN      2989/etcd           
tcp        0      0 127.0.0.1:2379          0.0.0.0:*               LISTEN      2989/etcd           
tcp6       0      0 :::2380                 :::*                    LISTEN      2989/etcd 

五、集群部署-部署Flannel网络

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

但在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使
这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。
   
Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得"同属一个内网"且"不重复的"IP地址，并让属于不同节
点上的容器能够直接通过内网IP通信。
   
Flannel实质上是一种"覆盖网络(overlay network)"，即表示运行在一个网上的网（应用层网络），并不依靠ip地址来传递消息，而是采用一种映射机制，把ip地址和
identifiers做映射来资源定位。也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。
   
原理是每个主机配置一个ip段和子网个数。例如，可以配置一个覆盖网络使用 10.100.0.0/16段，每个主机/24个子网。因此主机a可以接受10.100.5.0/24，主机B可以
接受10.100.18.0/24的包。flannel使用etcd来维护分配的子网到实际的ip地址之间的映射。对于数据路径，flannel 使用udp来封装ip数据报，转发到远程主机。选择
UDP作为转发协议是因为他能穿透防火墙。例如，AWS Classic无法转发IPoIP or GRE 网络包，是因为它的安全组仅仅支持TCP/UDP/ICMP。
   
flannel 使用etcd存储配置数据和子网分配信息。flannel 启动之后，后台进程首先检索配置和正在使用的子网列表，然后选择一个可用的子网，然后尝试去注册它。
etcd也存储这个每个主机对应的ip。flannel 使用etcd的watch机制监视/coreos.com/network/subnets下面所有元素的变化信息，并且根据它来维护一个路由表。为了
提高性能，flannel优化了Universal TAP/TUN设备，对TUN和UDP之间的ip分片做了代理。

1）数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端。
2）Flannel通过Etcd服务维护了一张节点间的路由表，在稍后的配置部分我们会介绍其中的内容。
3）源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel0虚拟网卡，
然后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通信一下的有docker0路由到达目标容器。
 
这样整个数据包的传递就完成了，这里需要解释三个问题：
1）UDP封装是怎么回事？
在UDP的数据内容部分其实是另一个ICMP（也就是ping命令）的数据包。原始数据是在起始节点的Flannel服务上进行UDP封装的，投递到目的节点后就被另一端的Flannel服务
还原成了原始的数据包，两边的Docker服务都感觉不到这个过程的存在。
 
2）为什么每个节点上的Docker会使用不同的IP地址段？
这个事情看起来很诡异，但真相十分简单。其实只是单纯的因为Flannel通过Etcd分配了每个节点可用的IP地址段后，偷偷的修改了Docker的启动参数。
在运行了Flannel服务的节点上可以查看到Docker服务进程运行参数（ps aux|grep docker|grep "bip"），例如“--bip=182.48.25.1/24”这个参数，它限制了所在节
点容器获得的IP范围。这个IP范围是由Flannel自动分配的，由Flannel通过保存在Etcd服务中的记录确保它们不会重复。
 
3）为什么在发送节点上的数据会从docker0路由到flannel0虚拟网卡，在目的节点会从flannel0路由到docker0虚拟网卡？
例如现在有一个数据包要从IP为172.17.18.2的容器发到IP为172.17.46.2的容器。根据数据发送节点的路由表，它只与172.17.0.0/16匹配这条记录匹配，因此数据从docker0
出来以后就被投递到了flannel0。同理在目标节点，由于投递的地址是一个容器，因此目的地址一定会落在docker0对于的172.17.46.0/24这个记录上，自然的被投递到了docker0网卡。

在master节点执行

[root@devops-k8s-master bin]# etcdctl -endpoint="http://172.16.8.210:2379,http://172.16.8.211:2379,http://172.16.8.212:2379" set /coreos.com/network/config  '{ "Network": "172.17.0.0/16", "Backend": {"Type": "vxlan"}}'
{ "Network": "172.17.0.0/16", "Backend": {"Type": "vxlan"}}
[root@devops-k8s-master bin]# etcdctl -endpoint="http://172.16.8.210:2379,http://172.16.8.211:2379,http://172.16.8.212:2379" get /coreos.com/network/config 
{ "Network": "172.17.0.0/16", "Backend": {"Type": "vxlan"}}

创建目录
mkdir /opt/kubernetes/{bin,cfg} -p
mkdir /app/tools/ -p

下载flannel安装
wget https://github.com/coreos/flannel/releases/download/v0.9.1/flannel-v0.9.1-linux-amd64.tar.gz
tar -xvf flannel-v0.9.1-linux-amd64.tar.gz 
mv flanneld mk-docker-opts.sh /opt/kubernetes/bin/

vim /opt/kubernetes/cfg/flanneld
FLANNEL_OPTIONS="--etcd-endpoints=http://172.16.8.210:2379,http://172.16.8.211:2379,http://172.16.8.212:2379" 

编辑启动etcd文件
vim  /usr/lib/systemd/system/flanneld.service 
[Unit]
Description=Flanneld overlay address etcd agent
After=network.target
After=network-online.target
Wants=network-online.target
Before=docker.service

[Service]
Type=notify
EnvironmentFile=/opt/kubernetes/cfg/flanneld
ExecStart=/opt/kubernetes/bin/flanneld  $FLANNEL_OPTIONS
ExecStartPost=/opt/kubernetes/bin/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/subnet.env
Restart=on-failure

[Install]
WantedBy=multi-user.target
RequiredBy=docker.service

启动etcd
systemctl enable flanneld.service
systemctl start flanneld.service

查看路由
节点1
route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    100    0        0 ens32
172.16.8.0      0.0.0.0         255.255.255.0   U     100    0        0 ens32
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.17.15.0     172.17.15.0     255.255.255.0   UG    0      0        0 flannel.1
节点2
route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    100    0        0 ens32
172.16.8.0      0.0.0.0         255.255.255.0   U     100    0        0 ens32
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.17.96.0     172.17.96.0     255.255.255.0   UG    0      0        0 flannel.1