Master01 192.168.121.12
Node01 192.168.121.13
Node03 192.168.121.17
cd /opt/k8s/
unzip master.zip
apiserver.sh
scheduler.sh
controller-manager.sh
chmod +x *.sh
mkdir -p /opt/kubernetes/{cfg,bin,ssl}
mkdir /opt/k8s/k8s-cert
mv /opt/k8s/k8s-cert.sh /opt/k8s/k8s-cert
cd /opt/k8s/k8s-cert/
vim k8s-cert.sh
chmod +x k8s-cert.sh
./k8s-cert.sh #生成CA证书、相关组件的证书和私钥
ls *pem
admin-key.pem apiserver-key.pem ca-key.pem kube-proxy-key.pem
admin.pem apiserver.pem ca.pem kube-proxy.pem
//controller-manager 和 kube-scheduler 设置为只调用当前机器的 apiserver，使用 127.0.0.1:8080 通信，因此不需要签发证书
cp ca*pem apiserver*pem /opt/kubernetes/ssl/
//上传 kubernetes-server-linux-amd64.tar.gz 到 /opt/k8s/ 目录中，解压 kubernetes 压缩包
cd /opt/k8s/
tar zxvf kubernetes-server-linux-amd64.tar.gz
cd /opt/k8s/kubernetes/server/bin
cp kube-apiserver kubectl kube-controller-manager kube-scheduler /opt/kubernetes/bin/
ln -s /opt/kubernetes/bin/* /usr/local/bin/
apiserver 启动时会调用，然后就相当于在集群内创建了一个这个用户，接下来就可以用 RBAC 给他授权
cd /opt/k8s/
vim token.sh
#!/bin/bash
#获取随机数前16个字节内容，以十六进制格式输出，并删除其中空格
BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')
#生成 token.csv 文件，按照 Token序列号,用户名,UID,用户组 的格式生成
cat > /opt/kubernetes/cfg/token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF
chmod +x token.sh
./token.sh
cat /opt/kubernetes/cfg/token.csv
cd /opt/k8s/
./apiserver.sh 192.168.121.12 https://192.168.121.12:2379,https://192.168.121.13:2379,https://192.168.121.17:2379
ps aux | grep kube-apiserver
//k8s通过kube-apiserver这个进程提供服务，该进程运行在单个master节点上。默认有两个端口6443和8080
//安全端口6443用于接收HTTPS请求，用于基于Token文件或客户端证书等认证
netstat -natp | grep 6443
//本地端口8080用于接收HTTP请求，非认证或授权的HTTP请求通过该端口访问API Server
netstat -natp | grep 8080
必须保证apiserver启动正常，不然无法查询到server的版本信息
kubectl version
cd /opt/k8s/
./scheduler.sh 127.0.0.1
ps aux | grep kube-scheduler
//启动 controller-manager 服务
cd /opt/k8s/
./controller-manager.sh 127.0.0.1
kubectl get componentstatuses #也可以 kubectl get cs
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-2 Healthy {"health":"true"}
etcd-1 Healthy {"health":"true"}
etcd-0 Healthy {"health":"true"}
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root@192.168.121.13:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.121.17:/opt/kubernetes/bin/
cd /opt/
unzip node.zip
mkdir /opt/k8s/kubeconfig
kubeconfig.sh 文件包含集群参数（CA 证书、API Server 地址），客户端参数（上面生成的证书和私钥），集群 context 上下文参数（集群名称、用户名）。Kubenetes 组件（如 kubelet、kube-proxy）通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群，连接到 apiserver。
cd /opt/k8s/kubeconfig
rz -E
chmod +x kubeconfig.sh
cd /opt/k8s/kubeconfig
./kubeconfig.sh 192.168.121.12 /opt/k8s/k8s-cert/
ls
bootstrap.kubeconfig kubeconfig.sh kube-proxy.kubeconfig
cd /opt/k8s/kubeconfig
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.121.13:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.121.17:/opt/kubernetes/cfg/
将预设用户 kubelet-bootstrap 与内置的 ClusterRole system:node-bootstrapper 绑定到一起，使其能够发起 CSR 请求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
------------------------------------------------------------------------------------------
kubelet 采用 TLS Bootstrapping 机制，自动完成到 kube-apiserver 的注册，在 node 节点量较大或者后期自动扩容时非常有用。
Master apiserver 启用 TLS 认证后，node 节点 kubelet 组件想要加入集群，必须使用CA签发的有效证书才能与 apiserver 通信，当 node 节点很多时，签署证书是一件很繁琐的事情。因此 Kubernetes 引入了 TLS bootstraping 机制来自动颁发客户端证书，kubelet 会以一个低权限用户自动向 apiserver 申请证书，kubelet 的证书由 apiserver 动态签署。
kubelet 首次启动通过加载 bootstrap.kubeconfig 中的用户 Token 和 apiserver CA 证书发起首次 CSR 请求，这个 Token 被预先内置在 apiserver 节点的 token.csv 中，其身份为 kubelet-bootstrap 用户和 system:kubelet-bootstrap 用户组；想要首次 CSR 请求能成功（即不会被 apiserver 401 拒绝），则需要先创建一个 ClusterRoleBinding，将 kubelet-bootstrap 用户和 system:node-bootstrapper 内置 ClusterRole 绑定（通过 kubectl get clusterroles 可查询），使其能够发起 CSR 认证请求。
TLS bootstrapping 时的证书实际是由 kube-controller-manager 组件来签署的，也就是说证书有效期是 kube-controller-manager 组件控制的；kube-controller-manager 组件提供了一个 --experimental-cluster-signing-duration 参数来设置签署的证书有效时间；默认为 8760h0m0s，将其改为 87600h0m0s，即 10 年后再进行 TLS bootstrapping 签署证书即可。
也就是说 kubelet 首次访问 API Server 时，是使用 token 做认证，通过后，Controller Manager 会为 kubelet 生成一个证书，以后的访问都是用证书做认证了。
------------------------------------------------------------------------------------------
kubectl get clusterroles | grep system:node-bootstrapper
kubectl get clusterrolebinding
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.121.13
ps aux | grep kubelet
ls /opt/kubernetes/ssl/
kubectl get csr
kubectl certificate approve node-csr-NOI-9vufTLIqJgMWq4fHPNPHKbjCXlDGHptj7FqTa8A
Approved,Issued 表示已授权 CSR 请求并签发证书
kubectl get csr
kubectl get nodes
ls /opt/kubernetes/cfg/kubelet.kubeconfig
ls /opt/kubernetes/ssl/
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
cd /opt/
chmod +x proxy.sh
./proxy.sh 192.168.121.13
systemctl status kube-proxy.service
//在 node01 节点上将 kubelet.sh、proxy.sh 文件拷贝到 node02 节点
cd /opt/
scp kubelet.sh proxy.sh root@192.168.121.17:/opt/
##### 在 node02 节点上操作 #####
//使用kubelet.sh脚本启动kubelet服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.121.17
##### 在 master01 节点上操作 #####
//在 master01 节点上操作查看 CSR 请求
kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-OaH9HpIKh6AKlfdjEKm4C6aJ0UT_1YxNaa70yEAxnsU 15s kubelet-bootstrap Pending
//通过 CSR 请求
kubectl certificate approve node-csr-OaH9HpIKh6AKlfdjEKm4C6aJ0UT_1YxNaa70yEAxnsU
kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-OaH9HpIKh6AKlfdjEKm4C6aJ0UT_1YxNaa70yEAxnsU 2m kubelet-bootstrap Approved,Issued
//查看群集中的节点状态
kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.121.13 Ready
192.168.121.17 Ready
//加载 ipvs 模块
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
//使用proxy.sh脚本启动proxy服务
cd /opt/
chmod +x proxy.sh
./proxy.sh 192.168.121.17
systemctl status kube-proxy.service
//在node01节点操作，把现成的/opt/kubernetes目录和kubelet、kube-proxy的service服务管理文件复制到其他node节点
scp -r /opt/kubernetes/ root@192.168.121.17:/opt/
scp /usr/lib/systemd/system/{kubelet,kube-proxy}.service root@192.168.121.17:/usr/lib/systemd/system/
//在node02节点上操作，进行修改
//首先删除复制过来的证书，等会node02会自行申请证书
cd /opt/kubernetes/ssl/
rm -rf *
//修改配置文件kubelet、kubelet.config、kube-proxy的相关IP地址配置为当前节点的IP地址
cd /opt/kubernetes/cfg
vim kubelet
KUBELET_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.121.17 \ #修改
......
vim kubelet.config
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: 192.168.121.17 #修改
vim kube-proxy
KUBE_PROXY_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.121.17 \ #修改
//加载 ipvs 模块
modprobe ip_vs
//启动kubelet和kube-proxy服务并设置开机自启
systemctl start kubelet.service
systemctl enable kubelet.service
systemctl start kube-proxy.service
systemctl enable kube-proxy.service
//到master01节点上发现未授权的node02请求，授权node02加入集群
kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-P3996HQxx_2PLeo9bxBu7TVPcWgbAWqla5yj8Wa_5ks 15s kubelet-bootstrap Pending
//授权许可加入群集
kubectl certificate approve node-csr-P3996HQxx_2PLeo9bxBu7TVPcWgbAWqla5yj8Wa_5ks
kubectl get csr
kubectl get nodes
master01 192.168.121.12
master02 192.168.121.18
VIP 192.168.121.100
LB01 192.168.121.19
LB02 192.168.121.20
scp -r /opt/etcd/ root@192.168.121.18:/opt/
scp -r /opt/kubernetes/ root@192.168.121.18:/opt
scp /usr/lib/systemd/system/{kube-apiserver,kube-controller-manager,kube-scheduler}.service root@192.168.121.18:/usr/lib/systemd/system/
vim /opt/kubernetes/cfg/kube-apiserver
KUBE_APISERVER_OPTS="--logtostderr=true \
--v=4 \
--etcd-servers=https://192.168.80.10:2379,https://192.168.80.11:2379,https://192.168.80.12:2379 \
--bind-address=192.168.121.18 \ #修改
--secure-port=6443 \
--advertise-address=192.168.121.18 \ #修改
......
systemctl start kube-apiserver.service
systemctl enable kube-apiserver.service
systemctl start kube-controller-manager.service
systemctl enable kube-controller-manager.service
systemctl start kube-scheduler.service
systemctl enable kube-scheduler.service
ln -s /opt/kubernetes/bin/* /usr/local/bin/
kubectl get nodes
kubectl get nodes -o wide #-o=wide：输出额外信息；对于Pod，将输出Pod所在的Node名
//此时在master02节点查到的node节点状态仅是从etcd查询到的信息，而此时node节点实际上并未与master02节点建立通信连接，因此需要使用一个VIP把node节点与master节点都关联起来
配置load balancer集群双机热备负载均衡（nginx实现负载均衡，keepalived实现双机热备）
cat > /etc/yum.repos.d/nginx.repo << 'EOF'
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
EOF
yum install nginx -y
指定k8s群集2台master的节点ip和6443端口
vim /etc/nginx/nginx.conf
events {
worker_connections 1024;
}
#添加
stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent';
access_log /var/log/nginx/k8s-access.log main;
upstream k8s-apiserver {
server 192.168.121.19:6443;
server 192.168.121.20:6443;
}
server {
listen 6443;
proxy_pass k8s-apiserver;
}
}
http {
......
//检查配置文件语法
nginx -t
//启动nginx服务，查看已监听6443端口
systemctl start nginx
systemctl enable nginx
netstat -natp | grep nginx
yum install keepalived -y
vim /etc/keepalived/keepalived.conf
vim /etc/nginx/check_nginx.sh
#!/bin/bash
#egrep -cv "grep|$$" 用于过滤掉包含grep 或者 $$ 表示的当前Shell进程ID
count=$(ps -ef | grep nginx | egrep -cv "grep|$$")
if [ "$count" -eq 0 ];then
systemctl stop keepalived
fi
chmod +x /etc/nginx/check_nginx.sh
systemctl start keepalived
systemctl enable keepalived
ip a #查看VIP是否生成
cd /opt/kubernetes/cfg/
vim bootstrap.kubeconfig
server: https://192.168.80.100:6443
vim kubelet.kubeconfig
server: https://192.168.80.100:6443
vim kube-proxy.kubeconfig
server: https://192.168.80.100:6443
systemctl restart kubelet.service
systemctl restart kube-proxy.service
tail /var/log/nginx/k8s-access.log
//测试创建pod
kubectl run nginx --image=nginx
//查看Pod的状态信息
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-dbddb74b8-nf9sk 0/1 ContainerCreating 0 33s #正在创建中
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-dbddb74b8-nf9sk 1/1 Running 0 80s #创建完成，运行中
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-dbddb74b8-26r9l 1/1 Running 0 10m 172.17.36.2 192.168.80.15 <none>
//READY为1/1，表示这个Pod中有1个容器
//在对应网段的node节点上操作，可以直接使用浏览器或者curl命令访问
curl 172.17.36.2
//这时在master01节点上查看nginx日志，发现没有权限查看
kubectl logs nginx-dbddb74b8-nf9sk
Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( nginx-dbddb74b8-nf9sk)
//在master01节点上，将cluster-admin角色授予用户system:anonymous
kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous
clusterrolebinding.rbac.authorization.k8s.io/cluster-system-anonymous created
//再次查看nginx日志
kubectl logs nginx-dbddb74b8-nf9sk
仪表板是基于Web的Kubernetes用户界面。您可以使用仪表板将容器化应用程序部署到Kubernetes集群，对容器化应用程序进行故障排除，并管理集群本身及其伴随资源。您可以使用仪表板来概述群集上运行的应用程序，以及创建或修改单个Kubernetes资源（例如部署，作业，守护进程等）。例如，您可以使用部署向导扩展部署，启动滚动更新，重新启动Pod或部署新应用程序。仪表板还提供有关群集中Kubernetes资源状态以及可能发生的任何错误的信息。
mkdir /opt/k8s/dashboard
cd /opt/k8s/dashboard
//上传Dashboard.zip压缩包，并解压，一共有7个yaml文件，包含5个构建该界面的核心文件，一个k8s-admin.yaml文件是自己写的，用来生成待会在浏览器中登录时所用的令牌；一个dashboard-cert.sh，用来快速生成解决谷歌浏览器加密通信问题所需的证书文件
https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dashboard
dashboard-configmap.yaml dashboard-rbac.yaml dashboard-service.yaml dashboard-controller.yaml dashboard-secret.yaml k8s-admin.yaml dashboard-cert.sh
------------------------------------------------------------------------------------------
1、dashboard-rbac.yaml：用于访问控制设置，配置各种角色的访问控制权限及角色绑定（绑定角色和服务账户），内容中包含对应各种角色所配置的规则（rules）
2、dashboard-secret.yaml：提供令牌，访问API服务器所用（个人理解为一种安全认证机制）
3、dashboard-configmap.yaml：配置模板文件，负责设置Dashboard的文件，ConfigMap提供了将配置数据注入容器的方式，保证容器中的应用程序配置从 Image 内容中解耦
4、dashboard-controller.yaml：负责控制器及服务账户的创建，来管理pod副本
5、dashboard-service.yaml：负责将容器中的服务提供出去，供外部访问
cd /opt/k8s/dashboard
1、规定kubernetes-dashboard-minimal该角色的权限：例如其中具备获取更新删除等不同的权限
kubectl create -f dashboard-rbac.yaml
//有几个kind就会有几个结果被创建，格式为kind+apiServer/name
role.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
kubectl get role,rolebinding -n kube-system
//-n kube-system 表示查看指定命名空间中的pod，缺省值为default
kubectl create -f dashboard-secret.yaml
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-key-holder created
kubectl get secret -n kube-system
kubectl create -f dashboard-controller.yaml
serviceaccount/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
kubectl get serviceaccount,deployment -n kube-system
kubectl create -f dashboard-service.yaml
service/kubernetes-dashboard created
kubectl get pods,svc -n kube-system -o wide
//svc 为 service 的缩写，可用 kubectl api-resources 查看
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
pod/kubernetes-dashboard-7dffbccd68-c6d24 1/1 Running 1 11m 172.17.26.2 192.168.80.11 <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes-dashboard NodePort 10.0.0.75 <none> 443:30001/TCP 11m k8s-app=kubernetes-dashboard
//dashboard分配给了node01服务器，访问的入口是30001端口，打开浏览器访问 https://nodeIP:30001 来进行测试
火狐浏览器可直接访问：https://192.168.80.11:30001
谷歌浏览器则因为缺少加密通信的认证证书，导致无法直接访问。可通过 菜单->更多工具->开发者工具->Security 查看访问失败的原因。
//解决谷歌浏览器加密通信问题，使用的脚本 dashboard-cert.sh 来快速生成证书文件
cd /opt/k8s/dashboard/
vim dashboard-controller.yaml
......
args:
# PLATFORM-SPECIFIC ARGS HERE
- --auto-generate-certificates
#在文件的第47行下面添加以下两行，指定加密（tls）的私钥和证书文件
- --tls-key-file=dashboard-key.pem
- --tls-cert-file=dashboard.pem
cd /opt/k8s/dashboard/
chmod +x dashboard-cert.sh
./dashboard-cert.sh /opt/k8s/k8s-cert/
ls *.pem
dashboard.pem dashboard-key.pem
kubectl apply -f dashboard-controller.yaml
kubectl get pods,svc -n kube-system -o wide
cd /opt/k8s/dashboard/
kubectl create -f k8s-admin.yaml
#获取token简要信息，名称为dashboard-admin-token-xxxxx
kubectl get secrets -n kube-system
NAME TYPE DATA AGE
dashboard-admin-token-kpmm8 kubernetes.io/service-account-token 3
default-token-7dhwm kubernetes.io/service-account-token 3
kubernetes-dashboard-certs Opaque 11
kubernetes-dashboard-key-holder Opaque 2
kubernetes-dashboard-token-jn94c kubernetes.io/service-account-token 3
kubectl describe secrets dashboard-admin-token-kpmm8 -n kube-system
先通过 kubectl get pods 命令查看一下集群中是否有资源在运行，再在 Dashboard UI 界面中命令空间选 default，
点击侧边栏中的“容器组”，点击容器名称，进入一个页面，点击右上方的“运行命令”或”日志“控件会弹出另一个额外页面，可在“运行命令”输入 curl <podip> 命令访问容器，再通过dashboard页面查看日志更新结果。