k8s集群部署

时间 2020-06-17 标签 k8s 集群部署

1）部署环境vue

部署节点 x1 : 运行这份 ansible 脚本的节点
etcd节点 x3 : 注意etcd集群必须是1,3,5,7...奇数个节点
master节点 x1 : 运行集群主要组件
node节点 x3 : 真正应用部署的节点，根据须要增长机器配置和节点数

2）下载dockernode

wget download.yunwei.edu/shell/docker.tar.gz ls tar zxvf docker.tar.gz ls cd docker/ ls bash docker.sh

3）设置免密登录而且配置号域名解析服务docker

172.16.254.20 reg.yunwei.edu　　　　　　#此域名解析是为了获取docker版ansible的资源地址 192.168.253.9 cicd　　　　　　　　　　　　#一个部署，三个节点，node1同时又是master节点 192.168.253.14 node1 192.168.253.11 node2 192.168.253.10 node3

4）下载并运行docker版ansibleshell

[root@cicd ~]# docker run -itd -v /etc/ansible:/etc/ansible -v /etc/kubernetes/:/etc/kubernetes/ -v /root/.kube:/root/.kube -v /usr/local/bin/:/usr/local/bin/ 1acb4fd5df5b  /bin/sh WARNING: IPv4 forwarding is disabled. Networking will not work.

上述报错解决方法：json

在下面文件内添加，而后重启netowrkapi

　　systemctl restart networkbash

[root@cicd ~]# cat /usr/lib/sysctl.d/00-system.conf

　　net.ipv4.ip_forward=1网络

5)进入刚刚下载ansible的容器。app

[root@cicd ~]# docker exec -it 36aac0dee157 /bin/sh / # ansible all -m ping [WARNING]: Could not match supplied host pattern, ignoring: all [WARNING]: provided hosts list is empty, only localhost is available [WARNING]: No hosts matched, nothing to do

发现没法ping通，这是由于没有配置主机组以及取消配置文件中的host-key注释。负载均衡

又由于咱们宿主机与容器创建了目录映射，因此咱们这里直接在宿主机之下作如下步骤

6）上传k8s的压缩包，而后解压，进入kubernetes目录。

wget http://download.yunwei.edu/shell/docker.tar.gz

[root@cicd kubernetes]# ls
bash ca.tar.gz harbor-offline-installer-v1.4.0.tgz image image.tar.gz k8s197.tar.gz kube-yunwei-197.tar.gz scope.yaml sock-shop

7）解压kube-yunwei-197.tar.gz压缩包，并把解压后目录下面的内容所有移动到/etc/ansible/

　解压k8s197.tar.gz压缩包，并把解压后文件所有移动到/etc/ansible/bin/目录下

[root@cicd ansible]# ls 01.prepare.retry  02.etcd.yml    04.kube-master.yml  06.network.yml ansible.cfg example manifests tools 01.prepare.yml    03.docker.yml  05.kube-node.yml    99.clean.yml    bin          hosts    roles

[root@cicd bin]# ls
bridge cfssljson docker-containerd-ctr docker-proxy flannel kubectl loopback
calicoctl docker docker-containerd-shim docker-runc host-local kubelet portmap
cfssl docker-compose dockerd etcd kube-apiserver kube-proxy VERSION.md
cfssl-certinfo docker-containerd docker-init etcdctl kube-controller-manager kube-scheduler

8）在/etc/ansible/目录下建立一个hosts文件，并将example目录下的样本文件复制到此文件中。

