Kubernetes(通常称为”K8S”)是Google开源的容器集群管理系统。其设计目标是在主机集群之间提供一个能够自动化部署、可拓展、应用容器可运营的平台。Kubernetes通常结合docker容器工具工作,并且整合多个运行着docker容器的主机集群,Kubernetes不仅仅支持Docker,还支持Rocket,这是另一种容器技术。Kubernetes是一个用于容器集群的自动化部署、扩容以及运维的开源平台。
本文系列:
Kubernetes(K8S)容器集群管理环境完整部署详细教程-上篇
Kubernetes(K8S)容器集群管理环境完整部署详细教程-中篇
Kubernetes(K8S)容器集群管理环境完整部署详细教程-下篇
通过Kubernetes, 可以快速有效地响应用户需求:
->
快速而有预期地部署应用;
->极速地扩展你的应用;
->无缝对接新的应用功能;
-> 节省资源,优化硬件资源的使用; Kubernetes功能特性:->
自动化容器部署与复制
->随时扩展或收缩容器规模
->组织容器成组,提供容器间的负载均衡
->快速更新及回滚容器版本
-> 提供弹性伸缩,如果某个容器失效就进行替换Kubernetes重要组件:
1)Master组件Master节点上面主要由四个模块组成:APIServer、scheduler、controller manager、etcd
-> APIServer: 负责对外提供RESTful的Kubernetes API服务,它是系统管理指令的统一入口,任何对资源进行增删改查的操作都要交给APIServer处理后再提交给etcd。kubectl(k8s提供的客户端工具,该工具内部就是对Kubernetes API的调用)是直接和APIServer交互的。
-> schedule: 它的职责很明确,就是负责调度pod到合适的Node上。如果把scheduler看成一个黑匣子,那么它的输入是pod和由多个Node组成的列表,输出是Pod和一个Node的绑定,即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法,但是同样也保留了接口,用户可以根据自己的需求定义自己的调度算法。
-> controller manager: 如果说APIServer做的是“前台”的工作的话,那controller manager就是负责“后台”的。每个资源一般都对应有一个控制器,而controller manager就是负责管理这些控制器的。比如我们通过APIServer创建一个pod,当这个pod创建成功后,APIServer的任务就算完成了。而后面保证Pod的状态始终和我们预期的一样的重任就由controller manager去保证了。
-> etcd: 它是一个高可用的键值存储系统,Kubernetes使用它来存储各个资源的状态,从而实现了Restful的API。 2)Node组件每个Node节点主要由三个模块组成:kubelet、kube-proxy、runtime。
runtime。runtime指的是容器运行环境,目前Kubernetes支持docker和rkt两种容器。
-> kubelet:Kubelet是Master在每个Node节点上面的agent,是Node节点上面最重要的模块,它负责维护和管理该Node上面的所有容器,但是如果容器不是通过Kubernetes创建的,它并不会管理。本质上,它负责使Pod得运行状态与期望的状态一致。
-> kube-proxy:该模块实现了Kubernetes中的服务发现和反向代理功能。反向代理方面:kube-proxy支持TCP和UDP连接转发,默认基于Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面,kube-proxy使用etcd的watch机制,监控集群中service和endpoint对象数据的动态变化,并且维护一个service到endpoint的映射关系,从而保证了后端pod的IP变化不会对访问者造成影响。另外kube-proxy还支持session affinity。 3)PodPod是k8s进行资源调度的最小单位,每个Pod中运行着一个或多个密切相关的业务容器,这些业务容器共享这个Pause容器的IP和Volume,我们以这个不易死亡的Pause容器作为Pod的根容器,以它的状态表示整个容器组的状态。一个Pod一旦被创建就会放到Etcd中存储,然后由Master调度到一个Node绑定,由这个Node上的Kubelet进行实例化。每个Pod会被分配一个单独的Pod IP,Pod IP + ContainerPort 组成了一个Endpoint。
4)ServiceService其功能使应用暴露,Pods 是有生命周期的,也有独立的 IP 地址,随着 Pods 的创建与销毁,一个必不可少的工作就是保证各个应用能够感知这种变化。这就要提到 Service 了,Service 是 YAML 或 JSON 定义的由 Pods 通过某种策略的逻辑组合。更重要的是,Pods 的独立 IP 需要通过 Service 暴露到网络中。
K8s集群可以帮助培育出一个组件及工具的生态,帮助减轻在公有云及私有云上运行应用的负担。
搭建Kubernetes集群环境有以下三种方式:
1. Minikube安装方式Minikube是一个工具,可以在本地快速运行一个单点的Kubernetes,尝试Kubernetes或日常开发的用户使用。但是这种方式仅可用于学习和测试部署,不能用于生产环境。
2. Kubeadm安装方式kubeadm是一个kubernetes官方提供的快速安装和初始化拥有最佳实践(best practice)的kubernetes集群的工具,提供kubeadm init和kubeadm join,用于快速部署Kubernetes集群。目前kubeadm还处于beta 和alpha状态,不推荐用在生产环境,但是可以通过学习这种部署方法来体会一些官方推荐的kubernetes最佳实践的设计和思想。
kubeadm的目标是提供一个最小可用的可以通过Kubernetes一致性测试的集群,所以并不会安装任何除此之外的非必须的addon。kubeadm默认情况下并不会安装一个网络解决方案,所以用kubeadm安装完之后,需要自己来安装一个网络的插件。所以说,目前的kubeadm是不能用于生产环境的
3. 二进制包安装方式(生产部署的推荐方式)从官方下载发行版的二进制包,手动部署每个组件,组成Kubernetes集群,这种方式符合企业生产环境标准的Kubernetes集群环境的安装,可用于生产方式部署。
一、基础信息
使用Kubernetes1.14.2,所有节点机操作系统是Centos7.5。本文档部署中所需kubernetes相关安装包和镜像可提前在FQ服务器上下载,然后同步到k8s部署机器上。具体信息如下:
ip地址 主机名 角色 172.16.60.241 k8s-master01 主节点1、etc节点1 172.16.60.242 k8s-master02 主节点2、etc节点2 172.16.60.243 k8s-master03 主节点3、etc节点3 172.16.60.244 k8s-node01 工作节点1 172.16.60.245 k8s-node02 工作节点2 172.16.60.246 k8s-node03 工作节点3 172.16.60.247 k8s-ha01 nginx节点1、harbor节点1 172.16.60.248 k8s-ha02 nginx节点2、harbor节点2本套Kubernetes集群环境版本
– Kubernetes 1.14.2
– Docker 18.09.6-ce
– Etcd 3.3.13
– Flanneld 0.11.0插件:
– Coredns
– Dashboard
– Metrics-server镜像仓库:
– harbor(两个仓库相互同步,对外提供统一入口VIP地址)
主要配置策略
kube-apiserver高可用(Nginx负载层):
– 使用Nginx+Keepalived实现高可用, VIP1:172.16.60.250;
– 关闭非安全端口 8080 和匿名访问;
– 在安全端口 6443 接收 https 请求;
– 严格的认证和授权策略 (x509、token、RBAC);
– 开启 bootstrap token 认证,支持 kubelet TLS bootstrapping;
– 使用 https 访问 kubelet、etcd,加密通信;kube-controller-manager高可用:
– 3节点高可用;
– 关闭非安全端口,在安全端口 10252 接收 https 请求;
– 使用 kubeconfig 访问 apiserver 的安全端口;
– 自动 approve kubelet 证书签名请求 (CSR),证书过期后自动轮转;
– 各controller 使用自己的 ServiceAccount 访问 apiserver;kube-scheduler高可用:
– 3节点高可用;
– 使用 kubeconfig 访问 apiserver 的安全端口;kubelet:
– 使用 kubeadm 动态创建 bootstrap token,而不是在 apiserver 中静态配置;
– 使用TLS bootstrap机制自动生成 client 和 server 证书,过期后自动轮转;
– 在 kubeletConfiguration 类型的 JSON 文件配置主要参数;
– 关闭只读端口,在安全端口 10250 接收 https 请求,对请求进行认证和授权,拒绝匿名访问和非授权访问;
– 使用 kubeconfig 访问 apiserver 的安全端口;kube-proxy:
– 使用kubeconfig 访问 apiserver 的安全端口;
– 在KubeProxyConfiguration 类型的 JSON 文件配置主要参数;
– 使用ipvs代理模式;集群插件:
– DNS:使用功能、性能更好的 coredns;
– Dashboard:支持登录认证;
– Metric:metrics-server,使用 https 访问 kubelet 安全端口;
– Log:Elasticsearch、Fluend、Kibana;
– Registry 镜像库:Harbor私有仓库,两个节点相互同步;kubernetes集群部署中生成的证书文件如下:
ca-key.pem 根私钥(controller-manager配置的时候,跟上–service-account-private-key-file)
ca.pem 根证书(apiserver配置的时候,跟上–service-account-key-file)
kubernetes-key.pem 集群私钥
kubernetes.pem 集群证书
kube-proxy.pem proxy证书-node节点进行认证
kube-proxy-key.pem proxy私钥-node节点进行认证
admin.pem 管理员证书-主要用于kubectl认证
admin-key.pem 管理员私钥-主要用于kubectl认证TLS作用:
就是对通讯加密,防止中间人窃听;同时如果证书不信任的话根本就无法与 apiserver 建立连接,更不用提有没有权限向 apiserver 请求指定内容。
RBAC作用: RBAC 中规定了一个用户或者用户组(subject)具有请求哪些 api 的权限;在配合 TLS 加密的时候,实际上 apiserver 读取客户端证书的 CN 字段作为用户名,读取 O 字段作为用户组。总之想要与apiserver通讯就必须采用由apiserver CA签发的证书,这样才能形成信任关系,建立TLS连接;另外可通过证书的CN、O字段来提供RBAC所需用户与用户组。
kubernetes集群会默认开启RABC(角色访问控制机制),这里提前了解几个重要概念:
– DRBC
K8S 1.6引进,是让用户能够访问K8S API资源的授权方式(不授权就没有资格访问K8S的资源)
– 用户K8S有两种用户:User 和 Service Account。其中,User给用户使用,Service Account给进程使用,让进程有相关权限。如Dashboard就是一个进程,可以创建一个Service Account给它使用。
– 角色Role是一系列权限的集合,例如一个Role可包含读取和列出Pod的权限(ClusterRole和Role类似,其权限范围是整个集群)
– 角色绑定RoleBinding把角色映射到用户,从而让这些用户拥有该角色的权限(ClusterRoleBinding和RoleBinding类似,可让用户拥有ClusteRole的权限)
– Secret Secret是一个包含少量敏感信息如密码,令牌或密钥的对象。把这些信息保存在Secret对象中,可以在这些信息被使用时加以控制,并可以减低信息泄露的风险。二、环境初始化准备
Kubernetes集群部署过程均需要使用root账号操作,下面初始化操作在k8s的master和node节点上操作。
三、创建集群中需要的CA证书和秘钥
为确保安全,kubernetes 系统各组件需要使用 x509 证书对通信进行加密和认证。CA (Certificate Authority) 是自签名的根证书,用来签名后续创建的其它证书。这里使用 CloudFlare 的 PKI 工具集 cfssl 创建所有证书。下面部署命令均在k8s-master01节点上执行,然后远程分发文件和执行命令。
四、部署kubectl命令行工具
kubectl 是 kubernetes 集群的命令行管理工具. kubectl 默认从 ~/.kube/config 文件读取kube-apiserver地址和认证信息,如果没有配置,执行kubectl命令时就会报错!kubectl只需要部署一次,生成的kubeconfig文件是通用的,可以拷贝到需要执行kubectl命令的节点机器,重命名为 ~/.kube/config;这里我将kubectl节点只部署到三个master节点机器上,其他节点不部署kubectl命令。也就是说后续进行kubectl命令管理就只能在master节点上操作。下面部署命令均在k8s-master01节点上执行,然后远程分发文件和执行命令。
五、部署etcd集群
etcd是基于Raft的分布式key-value存储系统,由CoreOS开发,常用于服务发现、共享配置以及并发控制(如leader选举、分布式锁等)。kubernetes使用etcd存储所有运行数据。需要注意的是:由于etcd是负责存储,所以不建议搭建单点集群,如zookeeper一样,由于存在选举策略,所以一般推荐奇数个集群,如3,5,7。只要集群半数以上的结点存活,那么集群就可以正常运行,否则集群可能无法正常使用。下面部署命令均在k8s-master01节点上执行,然后远程分发文件和执行命令。
六、Flannel容器网络方案部署
kubernetes要求集群内各节点(这里指master和node节点)能通过Pod网段互联互通。flannel使用vxlan技术为各节点创建一个可以互通的Pod网络,使用的端口为UDP 8472(需要开放该端口,如公有云AWS等)。flanneld第一次启动时,从etcd获取配置的Pod网段信息,为本节点分配一个未使用的地址段,然后创建flannedl.1网络接口(也可能是其它名称,如flannel1等)。flannel将分配给自己的Pod网段信息写入/run/flannel/docker文件,docker后续使用这个文件中的环境变量设置docker0网桥,从而从这个地址段为本节点的所有Pod容器分配IP。下面部署命令均在k8s-master01节点上执行,然后远程分发文件和执行命令。
七、基于nginx 四层代理环境
这里采用nginx 4 层透明代理功能实现 K8S 节点( master 节点和 worker 节点)高可用访问 kube-apiserver。控制节点的 kube-controller-manager、kube-scheduler 是多实例(3个)部署,所以只要有一个实例正常,就可以保证高可用;搭建nginx+keepalived环境,对外提供一个统一的vip地址,后端对接多个 apiserver 实例,nginx 对它们做健康检查和负载均衡;kubelet、kube-proxy、controller-manager、scheduler 通过vip地址访问 kube-apiserver,从而实现 kube-apiserver 的高可用;
点击查看 Kubernetes(K8S)容器集群管理环境完整部署详细教程-中篇
原文链接:https://www.cnblogs.com/kevingrace/p/10961264.html