目录
- 一、K8S安装
- 二、安装时遇到的几个问题
- 2.1、Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes
- 2.2、No resources found
- 2.3、端口配置错误
- 2.4、kubectl get node状态NotReady
- 三、K8S组件介绍
- 3.1 kube-apiserver
- 3.2 etcd
- 3.3 kube-scheduler
- 3.4 kube-controller-manager
- 3.5 cloud-controller-manager
- 3.6 kubelet
- 3.7 kube-proxy
- 3.8 容器运行时(Container Runtime)
- 3.9 CoreDNS
- 3.10 Dashboard
一、K8S安装
二进制安装K8S集群-上
二进制安装K8S集群-下
二、安装时遇到的几个问题
2.1、Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of “crypto/rsa: verification error” while trying to verify candidate authority certificate "kubernetes
[root@k8s-master01 ~]# kubectl get cs
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
解决办法:
[root@k8s-master01 ~]# rm -rf .kube
[root@k8s-master01 ~]# mkdir -p /root/.kube ; cp /etc/kubernetes/admin.kubeconfig /root/.kube/config #网上大部分都是走完以上2步即恢复正常,但本机安装中,走完这2步还是报错。
[root@k8s-master01 ~]# export KUBECONFIG=/etc/kubernetes/admin.kubeconfig
[root@k8s-master01 ~]# kubectl get cs #再次输入后正常
2.2、No resources found
[root@k8s-master01 ~]# kubectl get node
No resources found
解决办法:
[root@k8s-master01 ~]# vim /usr/lib/systemd/system/kube-apiserver.service
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota \ #删除ServiceAccount
[root@k8s-master01 ~]# systemctl daemon-reload
[root@k8s-master01 ~]# systemctl restart kube-apiserver
2.3、端口配置错误
kubectl get cs
The connection to the server 192.168.1.10:16443 was refused - did you specify the right host or port?
解决办法:
kubectl config view查看节点配置,发现端口配置错误
kubectl config current-context #用于显示当前上下文
kubectl config delete-context X #删除指定上下文
vim /root/.kube/config #修改到正确端口号
2.4、kubectl get node状态NotReady
安装好calico后恢复正常
三、K8S组件介绍
控制平面组件(Master节点)
控制平面组件会为集群做出全局决策,比如资源的调度。以及检测和响应集群事件。控制平面组件可以在集群中的任何节点上运行。但一般都是安装在master节点机器上。
3.1 kube-apiserver
提供其他模块之间的数据交互和通信的枢纽,其他模块通过API Server查询或修改数据,只有API Server才直接和etcd进行交互。
Kubernetes集群中,API Server扮演着通信枢纽的位置。API Server不仅负责和 etcd 交互,并且对外提供统一的API调用入口, 所有的交互都是以 API Server为核心的。
3.2 etcd
一致且高可用的键值存储,用作 Kubernetes所有集群数据的后台数据库。K8S中仅API Server具备读写权限,其他组件必须通过 API Server的接口才能读写数据。
3.3 kube-scheduler
kube-scheduler是控制平面的组件。负责资源调度的进程,根据调度算法为新创建的Pod选择一个合适的Node节点。可以理解成K8S所有node节点的调度器。当用户要部署服务时,Scheduler会根据调度算法选择最合适的Node 节点来部署Pod。
3.4 kube-controller-manager
kube-controller-manager 是控制平面的组件, 负责集群内 Node、Namespace、Service、Token、Replication 等资源对象的管理,使集群内的资源对象维持在预期的工作状态。
每一个 controller通过 api-server 提供的 restful 接口实时监控集群内每个资源对象的状态,当发生故障,导致资源对象的工作状态发生变化,就进行干预,尝试将资源对象从当前状态恢复为预期的工作状态。
3.5 cloud-controller-manager
一个 Kubernetes 控制平面组件,嵌入了特定于云平台的控制逻辑。云控制器管理器(Cloud Controller Manager)允许你将你的集群连接到云提供商的 API 之上, 并将与该云平台交互的组件同与你的集群交互的组件分离开来。
cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes,或者在本地计算机中运行学习环境, 所部署的集群不需要有云控制器管理器。
与 kube-controller-manager 类似,cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中, 供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。
Node 组件(node节点)
节点组件会在每个节点上运行,负责维护运行的 Pod 并提供 Kubernetes 运行环境。
3.6 kubelet
kubelet 会在集群中每个节点上运行。它保证容器都运行在 Pod 中。
当scheduler确定pod运行在某个节点上时,会将pod的具体配置信息发送给节点的kubelet,kubelet会根据配置信息进行创建容器,并将容器运行结果报告给Master。另外,kubelet还会周期性的向Master报告pod以及node节点的运行状态。
3.7 kube-proxy
kube-proxy 是集群中每个节点(node)上所运行的网络代理,实现 Kubernetes 服务概念的一部分。
kube-proxy 维护节点上的一些网络规则, 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
总结来说kube-proxy实现的主要有几点作用:
实时watching Kubernetes kube-API ,获取建立Service的建立、升级信息,增加或者删除backend Pod 信息,来获取Pod 和 vip的映射关系;
维护本地Netfilter 、 iptables、 IPVS 内核组件;
通过修改和更新Netfilter,iptables,IPVS 规则,来实现数据报文的转发规则;
实现每个node上 clusertIP的发布和路由为维护;
构建路由信息,通过转发规则转发报文到VIPs对应的Pod。
iptables模式:
kube-proxy默认模式,当前模式下,kube-proxy监听service和endpoint的变化,当service创建时,kube-proxy在iptables中追加新的规则,对于service中的每一个endpoint,会在iptables中追加一条DNAT规则,将目的地址设置为真正提供服务的pod地址;再为service追加规则,设定动作为跳转到对应的endpoint规则上
ipvs模式:
ipvs在INPUT阶段也是基于netfilter的hook功能,与iptables类似。但是转发规则是通过工作在内核空间下的hash表作为存储的数据结构。在这种模式下,只需要通过ipset来验证具体的请求是否满足某条规则。当service变化时,只需要更新ipset记录,不需要改变iptables规则链,因此可以保证iptables中的规则不会根据service的创建越来越多。同时,ipvs的性能也高于iptables,因为当service变化时,ipvs只需要对特定的hash表进行更新,而iptables则需要更新整个规则表。
3.8 容器运行时(Container Runtime)
容器运行时是 Kubernetes 管理的应用程序的基础组件。容器运行时是一种用于执行应用程序和容器的软件,它提供了将应用程序和容器打包到独立环境中的能力,使它们可以在任何地方运行。
在 K8s 中,可用的容器运行时包括 Docker、Containerd、CRI-O 和其他一些软件。这些容器运行时具有不同的特性和优点,在选择容器运行时时需要考虑诸多因素,例如性能、可靠性、安全性和兼容性等。
容器运行时的功能非常丰富,包括容器的创建、启动和停止等基本操作,还包括对容器资源的限制和保护、容器的网络和存储配置、容器间的通信和数据共享等高级功能。通过使用容器运行时,K8s 可以实现快速且高效的应用程序部署和管理,同时也可以提供可靠和可扩展的基础设施环境。
3.9 CoreDNS
尽管其他插件都并非严格意义上的必需组件,但几乎所有 Kubernetes 集群都应该有集群 DNS, 因为很多示例都需要 DNS 服务。
集群 DNS 是一个 DNS 服务器,和环境中的其他 DNS 服务器一起工作,它为 Kubernetes 服务提供 DNS 记录。
Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
3.10 Dashboard
Dashboard是Kubernetes 集群的通用的、基于Web的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身, 并进行故障排除。
部署方式:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml #安装
kubectl proxy #启用Dashboard访问