[deploy] 192.168.253.9　　　　　　#部署节点ip #etcd集群请提供以下NODE_NAME、NODE_IP变量,请注意etcd集群必须是1,3,5,7...奇数个节点 [etcd] 192.168.253.14 NODE_NAME=etcd1 NODE_IP="192.168.253.14"
192.168.253.11 NODE_NAME=etcd2 NODE_IP="192.168.253.11"
192.168.253.10 NODE_NAME=etcd3 NODE_IP="192.168.253.10" [kube-master] 192.168.253.14 NODE_IP="192.168..253.14" [kube-node] 192.168.253.14 NODE_IP="192.168.253.14"
192.168.253.11 NODE_IP="192.168.253.11"
192.168.253.10 NODE_IP="192.168.253.10" [all:vars] # ---------集群主要参数--------------- #集群部署模式：allinone, single-master, multi-master DEPLOY_MODE=single-master #集群 MASTER IP MASTER_IP="192.168.253.14" #集群 APISERVER KUBE_APISERVER="https://192.168.253.14:6443"　　　　　　#master节点ip #TLS Bootstrapping 使用的 Token，使用 head -c 16 /dev/urandom | od -An -t x | tr -d ' ' 生成 BOOTSTRAP_TOKEN="d18f94b5fa585c7110f56803d925d2e7" # 集群网络插件，目前支持calico和flannel CLUSTER_NETWORK="calico" # 部分calico相关配置，更全配置能够去roles/calico/templates/calico.yaml.j2自定义 # 设置 CALICO_IPV4POOL_IPIP=“off”,能够提升网络性能，条件限制详见 05.安装calico网络组件.md CALICO_IPV4POOL_IPIP="always" # 设置 calico-node使用的host IP，bgp邻居经过该地址创建，可手动指定端口"interface=eth0"或使用以下自动发现 IP_AUTODETECTION_METHOD="can-reach=113.5.5.5" # 部分flannel配置，详见roles/flannel/templates/kube-flannel.yaml.j2 FLANNEL_BACKEND="vxlan" # 服务网段 (Service CIDR），部署前路由不可达，部署后集群内使用 IP:Port 可达 SERVICE_CIDR="10.68.0.0/16" # POD 网段 (Cluster CIDR），部署前路由不可达，**部署后**路由可达 CLUSTER_CIDR="172.20.0.0/16" # 服务端口范围 (NodePort Range) NODE_PORT_RANGE="20000-40000" # kubernetes 服务 IP (预分配，通常是 SERVICE_CIDR 中第一个IP) CLUSTER_KUBERNETES_SVC_IP="10.68.0.1" # 集群 DNS 服务 IP (从 SERVICE_CIDR 中预分配) CLUSTER_DNS_SVC_IP="10.68.0.2" # 集群 DNS 域名 CLUSTER_DNS_DOMAIN="cluster.local." # etcd 集群间通讯的IP和端口, **根据实际 etcd 集群成员设置** ETCD_NODES="etcd1=https://192.168.253.14:2380,etcd2=https://192.168.253.11:2380,etcd3=https://192.168.253.10:2380" # etcd 集群服务地址列表, **根据实际 etcd 集群成员设置** ETCD_ENDPOINTS="https://192.168.253.14:2379,https://192.168.253.11:2379,https://192.168.253.10:2379" # 集群basic auth 使用的用户名和密码 BASIC_AUTH_USER="admin" BASIC_AUTH_PASS="admin" # ---------附加参数-------------------- #默认二进制文件目录 bin_dir="/usr/local/bin"　　　　　　# /root改成/usr #证书目录 ca_dir="/etc/kubernetes/ssl" #部署目录，即 ansible 工做目录 base_dir="/etc/ansible"

9）关闭防火墙，重启docker

再次进入容器，cd到/etc/ansible查看

出现6个脚本文件以及其余若干个文件

[root@cicd ansible]# docker exec -it ad5e6744151e /bin/sh / # cd /etc/ansible/
/etc/ansible # ls 01.prepare.retry    05.kube-node.yml example 01.prepare.yml      06.network.yml hosts 02.etcd.yml         99.clean.yml manifests 03.docker.yml ansible.cfg roles 04.kube-master.yml  bin                 tools

10）在容器内执行01-05脚本

/etc/ansible # ansible-playbook 01.prepare.yml

/etc/ansible # ansible-playbook 02.etcd.yml

/etc/ansible # ansible-playbook 03.docker.yml

/etc/ansible # ansible-playbook 04.kube-master.yml

/etc/ansible # ansible-playbook 05.kube-node.yml

11) 部署节点另开一个会话。其余三个节点建立一个名为image的目录用于接收部署节点发送的镜像包。

　　执行如下命令，而后将image目录下的全部镜像所有发送给node1.node2.node3。

[root@cicd ~]# cd kubernetes [root@cicd kubernetes]# ls bash ca.tar.gz harbor-offline-installer-v1.4.0.tgz  image  image.tar.gz  k8s197.tar.gz  kube-yunwei-197.tar.gz  scope.yaml  sock-shop [root@cicd kubernetes]# cd image [root@cicd image]# ls bash-completion-2.1-6.el7.noarch.rpm  coredns-1.0.6.tar.gz  heapster-v1.5.1.tar  kubernetes-dashboard-amd64-v1.8.3.tar.gz calico grafana-v4.4.3.tar    influxdb-v1.3.3.tar  pause-amd64-3.1.tar

12）node1节点进入到image目录，导入全部镜像

