kubernetes 用到的工具及组件,将所有的组件下载后放到/usr/local/bin目录下(记得chmod a+x /usr/local/bin/*)。所有的组件,原则上都用最新的,如果遇到不支持的,最有可能是docker,可以换成docker-17.03.2-ce。
1、cfssl、cfssljson,为确保安全,kubernetes 系统各组件需要使用 x509 证书对通信进行加密和认证。
CA (Certificate Authority) 是自签名的根证书,用来签名后续创建的其它证书。
本文档使用 CloudFlare 的 PKI 工具集 cfssl 创建所有证书。
一般我们用到两个组件:cfssl、cfssljson
# wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
# mv cfssl_linux-amd64 /usr/local/bin/cfssl
# wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
# mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
如果不想安装wget:
curl -s -L -o /usr/local/bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
curl -s -L -o /usr/local/bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
chmod +x /usr/local/bin/{cfssl,cfssljson}
创建证书都在/etc/kubernetes/ca 这个目录下。
创建根证书 (CA)
CA 证书是集群所有节点共享的,只需要创建一个 CA 证书,后续创建的所有证书都由它签名。
创建配置文件
CA 配置文件用于配置根证书的使用场景 (profile) 和具体参数 (usage,过期时间、服务端认证、客户端认证、加密等),后续在签名其它证书时需要指定特定场景。
cat > ca-config.json <<EOF
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "87600h"
}
}
}
}
EOF
signing:表示该证书可用于签名其它证书,生成的 ca.pem 证书中 CA=TRUE;
server auth:表示 client 可以用该该证书对 server 提供的证书进行验证;
client auth:表示 server 可以用该该证书对 client 提供的证书进行验证;
创建证书签名请求文件
cat > ca-csr.json <<EOF
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "ChongQing",
"L": "ChongQing",
"O": "k8s",
"OU": "yunwei"
}
]
}
EOF
CN: Common Name,浏览器使用该字段验证网站是否合法,一般写的是域名。非常重要。浏览器使用该字段验证网站是否合法
C: Country, 国家
ST: State,州,省
L: Locality,地区,城市
O: Organization Name,组织名称,公司名称
OU: Organization Unit Name,组织单位名称,公司部门
生成 CA 证书和私钥
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
ls ca*
分发证书文件(证书都在一台上生成,根据需要拷贝到其他节点)
将生成的 CA 证书、秘钥文件、配置文件拷贝到所有节点的 /etc/kubernetes/ca 目录下。
# scp /etc/kubernetes/ca/* 192.168.111.11:/etc/kubernetes/ca/
# scp /etc/kubernetes/ca/* 192.168.111.12:/etc/kubernetes/ca/
2、etcd 是基于 Raft 的分布式 key-value 存储系统,由 CoreOS 开发,常用于服务发现、共享配置以及并发控制(如 leader 选举、分布式锁等)。kubernetes 使用 etcd 存储所有运行数据。
项目地址:https://github.com/etcd-io/etcd/releases
选择etcd-v3.3.9-linux-amd64.tar.gz下载,主要用到两个文件etcd,etcdctl,分别是数据库文件盒客户端文件。
# wget https://github.com/etcd-io/etcd/releases/download/v3.3.9/etcd-v3.3.9-linux-amd64.tar.gz
# tar -zxvf etcd-v3.3.9-linux-amd64.tar.gz
# cd /etcd-v3.3.9-linux-amd64
# mv ./etcd etcdctl /usr/local/bin
将这两个文件拷贝到所有etcd集群的节点的/usr/local/bin 目录下
3、flannel,使用 vxlan 技术为各节点kubernetes集群内各节点(包括 master 节点)创建一个可以互通的 Pod 网络。
flaneel 第一次启动时,从 etcd 获取 Pod 网段信息,为本节点分配一个未使用的 /24 段地址,然后创建 flannedl.1(也可能是其它名称,如 flannel1 等) 接口。
flannel 将分配的 Pod 网段信息写入 /run/flannel/docker 文件,docker 后续使用这个文件中的环境变量设置 docker0 网桥。
项目地址:https://github.com/coreos/flannel/releases
选择flannel-v0.10.0-linux-amd64.tar.gz,主要用到的就是flanneld、mk-docker-opts.sh两个文件。
# wget https://github.com/coreos/flannel/releases/download/v0.10.0/flannel-v0.10.0-linux-amd64.tar.gz
# tar -zxvf flannel-v0.10.0-linux-amd64.tar.gz
# mv ./flanneld mk-docker-opts.sh /usr/local/bin
将这两个文件拷贝到所有的节点的/usr/local/bin 目录下。
4、docker 是容器的运行环境,管理它的生命周期。kubelet 通过 Container Runtime Interface (CRI) 与 docker 进行交互。
官网下载地址:https://download.docker.com/linux/static/stable/x86_64/
# wget https://download.docker.com/linux/static/stable/x86_64/docker-17.03.2-ce.tgz
# tar -zxvf docker-17.03.2-ce.tgz
# mv ./docker-17.03.2-ce/* /usr/local/bin
将docker的全部文件拷贝到所有的节点的/usr/local/bin 目录下。
5、Kubernetes(k8s),是自动化容器操作的开源平台,这些操作包括部署,调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器,那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker,还支持Rocket,这是另一种容器技术。
使用Kubernetes可以:
Kubernetes主要包含服务器端(kube-apiserver、kube-controller-manager、kube-scheduler)和客户端(kubelet、kube-proxy)及管理端kubectl。
kube-apiserver,kube-apiserver主要负责暴露Kubernetes API,不管是kubectl还是HTTP调用来操作Kubernetes集群各种资源,都是通过kube-apiserver提供的接口进行操作的。
kube-controller-manager,管理控制器负责整个Kubernetes的管理工作,保证集群中各种资源的状态处于期望状态,当监控到集群中某个资源状态不正常时,管理控制器会触发对应的调度操作,主要由以下几部分组成:
kube-scheduler,调度器负责Kubernetes集群的具体调度工作,接收来自于管理控制器(kube-controller-manager)触发的调度操作请求,然后根据请求规格、调度约束、整体资源情况等因素进行调度计算,最后将任务发送到目标节点的kubelet组件执行。
kubelet,是Node节点上最重要的核心组件,负责Kubernetes集群具体的计算任务,具体功能包括:
kube-proxy,主要负责Service Endpoint到POD实例的请求转发及负载均衡的规则管理。
kube-proxy本身实际上并不负责请求转发和负载均衡,而时从kube-apiserver获取Service和POD的状态更新,生成对应的DNAT规则到本地的iptabels,最终的转发和负载均衡动作有iptabels实施,所以kube-proxy组件即使出现问题,已经更新到iptabels的转发规则依然能够生效。
kubectl,用于运行Kubernetes集群命令的管理工具。对于kubectl的安装可以在服务端安装完成后安装,一般安装在服务端的其中一台上就ok了。
项目地址:https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md
选择一个版本的,选择Server Binaries,选择kubernetes-node-linux-amd64.tar.gz下载
# wget https://dl.k8s.io/v1.11.3/kubernetes-node-linux-amd64.tar.gz
# tar -zxvf kubernetes-node-linux-amd64.tar.gz
# cd /kubernetes-node-linux-amd64
# mv ./kube-apiserver kube-controller-manager kube-scheduler /usr/local/bin #服务端只复制这三个
# mv ./kubelet kube-proxy /usr/local/bin #客户端复制这两个个,也复制到其他几台客户端的/usr/local/bin目录下。
kube-scheduler 和 kube-controller-manager 可以以集群模式运行,通过 leader 选举产生一个工作进程,其它进程处于阻塞模式。但是我们一般不这么做,多个 kube-apiserver,一个kube-scheduler 和 kube-controller-manager,效率有问题,二是可能会跨主机,比如A机的kube-apiserver,用的是B机的kube-scheduler 和C机的kube-controller-manager。
对于 kube-apiserver,可以运行多个实例(本文档是 3 实例),但对其它组件需要提供统一的访问地址,该地址需要高可用。本文档使用 keepalived 和 haproxy (或者nginx)实现 kube-apiserver VIP 高可用和负载均衡。
最好的是kube-apiserver、kube-scheduler 和 kube-controller-manager是一个整体,都用本机的,都用本机还可以不用认证授权(后续版本会删除非安全端口,建议还是用认证的),而且三个主机的kube-apiserver、kube-scheduler 和 kube-controller-manager都是可用的。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章