主要参考

(https://github.com/liuyi01/kubernetes-starter/blob/master/docs/3-kubernetes-with-ca.md)

(https://github.com/gjmzj/kubeasz)

[一、预先准备环境 ]
(https://github.com/liuyi01/kubernetes-starter/tree/master/docs/1-pre.md)

规划

192.168.188.30 test30 master etcd Controller

192.168.188.31 test31 worker

192.168.188.32 test32 worker

#######

系统版本

如果是CentOS7,建议7.3以上版本;

Docker版本:

readme中已有说明,

主机名:

如果是克隆的系统一定要修改主机名,hostname主机名必须不同!

主机文件:

/etc/hosts要配置正确,一定要有127.0.0.1 localhost
这一项。Hosts文件中包含所有主机节点的IP和名称列表。使用vi进行编辑,不能使用中文全角的空格;

192.168.188.30 test30

192.168.188.31 test31

192.168.188.32 test32

IPV4转发:

CentOS7 下可编辑配置文件/etc/sysctl.conf,设置启用转发,

net.ipv4.ip_forward = 1

net.bridge.bridge-nf-call-ip6tables = 1

net.bridge.bridge-nf-call-iptables = 1

执行sysctl -p 立刻生效。

关闭防火墙/SELinux

禁用SWAP:

swapoff -a

sed -i \’s/.*swap.*/#&/\’ /etc/fstab

SSH免密登录:这里举例root用户--过程略

要将普通用户(如docker)加入到docker组,

命令:usermod -aG docker docker

注意:重启系统以后才能生效,只重启Docker服务是不行的!

准备二进制文件(所有节点)

下载 https://pan.baidu.com/s/1c4RFaA

kubernetes二进制文件目录cd /opt tar zxvf k8s.1-10-4.tar.gz mv /opt/bin
/opt/k8s-bin

chmod -R 755 /opt/k8s-bin

放好后最好设置一下环境变量\$PATH,方便后面可以直接使用命令。

cat>>/etc/profile\<\< EOF

PATH=\\$PATH:/opt/k8s-bin

EOF

source /etc/profile

准备配置文件(所有节点)

我用了tmux的批量同步操作

开启 tmux 同步的方法:

ctrl+b 以后输入 : set synchronize-panes on

########################

上一步我们下载了kubernetes各个组件的二进制文件,这些可执行文件的运行也是需要添加很多参数的,包括有的还会依赖一些配置文件。现在我们就把运行它们需要的参数和配置文件都准备好。

下载配置文件

cd /opt && git clone https://github.com/liuyi01/kubernetes-starter.git

cd kubernetes-starter && ll

----------------------------------------------

文件说明

gen-config.sh

shell脚本,用来根据每个同学自己的集群环境(ip,hostname等),根据下面的模板,生成适合大家各自环境的配置文件。生成的文件会放到target文件夹下。

kubernetes-simple

简易版kubernetes配置模板(剥离了认证授权)。

适合刚接触kubernetes的同学,首先会让大家在和kubernetes初次见面不会印象太差(太复杂啦~~),再有就是让大家更容易抓住kubernetes的核心部分,把注意力集中到核心组件及组件的联系,从整体上把握kubernetes的运行机制。

kubernetes-with-ca

在simple基础上增加认证授权部分。大家可以自行对比生成的配置文件,看看跟simple版的差异,更容易理解认证授权的(认证授权也是kubernetes学习曲线较高的重要原因)

service-config

这个先不用关注,它是我们曾经开发的那些微服务配置。

等我们熟悉了kubernetes后,实践用的,通过这些配置,把我们的微服务都运行到kubernetes集群中。

===================================

生成配置

这里会根据大家各自的环境生成kubernetes部署过程需要的配置文件。

在每个节点上都生成一遍,把所有配置都生成好,后面会根据节点类型去使用相关的配置。

#cd到之前下载的git代码目录

\$ cd kubernetes-starter

#编辑属性配置(根据文件注释中的说明填写好每个key-value)

\$ vi config.properties

-------------------------------------

#kubernetes二进制文件目录,eg: /home/michael/bin

BIN_PATH=/opt/k8s-bin

#当前节点ip, eg: 192.168.1.102 --------各个节点的NODE_IP不一样

NODE_IP=192.168.188.31

#etcd服务集群列表, eg: http://192.168.1.102:2379

#如果已有etcd集群可以填写现有的。没有的话填写:http://\${MASTER\_IP}:2379
(MASTER_IP自行替换成自己的主节点ip)

##如果用了证书,就填写:https:// ---注意这个小细节 作者没有写

ETCD_ENDPOINTS=https://192.168.188.30:2379

#kubernetes主节点ip地址, eg: 192.168.1.102

MASTER_IP=192.168.188.30

----------------------------------------------------------------------------

cat \<\< EOF >/opt/kubernetes-starter/config.properties

BIN_PATH=/opt/k8s-bin

NODE_IP=192.168.188.30

ETCD_ENDPOINTS=http://192.168.188.30:2379

MASTER_IP=192.168.188.30

EOF

#########################

#生成配置文件

#./gen-config.sh with-ca

#查看生成的配置文件,

\$ find target/ -type f

二、基础集群部署

安装cfssl(所有节点)

cfssl是非常好用的CA工具,我们用它来生成证书和秘钥文件

安装过程比较简单,如下:

#下载

cd /opt wget -q --timestamping \
https://pkg.cfssl.org/R1.2/cfssl\_linux-amd64 \
https://pkg.cfssl.org/R1.2/cfssljson\_linux-amd64 \

#修改为可执行权限
chmod +x cfssl_linux-amd64 cfssljson_linux-amd64

#移动到bin目录

mv
cfssl_linux-amd64 /usr/local/bin/cfssl mv cfssljson_linux-amd64
/usr/local/bin/cfssljson

#验证 cfssl version

生成根证书(主节点)

根证书是证书信任链的根,各个组件通讯的前提是有一份大家都信任的证书(根证书),每个人使用的证书都是由这个根证书签发的。

#所有证书相关的东西都放在这

mkdir -p /etc/kubernetes/ca

#准备生成证书的配置文件

cp /opt/kubernetes-starter/target/ca/ca-config.json /etc/kubernetes/ca

cp /opt/kubernetes-starter/target/ca/ca-csr.json /etc/kubernetes/ca

#生成证书和秘钥

cd /etc/kubernetes/ca cfssl gencert -initca ca-csr.json
| cfssljson -bare ca

#生成完成后会有以下文件(我们最终想要的就是ca-key.pem和ca.pem,一个秘钥,一个证书)

1. 部署ETCD(主节点)

  kubernetes需要存储很多东西,像它本身的节点信息,组件信息,还有通过kubernetes运行的pod,deployment,service等等。都需要持久化。etcd就是它的数据中心。生产环境中为了保证数据中心的高可用和数据的一致性,一般会部署最少三个节点。我们这里以学习为主就只在主节点部署一个实例

准备证书

etcd节点需要提供给其他服务访问,就要验证其他服务的身份,所以需要一个标识自己监听服务的server证书,当有多个etcd节点的时候也需要client证书与etcd集群其他节点交互,当然也可以client和server使用同一个证书因为它们本质上没有区别。

#etcd证书放在这
mkdir -p /etc/kubernetes/ca/etcd

#准备etcd证书配置

cp /opt/kubernetes-starter/target/ca/etcd/etcd-csr.json
/etc/kubernetes/ca/etcd/

cd /etc/kubernetes/ca/etcd/

#使用根证书(ca.pem)签发etcd证书

cfssl gencert -ca=/etc/kubernetes/ca/ca.pem
-ca-key=/etc/kubernetes/ca/ca-key.pem -config=/etc/kubernetes/ca/ca-config.json -profile=kubernetes
etcd-csr.json | cfssljson -bare etcd

#跟之前类似生成三个文件etcd.csr是个中间证书请求文件,我们最终要的是etcd-key.pem和etcd.pem

部署

etcd的二进制文件和服务的配置我们都已经准备好,现在的目的就是把它做成系统服务并启动。

#把服务配置文件copy到系统服务目录

cp
/opt/kubernetes-starter/target/master-node/etcd.service
/lib/systemd/system/

systemctl daemon-reload

systemctl enable etcd.service

#创建工作目录(保存数据的地方)

mkdir -p /var/lib/etcd

# 启动服务

systemctl start etcd

ps -ef |grep etcd

#验证etcd服务(endpoints自行替换)

#ETCDCTL_API=3 etcdctl \
--endpoints=https://192.168.188.30:2379 \
--cacert=/etc/kubernetes/ca/ca.pem \
--cert=/etc/kubernetes/ca/etcd/etcd.pem \
--key=/etc/kubernetes/ca/etcd/etcd-key.pem \ endpoint health

# 查看服务日志,看是否有错误信息,确保服务正常

#journalctl -f -u etcd.service

##################################################

2. 部署APIServer(主节点)

简介

kube-apiserver是Kubernetes最重要的核心组件之一,主要提供以下的功能

提供集群管理的REST
API接口,包括认证授权(我们现在没有用到)数据校验以及集群状态变更等

提供其他模块之间的数据交互和通信的枢纽(其他模块通过API
Server查询或修改数据,只有API Server才直接操作etcd)

生产环境为了保证apiserver的高可用一般会部署2+个节点,在上层做一个lb做负载均衡,比如haproxy。由于单节点和多节点在apiserver这一层说来没什么区别,所以我们学习部署一个节点就足够啦

准备证书

#api-server证书放在这,api-server是核心,文件夹叫kubernetes吧,

如果想叫apiserver也可以,不过相关的地方都需要修改哦

mkdir -p
/etc/kubernetes/ca/kubernetes

#准备apiserver证书配置

cp
/opt/kubernetes-starter/target/ca/kubernetes/kubernetes-csr.json
/etc/kubernetes/ca/kubernetes/

cd /etc/kubernetes/ca/kubernetes/

#使用根证书(ca.pem)签发kubernetes证书

cfssl gencert \ -ca=/etc/kubernetes/ca/ca.pem \
-ca-key=/etc/kubernetes/ca/ca-key.pem \
-config=/etc/kubernetes/ca/ca-config.json \ -profile=kubernetes
kubernetes-csr.json | cfssljson -bare kubernetes

#跟之前类似生成三个文件kubernetes.csr是个中间证书请求文件,我们最终要的是kubernetes-key.pem和kubernetes.pem

生成token认证文件

生成随机

token \$ head -c 16 /dev/urandom | od -An -t x | tr -d \’ \’
44ec8a4eb808af51d1f470f2fde0e082

#按照固定格式写入token.csv,注意替换token内容

\$ echo
\”44ec8a4eb808af51d1f470f2fde0e082,kubelet-bootstrap,10001,\\”system:kubelet-bootstrap\\”\”
> /etc/kubernetes/ca/kubernetes/token.csv

部署

cp /opt/kubernetes-starter/target/master-node/kube-apiserver.service
/lib/systemd/system/

注意要再次修改

vi /lib/systemd/system/kube-apiserver.service

--etcd-servers=http

要改为--etcd-servers=https

增加 --anonymous-auth=false \

# 关闭匿名认证,若为true,则表示接受,此处设置为false

##启用基本密码认证

--basic-auth-file=/etc/kubernetes/basic_auth_file \

{width=”5.760416666666667in”
height=”1.3392049431321085in”}

#############################可选

新建/etc/kubernetes/basic_auth_file文件,并在其中添加:

admin,admin,1

readonly,readonly,2

[密码文件模板]中按照每行(密码,用户名,序号)的格式,可以定义多个用户

务必保管好密码文件

####################################

systemctl daemon-reload

systemctl enable kube-apiserver.service

systemctl start kube-apiserver

ps -ef |grep kube-apiserver ###### journalctl -f -u
kube-apiserver

##############################

3. 部署ControllerManager(主节点)

3.1 简介

Controller
Manager由kube-controller-manager和cloud-controller-manager组成,是Kubernetes的大脑,它通过apiserver监控整个集群的状态,并确保集群处于预期的工作状态。

kube-controller-manager由一系列的控制器组成,像Replication
Controller控制副本,Node Controller节点控制,Deployment
Controller管理deployment等等
cloud-controller-manager在Kubernetes启用Cloud
Provider的时候才需要,用来配合云服务提供商的控制

controller-manager、scheduler和apiserver
三者的功能紧密相关,一般运行在同一个机器上,我们可以把它们当做一个整体来看,所以保证了apiserver的高可用即是保证了三个模块的高可用。也可以同时启动多个controller-manager进程,但只有一个会被选举为leader提供服务。

######################################

controller-manager一般与api-server在同一台机器上,所以可以使用非安全端口与api-server通讯,不需要生成证书和私钥。

部署

通过系统服务方式部署

cp
/opt/kubernetes-starter/target/master-node/kube-controller-manager.service
/lib/systemd/system/

systemctl daemon-reload systemctl enable kube-controller-manager.service

systemctl start kube-controller-manager ###journalctl -f -u
kube-controller-manager

4. 部署Scheduler(主节点)

4.1 简介

kube-scheduler负责分配调度Pod到集群内的节点上,它监听kube-apiserver,查询还未分配Node的Pod,然后根据调度策略为这些Pod分配节点。我们前面讲到的kubernetes的各种调度策略就是它实现的。

scheduler一般与apiserver在同一台机器上,所以可以使用非安全端口与apiserver通讯。不需要生成证书和私钥。

部署

通过系统服务方式部署

cp /opt/kubernetes-starter/target/master-node/kube-scheduler.service
/lib/systemd/system/

systemctl enable kube-scheduler.service

systemctl
start kube-scheduler.service

########### journalctl -f -u kube-scheduler

5.配置kubectl命令(主节点)

简介

kubectl是Kubernetes的命令行工具,是Kubernetes用户和管理员必备的管理工具。
kubectl提供了大量的子命令,方便管理Kubernetes集群中的各种功能。

准备证书

#kubectl证书放在这,由于kubectl相当于系统管理员,我们使用admin命名

mkdir -p /etc/kubernetes/ca/admin

#准备admin证书配置 -
kubectl只需客户端证书,因此证书请求中 hosts 字段可以为空

cp
/opt/kubernetes-starter/target/ca/admin/admin-csr.json
/etc/kubernetes/ca/admin/ cd /etc/kubernetes/ca/admin/

#使用根证书(ca.pem)签发admin证书

cfssl gencert -ca=/etc/kubernetes/ca/ca.pem -ca-key=/etc/kubernetes/ca/ca-key.pem
-config=/etc/kubernetes/ca/ca-config.json -profile=kubernetes
admin-csr.json | cfssljson -bare admin

#我们最终要的是admin-key.pem和admin.pem

配置kubectl

#指定apiserver的地址和证书位置(ip替换为主节点的api-server地址)

\$
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ca/ca.pem \
--embed-certs=true \ --server=https://192.168.188.30:6443

#设置客户端认证参数,指定admin证书和秘钥

\$ kubectl config
set-credentials admin \
--client-certificate=/etc/kubernetes/ca/admin/admin.pem \
--embed-certs=true \
--client-key=/etc/kubernetes/ca/admin/admin-key.pem

#关联用户和集群

\$
kubectl config set-context kubernetes \ --cluster=kubernetes
--user=admin

#设置当前上下文

\$ kubectl config use-context kubernetes

#设置结果就是一个配置文件,可以看看内容

\$ cat /root/.kube/config

通过上面的设置最终目的是生成了一个配置文件:/root/.kube/config,当然你也可以手写或复制一个文件放在那,就不需要上面的命令了。

验证master节点

#可以使用刚配置好的kubectl查看一下组件状态

\$ kubectl get cs NAME
STATUS MESSAGE ERROR scheduler Healthy ok controller-manager Healthy ok
etcd-0 Healthy {\”health\”: \”true\”}

6. 部署CalicoNode(所有节点)

简介

Calico实现了CNI接口,是kubernetes网络方案的一种选择,它一个纯三层的数据中心网络方案(不需要Overlay),并且与OpenStack、Kubernetes、AWS、GCE等IaaS和容器平台都有良好的集成。
Calico在每一个计算节点利用Linux
Kernel实现了一个高效的vRouter来负责数据转发,而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联,大规模下可通过指定的BGP
route reflector来完成。
这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。

#############

准备证书--- 在主节点上

后续可以看到calico证书用在四个地方:

calico/node 这个docker 容器运行时访问 etcd 使用证书

cni 配置文件中,cni 插件需要访问 etcd 使用证书

calicoctl 操作集群网络时访问 etcd 使用证书

calico/kube-controllers 同步集群网络策略时访问 etcd 使用证书

#calico证书放在这

mkdir -p /etc/kubernetes/ca/calico

#准备calico证书配置 - calico只需客户端证书,因此证书请求中 hosts
字段可以为空

cp /opt/kubernetes-starter/target/ca/calico/calico-csr.json
/etc/kubernetes/ca/calico/

cd /etc/kubernetes/ca/calico/

#使用根证书(ca.pem)签发calico证书

cfssl gencert \
-ca=/etc/kubernetes/ca/ca.pem \ -ca-key=/etc/kubernetes/ca/ca-key.pem
\ -config=/etc/kubernetes/ca/ca-config.json \ -profile=kubernetes
calico-csr.json | cfssljson -bare calico

#我们最终要的是calico-key.pem和calico.pem

由于calico服务是所有节点都需要启动的,
需要把这几个文件拷贝到每台服务器上

在主节点上执行:

scp -r /etc/kubernetes/ca root\@其他节点ip:/etc/kubernetes/

scp -r /etc/kubernetes/ca root\@192.168.188.31:/etc/kubernetes/

scp -r /etc/kubernetes/ca root\@192.168.188.32:/etc/kubernetes/

部署(所有节点)

calico是通过系统服务+docker方式完成的

docker pull registry.cn-hangzhou.aliyuncs.com/imooc/calico-node:v2.6.2

cp /opt/kubernetes-starter/target/all-node/kube-calico.service
/lib/systemd/system/

systemctl daemon-reload

systemctl enable kube-calico.service

systemctl start kube-calico.service

#### journalctl -f -u kube-calico

calico可用性验证

查看容器运行情况

\$ docker ps

查看节点运行情况 (能看到其他节点的列表就对啦)

\$ calicoctl node status

查看端口BGP 协议是通过TCP 连接来建立邻居的,因此可以用netstat 命令验证
BGP Peer

\$ netstat -natp|grep ESTABLISHED|grep 179

查看集群ippool情况--主节点

\$ calicoctl get ipPool -o yaml

######################################################

7. 配置kubelet(工作节点)

7.1 简介

每个工作节点上都运行一个kubelet服务进程,默认监听10250端口,接收并执行master发来的指令,管理Pod及Pod中的容器。每个kubelet进程会在API
Server上注册节点自身信息,定期向master节点汇报节点的资源使用情况,并通过cAdvisor监控节点和容器的资源。

这里让kubelet使用引导token的方式认证,所以认证方式跟之前的组件不同,它的证书不是手动生成,而是由工作节点TLS
BootStrap 向api-server请求,由主节点的controller-manager 自动签发。

创建角色绑定(主节点)

引导token的方式要求客户端向api-server发起请求时告诉他你的用户名和token,并且这个用户是具有一个特定的角色:system:node-bootstrapper,所以需要先将
bootstrap token 文件中的 kubelet-bootstrap 用户赋予这个特定角色,然后
kubelet 才有权限发起创建认证请求。

在主节点执行下面命令

#可以通过下面命令查询clusterrole列表

kubectl -n kube-system get
clusterrole

#可以回顾一下token文件的内容

\$ cat
/etc/kubernetes/ca/kubernetes/token.csv
44ec8a4eb808af51d1f470f2fde0e082,kubelet-bootstrap,10001,\”system:kubelet-bootstrap\”

#创建角色绑定(将用户kubelet-bootstrap与角色system:node-bootstrapper绑定)

kubectl create clusterrolebinding kubelet-bootstrap \
--clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

创建bootstrap.kubeconfig(工作节点)

这个配置是用来完成bootstrap
token认证的,保存了像用户,token等重要的认证信息,这个文件可以借助kubectl命令生成:(也可以自己写配置)

#设置集群参数(注意替换ip)

\$ kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ca/ca.pem \
--embed-certs=true \ --server=https://192.168.188.30:6443 \
--kubeconfig=bootstrap.kubeconfig

#设置客户端认证参数(注意替换token)

\$ kubectl config set-credentials kubelet-bootstrap \
--token=44ec8a4eb808af51d1f470f2fde0e082 \
--kubeconfig=bootstrap.kubeconfig

#设置上下文

\$ kubectl config
set-context default \ --cluster=kubernetes \
--user=kubelet-bootstrap \ --kubeconfig=bootstrap.kubeconfig

#选择上下文 \$ kubectl config use-context default
--kubeconfig=bootstrap.kubeconfig

#将刚生成的文件移动到合适的位置

mv
bootstrap.kubeconfig /etc/kubernetes/

##################################

通过系统服务方式部署(工作节点)

#确保相关目录存在

mkdir -p /var/lib/kubelet

mkdir -p /etc/kubernetes

mkdir -p /etc/cni/net.d

#复制kubelet服务配置文件

cp
/opt/kubernetes-starter/target/worker-node/kubelet.service
/lib/systemd/system/

#复制kubelet用到的cni插件配置文件

cp
/opt/kubernetes-starter/target/worker-node/10-calico.conf
/etc/cni/net.d/

systemctl daemon-reload

systemctl enable kubelet.service

systemctl start kubelet.service

#启动kubelet之后到master节点允许worker加入(批准worker的tls证书请求)

#--------*在主节点执行*---------

\$ kubectl get csr|grep \’Pending\’ | awk \’{print \$1}\’| xargs
kubectl certificate
approve

#-----------------------------

###########检查日志# journalctl -f -u kubelet

8. 为集群增加service功能 - kube-proxy(工作节点)

简介

每台工作节点上都应该运行一个kube-proxy服务,它监听API
server中service和endpoint的变化情况,并通过iptables等来为服务配置负载均衡,是让我们的服务在集群外可以被访问到的重要方式。

准备证书

#proxy证书放在这

mkdir -p /etc/kubernetes/ca/kube-proxy
#准备proxy证书配置 - proxy只需客户端证书,因此证书请求中 hosts
字段可以为空。

#CN 指定该证书的 User 为 system:kube-proxy,预定义的
ClusterRoleBinding system:node-proxy 将User system:kube-proxy 与 Role
system:node-proxier 绑定,授予了调用 kube-api-server proxy的相关 API
的权限

cp /opt/kubernetes-starter/target/ca/kube-proxy/kube-proxy-csr.json
/etc/kubernetes/ca/kube-proxy/

cd /etc/kubernetes/ca/kube-proxy/

#使用根证书(ca.pem)签发calico证书

\$
cfssl gencert \ -ca=/etc/kubernetes/ca/ca.pem \
-ca-key=/etc/kubernetes/ca/ca-key.pem \
-config=/etc/kubernetes/ca/ca-config.json \ -profile=kubernetes
kube-proxy-csr.json | cfssljson -bare kube-proxy

#我们最终要的是kube-proxy-key.pem和kube-proxy.pem

生成kube-proxy.kubeconfig配置

#设置集群参数(注意替换ip)

\$ kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ca/ca.pem \
--embed-certs=true \ --server=https://192.168.188.30:6443 \
--kubeconfig=kube-proxy.kubeconfig

#置客户端认证参数

\$ kubectl config
set-credentials kube-proxy \
--client-certificate=/etc/kubernetes/ca/kube-proxy/kube-proxy.pem \
--client-key=/etc/kubernetes/ca/kube-proxy/kube-proxy-key.pem \
--embed-certs=true \ --kubeconfig=kube-proxy.kubeconfig

#设置上下文参数

\$ kubectl config set-context default \
--cluster=kubernetes \ --user=kube-proxy \
--kubeconfig=kube-proxy.kubeconfig

#选择上下文

\$ kubectl config
use-context default --kubeconfig=kube-proxy.kubeconfig

#移动到合适位置

\$ mv kube-proxy.kubeconfig /etc/kubernetes/kube-proxy.kubeconfig

部署

通过系统服务方式部署:

#确保工作目录存在

mkdir -p /var/lib/kube-proxy

#复制kube-proxy服务配置文件

cp
/opt/kubernetes-starter/target/worker-node/kube-proxy.service
/lib/systemd/system/

#安装依赖软件

yum -y install conntrack

systemctl daemon-reload

systemctl enable kube-proxy.service

systemctl start kube-proxy.service

###journalctl -f -u kube-proxy

9. 为集群增加dns功能 - kube-dns(app)

简介

kube-dns为Kubernetes集群提供命名服务,主要用来解析集群服务名和Pod的hostname。目的是让pod可以通过名字访问到集群内服务。它通过添加A记录的方式实现名字和service的解析。普通的service会解析到service-ip。headless
service会解析到pod列表。

kube-dns有些特别,因为它本身是运行在kubernetes集群中,以kubernetes应用的形式运行。所以它的认证授权方式跟之前的组件都不一样。它需要用到service
account认证和RBAC授权。

service account认证:

每个service
account都会自动生成自己的secret,用于包含一个ca,token和secret,用于跟api-server认证

RBAC授权:

权限、角色和角色绑定都是kubernetes自动创建好的。我们只需要创建一个叫做kube-dns的
ServiceAccount即可,官方现有的配置已经把它包含进去了。

部署

通过kubernetes应用的方式部署
kube-dns.yaml文件基本与官方一致(除了镜像名不同外)。
里面配置了多个组件,之间使用”---“分隔

我们在官方的基础上添加的变量,生成适合我们集群的配置。直接copy就可以啦

#到kubernetes-starter目录执行命令

docker pull
registry.cn-hangzhou.aliyuncs.com/imooc/k8s-dns-sidecar-amd64:1.14.5

cp /opt/kubernetes-starter/target/services/kube-dns.yaml /opt/ \$
kubectl create -f /opt/kube-dns.yaml

新的配置没有设定api-server。不访问api-server,它是怎么知道每个服务的cluster
ip和pod的endpoints的呢?这就是因为kubernetes在启动每个服务service的时候会以环境变量的方式把所有服务的ip,端口等信息注入进来。

10 配置kubernetes UI图形化界面 (其他节点-我在主节点)

[https://github.com/gjmzj/kubeasz/blob/master/docs/guide/dashboard.md]

k8s里面有两种用户,一种是User,一种就是service
account,User给人用的,service account给进程用的,让进程有相关的权限。

如dasboard就是一个进程,我们就可以创建一个service
account给它,让它去访问k8s。

######

查看/lib/systemd/system/kube-apiserver.service

##启用基本密码认证

--basic-auth-file=/etc/kubernetes/basic_auth_file \

vi /etc/kubernetes/basic_auth_file文件,并在其中添加:

admin,admin,1

readonly,readonly,2

密码文件模板中按照每行(密码,用户名,序号)的格式,可以定义多个用户

务必保管好密码文件

使用admin 登陆dashboard拥有所有权限,使用readonly
登陆后仅查看权限,首先在 master节点文件
/etc/kubernetes/basic_auth_file确认用户名和密码,如果要增加或者修改用户,修改保存该文件后记得逐个重启你的master
节点;

cd /opt

下载ui-admin-rbac.yaml

wget
https://raw.githubusercontent.com/gjmzj/kubeasz/master/manifests/dashboard/ui-admin-rbac.yaml

下载ui-read-rbac.yaml

wget
https://raw.githubusercontent.com/gjmzj/kubeasz/master/manifests/dashboard/ui-read-rbac.yaml

下载kubernetes-dashboard.yaml

wget
https://raw.githubusercontent.com/gjmzj/kubeasz/master/manifests/dashboard/kubernetes-dashboard.yaml

docker pull mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.8.3
(所有节点)

###可以自定义 vi kubernetes-dashboard.yaml

自动生成dashboard证书,此处不需要填写apiserver地址。

###修改- --apiserver-host=http://192.168.188.30:6443 指向自己的api
server.--暂时不用改

修改镜像为自己可用的镜像 image:
mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.8.3

下载admin-user-sa-rbac.yaml

wget
[https://raw.githubusercontent.com/gjmzj/kubeasz/master/manifests/dashboard/admin-user-sa-rbac.yaml]{.underline}

kubernetes-dashboard-certs创建

新建一个空目录:

mkdir /certs

然后执行下面命令:

kubectl create secret generic kubernetes-dashboard-certs
--from-file=/certs -n kube-system

创建dashboard

# 部署dashboard 主yaml配置文件

kubectl create -f kubernetes-dashboard.yaml

kubectl create -f admin-user-sa-rbac.yaml

设置用户admin 的RBAC 权限

kubectl create -f ui-admin-rbac.yaml

设置用户readonly 的RBAC 权限

kubectl create -f ui-read-rbac.yaml

将访问账号名admin与kubernetes-rbac.yaml文件中指定的cluster-admin关联,获得访问权限。

kubectl create clusterrolebinding login-dashboard-admin
--clusterrole=cluster-admin --user=admin

查看

kubectl get -f kubernetes-dashboard.yaml

kubectl get -f admin-user-sa-rbac.yaml

####################### #可选

删除kubernetes-dashboard

,删除命令如下:

kubectl delete -f kubernetes-dashboard.yaml

在运行kubectl get pods
--all-namespaces发现总是有kube-system命名空间下的pod在运行.最后通过指定命名空间删除

kubectl delete --all pods --namespace=kube-system

kubectl delete deployment kubernetes-dashboard --namespace=kube-system

#################################################

验证

###########################

iptables -I FORWARD -s 0.0.0.0/0 -j ACCEPT (所有节点)

写入开机自启/etc/rc.local里面

###################

在主节点上:

首先,查看dashboard被k8s分配到了哪一台机器上

kubectl get pods --all-namespaces -o wide

接着,查看dashboard的集群内部IP,

kubectl get services --all-namespaces

# 查看pod 运行状态--一定要是running状态

kubectl get pod -n kube-system
| grep dashboard

# 查看dashboard service kubectl get svc -n
kube-system|grep dashboard

# 查看pod 运行日志 有没有错误

kubectl logs
kubernetes-dashboard-66c9d98865-p59v4 -n kube-system

访问

# 查看集群服务 kubectl cluster-info|grep dashboard

浏览器访问

[[https://192.168.188.30:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy]

提示用户名密码 admin/admin

打开页面出现dashboard
新版本自带的登陆页面。Kubernetes仪表盘支持两种登录方式:

kubeconfig(HTTPS)和token令牌(http)

# 获取 Bearer Token,找到输出中 ‘token:’ 开头那一行

\$ kubectl -n
kube-system describe secret \$(kubectl -n kube-system get secret | grep
admin-user | awk \’{print \$1}\’)

由于还未部署 Heapster 插件,当前 dashboard 不能展示 Pod、Nodes 的CPU、内存等 metric 图形,后续部署 heapster后自然能够看到