[root@node2 ~]# cd image/ [root@node2 image]# ls bash-completion-2.1-6.el7.noarch.rpm  grafana-v4.4.3.tar calico-cni-v2.0.5.tar                 heapster-v1.5.1.tar calico-kube-controllers-v2.0.4.tar    influxdb-v1.3.3.tar calico-node-v3.0.6.tar                kubernetes-dashboard-amd64-v1.8.3.tar.gz coredns-1.0.6.tar.gz                  pause-amd64-3.1.tar [root@node2 image]# for ls in `ls` ;do docker load -i $ls ;done

13）查看镜像是否导入成功

[root@node2 image]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE mariadb latest 3ab4bbd66f97 8 hours ago 344MB zabbix/zabbix-agent                                 latest              bc21cdfcc381        6 days ago          14.9MB calico/node                                         v3.0.6              15f002a49ae8        14 months ago 248MB calico/kube-controllers                             v2.0.4              f8e683e673ec        14 months ago       55.1MB calico/cni                                          v2.0.5              b5e5532af766        14 months ago       69.1MB coredns/coredns                                     1.0.6               d4b7466213fe        16 months ago       39.9MB mirrorgooglecontainers/kubernetes-dashboard-amd64   v1.8.3              0c60bcf89900        16 months ago 102MB mirrorgooglecontainers/heapster-amd64               v1.5.1              c41e77c31c91        16 months ago       75.3MB mirrorgooglecontainers/pause-amd64                  3.1                 da86e6ba6ca1        18 months ago 742kB mirrorgooglecontainers/heapster-influxdb-amd64      v1.3.3              577260d221db        21 months ago       12.5MB mirrorgooglecontainers/heapster-grafana-amd64       v4.4.3              8cb3de219af7        21 months ago       152MB

其余两个节点操做相同。

14）在部署节点的容器内执行06脚本

/etc/ansible # ansible-playbook 06.network.yml

15）进入manifests/coredns/目录下，执行

　　kubeclt create -f .

/etc/ansible # cd manifests/
/etc/ansible/manifests # ls coredns dashboard efk heapster ingress kubedns /etc/ansible/manifests # cd coredns/
/etc/ansible/manifests/coredns # ls coredns.yaml /etc/ansible/manifests/coredns # kubectl create -f . serviceaccount "coredns" created clusterrole "system:coredns" created clusterrolebinding "system:coredns" created configmap "coredns" created deployment "coredns" created service "coredns" created

16)部署节点的宿主机界面执行：

 kubectl get node -o wide

[root@cicd image]# kubectl get node -o wide NAME STATUS ROLES AGE VERSION EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION          CONTAINER-RUNTIME 192.168.253.10   Ready                      <none>    10m       v1.9.7    <none>        CentOS Linux 7 (Core)   3.10.0-693.el7.x86_64   docker://18.3.0
192.168.253.11   Ready                      <none>    10m       v1.9.7    <none>        CentOS Linux 7 (Core)   3.10.0-693.el7.x86_64   docker://18.3.0
192.168.253.14   Ready,SchedulingDisabled   <none>    12m       v1.9.7    <none>        CentOS Linux 7 (Core)   3.10.0-693.el7.x86_64   docker://18.3.0

17）查看名称空间

　　查看kube-system空间内的pod详情

[root@cicd image]# kubectl get ns NAME STATUS AGE default Active 14m kube-public Active 14m kube-system Active 14m [root@cicd image]# kubectl get pod -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE calico-kube-controllers-754c88ccc8-86rht   1/1       Running   0          4m        192.168.253.11   192.168.253.11 calico-node-cvhcn                          2/2       Running   0          4m        192.168.253.10   192.168.253.10 calico-node-j5d66                          2/2       Running   0          4m        192.168.253.14   192.168.253.14 calico-node-qfm66                          2/2       Running   0          4m        192.168.253.11   192.168.253.11 coredns-6ff7588dc6-mbg9x 1/1 Running 0 2m 172.20.104.1 192.168.253.11 coredns-6ff7588dc6-vzvbt                   1/1       Running   0          2m        172.20.135.1 192.168.253.10

18）在不一样节点上尝试ping通彼此节点的内部ip

[root@node1 image]# ping 172.20.135.1 PING 172.20.135.2 (172.20.135.2) 56(84) bytes of data. 64 bytes from 172.20.135.2: icmp_seq=1 ttl=63 time=0.813 ms 64 bytes from 172.20.135.2: icmp_seq=2 ttl=63 time=0.696 ms

若是ping通则证实k8s实验部署成功。

19）cd到dashboard目录下执行

kubectl create -f .

/etc/ansible/manifests # cd dashboard/
/etc/ansible/manifests/dashboard # ls 1.6.3                      kubernetes-dashboard.yaml  ui-read-rbac.yaml admin-user-sa-rbac.yaml    ui-admin-rbac.yaml /etc/ansible/manifests/dashboard # kubectl create -f . serviceaccount "admin-user" created clusterrolebinding "admin-user" created secret "kubernetes-dashboard-certs" created serviceaccount "kubernetes-dashboard" created role "kubernetes-dashboard-minimal" created rolebinding "kubernetes-dashboard-minimal" created deployment "kubernetes-dashboard" created service "kubernetes-dashboard" created clusterrole "ui-admin" created rolebinding "ui-admin-binding" created clusterrole "ui-read" created rolebinding "ui-read-binding" created

20）再次执行

kubectl get pod -n kube-system -o wide

发现多出一个容器

[root@cicd image]# kubectl get pod -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE calico-kube-controllers-754c88ccc8-86rht   1/1       Running   0          7m        192.168.253.11   192.168.253.11 calico-node-cvhcn                          2/2       Running   0          7m        192.168.253.10   192.168.253.10 calico-node-j5d66                          2/2       Running   0          7m        192.168.253.14   192.168.253.14 calico-node-qfm66                          2/2       Running   0          7m        192.168.253.11   192.168.253.11 coredns-6ff7588dc6-mbg9x                   1/1       Running   0          5m        172.20.104.1     192.168.253.11 coredns-6ff7588dc6-vzvbt                   1/1       Running   0          5m        172.20.135.1     192.168.253.10 kubernetes-dashboard-545b66db97-cbh9w 1/1 Running 0 1m 172.20.135.2 192.168.253.10

在node1节点ping172.168.135.2

[root@node1 image]# ping 172.20.135.2
PING 172.20.135.2 (172.20.135.2) 56(84) bytes of data.
64 bytes from 172.20.135.2: icmp_seq=1 ttl=63 time=0.813 ms
64 bytes from 172.20.135.2: icmp_seq=2 ttl=63 time=0.696 ms

若是可以ping通，执行如下命令

/etc/ansible/manifests/dashboard # kubectl cluster-info Kubernetes master is running at https://192.168.253.14:6443
CoreDNS is running at https://192.168.253.14:6443/api/v1/namespaces/kube-system/services/coredns:dns/proxy
kubernetes-dashboard is running at https://192.168.253.14:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy

21）复制加粗链接访问网页

登录用户名和密码后，选中令牌，执行如下命令

[root@cicd image]# kubectl -n kube-system describe secret $(kubectl -n kube-system get secret|grep admin-user|awk '{print $1}') Name: admin-user-token-q46rv Namespace: kube-system Labels: <none> Annotations: kubernetes.io/service-account.name=admin-user kubernetes.io/service-account.uid=b31a5f5c-9283-11e9-a6e3-000c2966ee14 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1359 bytes namespace:  11 bytes token:  eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi11c2VyLXRva2VuLXE0NnJ2Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJiMzFhNWY1Yy05MjgzLTExZTktYTZlMy0wMDBjMjk2NmVlMTQiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06YWRtaW4tdXNlciJ9.O5gqGeUNlwUYYDSL2bSolvCUoGmWjipaiqwrfBCbCroQ2SanUdP0w3SbJ0Vhb1Ddv6QswC2HeaGeHV_ideoH03RalKlJoJmCIaz0OpbvWQ6KaeDKLHqBxGyT4S-AHncF908aHr84JfY6GVIfJJL7P68EzMrFpOI24YC_PDfZvBm7zud7uhiFClWs8MMMmSt0YAWoakVQ4sPfyhlBX9rZLE1-2LobMio6g0vue9PJxzmJhZ7GrcOqHu__IpbmtPpwj-VHnvhDkU8dhC8617HyVU7xDsajZ89HmqSIVFtXrpiDTChDwBfMlx7QRmzu7bNNXyesQqDoyBJJgReW3M0evw

复制以上令牌内容到空格中，点击进入如下页面表明成功。

1、 Kubernetes 介绍：

kubernetes起源

Kubernetes (K8s) 是 Google 在 2014 年发布的一个开源项目。

听说 Google 的数据中内心运行着超过 20 亿个容器，并且 Google 十年前就开始使用容器技术。最初，Google 开发了一个叫 Borg 的系统（如今命令为 Omega）来调度如此庞大数量的容器和工做负载。在积累了这么多年的经验后，Google 决定重写这个容器管理系统，并将其贡献到开源社区，让全世界都能受益。

这个项目就是 Kubernetes。简单的讲，Kubernetes 是 Google Omega 的开源版本。

从 2014 年第一个版本发布以来，Kubernetes 迅速得到开源社区的追捧，包括 Red Hat、VMware、Canonical 在内的不少有影响力的公司加入到开发和推广的阵营。目前 Kubernetes 已经成为发展最快、市场占有率最高的容器编排引擎产品。 Kubernetes 一直在快速地开发和迭代。

Kubernetes 的几个重要概念

在实践以前，必须先学习 Kubernetes 的几个重要概念，它们是组成 Kubernetes 集群的基石。

Cluster

Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各类基于容器的应用。

Master

Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master 运行 Linux 操做系统，能够是物理机或者虚拟机。为了实现高可用，能够运行多个 Master。

Node

Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux 操做系统，能够是物理机或者是虚拟机。

Pod

Pod 是 Kubernetes 的最小工做单元。每一个 Pod 包含一个或多个容器。Pod 中的容器会做为一个总体被 Master 调度到一个 Node 上运行。

Kubernetes 引入 Pod 主要基于下面两个目的：

可管理性。

有些容器天生就是须要紧密联系，一块儿工做。Pod 提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期。
通讯和资源共享。

Pod 中的全部容器使用同一个网络 namespace，即相同的 IP 地址和 Port 空间。它们能够直接用 localhost 通讯。一样的，这些容器能够共享存储，当 Kubernetes 挂载 volume 到 Pod，本质上是将 volume 挂载到 Pod 中的每个容器。

Pods 有两种使用方式：

运行单一容器。

one-container-per-Pod 是 Kubernetes 最多见的模型，这种状况下，只是将单个容器简单封装成 Pod。即使是只有一个容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。
运行多个容器。

但问题在于：哪些容器应该放到一个 Pod 中？

答案是：这些容器联系必须很是紧密，并且须要直接共享资源。

举个例子。

下面这个 Pod 包含两个容器：一个 File Puller，一个是 Web Server。

File Puller 会按期从外部的 Content Manager 中拉取最新的文件，将其存放在共享的 volume 中。Web Server 从 volume 读取文件，响应 Consumer 的请求。

这两个容器是紧密协做的，它们一块儿为 Consumer 提供最新的数据；同时它们也经过 volume 共享数据。因此放到一个 Pod 是合适的。

再来看一个反例：是否须要将 Tomcat 和 MySQL 放到一个 Pod 中？

Tomcat 从 MySQL 读取数据，它们之间须要协做，但还不至于须要放到一个 Pod 中一块儿部署，一块儿启动，一块儿中止。同时它们是之间经过 JDBC 交换数据，并非直接共享存储，因此放到各自的 Pod 中更合适。

Controller

Kubernetes 一般不会直接建立 Pod，而是经过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，好比有几个副本，在什么样的 Node 上运行等。为了知足不一样的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，咱们逐一讨论。

Deployment 是最经常使用的 Controller，好比前面在线教程中就是经过建立 Deployment 来部署应用的。Deployment 能够管理 Pod 的多个副本，并确保 Pod 按照指望的状态运行。

ReplicaSet 实现了 Pod 的多副本管理。使用 Deployment 时会自动建立 ReplicaSet，也就是说 Deployment 是经过 ReplicaSet 来管理 Pod 的多个副本，咱们一般不须要直接使用 ReplicaSet。

DaemonSet 用于每一个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的，DaemonSet 一般用于运行 daemon。

StatefuleSet 可以保证 Pod 的每一个副本在整个生命周期中名称是不变的。而其余 Controller 不提供这个功能，当某个 Pod 发生故障须要删除并从新启动时，Pod 的名称会发生变化。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。

Job 用于运行结束就删除的应用。而其余 Controller 中的 Pod 一般是长期持续运行。

Service

Deployment 能够部署多个副本，每一个 Pod 都有本身的 IP，外界如何访问这些副本呢？

经过 Pod 的 IP 吗？

要知道 Pod 极可能会被频繁地销毁和重启，它们的 IP 会发生变化，用 IP 来访问不太现实。

答案是 Service。

Kubernetes Service 定义了外界访问一组特定 Pod 的方式。Service 有本身的 IP 和端口，Service 为 Pod 提供了负载均衡。

Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。

Namespace

若是有多个用户或项目组使用同一个 Kubernetes Cluster，如何将他们建立的 Controller、Pod 等资源分开呢？

答案就是 Namespace。

Namespace 能够将一个物理的 Cluster 逻辑上划分红多个虚拟 Cluster，每一个 Cluster 就是一个 Namespace。不一样 Namespace 里的资源是彻底隔离的。

Kubernetes 默认建立了三个 Namespace。 default -- 建立资源时若是不指定，将被放到这个 Namespace 中。 kube-system -- Kubernetes 本身建立的系统资源将放到这个 Namespace 中。 kube-public -- Kubernetes 公共的系统资源将放到这个 Namespace 中。