kubernetes(kubernetes组件)

本文目录：

• 1、2022年kubernetes的5个趋势
• 2、kubernetes常见故障
• 3、Kubernetes——Pod控制器详解

2022年Kubernetes的5个趋势

Kubernetes在成长，使用它的团队也在成长。早期采用者现在已经进入了自己的领域，能够基于经验和云原生生态系统的增长，以新的方式扩展Kubernetes的核心功能。

《财富》100强公司加速使用Kubernetes作为其更广泛的混合云/多云基础设施的平台，这反映了推动Kubernetes在各行业采用率飙升的大趋势。

5个主要趋势

另一个大趋势是：许多公司仍在起步。而在他们的云之旅的任何阶段，大多数IT领导者都希望在生产中运行更多的容器化应用程序——Kubernetes是这样做的常见选择。

“Gartner预测，到2022年，超过75%的全球组织将在生产中运行容器化应用程序，而2020年这一比例还不到30%。”红帽产品战略高级总监Brian Gracely说。

这与红帽《2021企业开源状态》报告一致，其中72%的IT领导者表示他们预期在组织中越来越多地使用容器。他们还几乎普遍（85%）认为Kubernetes是云原生应用程序策略的关键。

这对Kubernetes的功能、用例、技能和其他领域产生了级联效应。“和任何新技术一样，存在技术成熟和用户学习曲线，”Gracely说。

1.Kubernetes成为一切的平台？

Kubernetes与容器齐头并进。这一点2022年也不会改变。2022年及以后将继续发展的是团队使用基于Kubernetes的平台管理的应用程序类型。

Gracely说：“在早期，用户通常在内部构建自己的Kubernetes平台，并部署一组更简化的应用程序。但随着Kubernetes的稳定，使用模式已经明显成熟。”

例如，在Kubernetes上运行的大多数早期应用程序都是无状态的——但曾经的认为Kubernetes对有状态不友好的观点在今天已经站不住脚了。

“各种各样的应用程序在容器中运行，但我们开始看到更多的组织将其任务关键型、有状态的应用程序带到Kubernetes。数据库、事件驱动消息传递和任务关键型应用程序都有望迁移到Kubernetes，以利用它为所有应用程序带来的可扩展性、安全性和可移植性。”

Kubernetes已经准备好不“仅仅”成为一个容器编排工具，但Kubernetes控制平面正在成为多云和混合云操作的主干。

Drobisewski还希望更多经验丰富的团队以新的方式延长Kubernetes的成熟度，包括Kubernetes Operator。

Drobisewski说：“组织将开始DevOps旅程的下一步，并利用Kubernetes operator框架。我们将看到在Kubernetes之上构建的许多自助服务功能的扩展超越了资源调配和生命周期管理的基本自动化，成为其服务的全自动试点模式，实现了深入的数据驱动洞察，推动事件的自动修复和自愈能力，从而允许服务可根据工作负载的需要进行动态调整。”

2.Kubernetes和AI/ML成为明星组合

Kubernetes的成熟度和处理日益复杂用例的能力可能在AI和机器学习中最为明显。Kubernetes正在成为为生产中的人工智能和机器学习（AI/ML）工作负载提供服务的首选。

这是一对强大的组合，将在未来几年产生巨大的业务影响。

“在Kubernetes上运行的所有应用程序中，有一个突出的领域是AI/ML。随着数据科学在几乎每一家公司中都扮演着关键角色，改进和增强多种应用程序的能力也在增长。从改善客户互动到利用数据做出更好的决策，再到为自动驾驶车辆建模，AI/ML几乎影响着现代商业的方方面面。”

正如容器化，AI/ML的巨大潜力也需要一个坚实的IT基础来实现，需要一种有效的方式来管理生产中的一切。

“Kubernetes为AI/ML带来了完美的平台功能——可伸缩性、对GPU的访问、工作负载可移植性等。我们已经开始看到组织在Kubernetes上使用AI/ML做了大量工作，我们预计下一代应用程序将彻底改变行业。”

3.唯一比Kubernetes更热的东西是Kubernetes人才

在可预见的未来，对Kubernetes技能——以及一般的云原生功能——的需求将会白热化。

“在Kubernetes和云原生采用上没有放缓的迹象。”Linux基金会培训和认证SVP和GM Clyde Seepersad说，“我希望看到更多的组织继续向云移动，并增加对微服务、无服务器和其他云原生技术的使用。最重要的是，我希望更多的组织将认识到Kubernetes、Linux和DevOps之间的重要相互作用。”

是的，我们将在未来一年听到更多关于缺乏可用的、负担得起的Kubernetes人才的消息。各种组织将进行更协调一致的创造性努力，以建立Kubernetes能力和相关技能。

4.商业和托管服务将蓬勃发展

商业Kubernetes平台，如红帽的OpenShift，建立在开源项目之上，已经成为企业Kubernetes采用和使用的支柱。Gracely说，随着越来越多的早期采用者的成功故事被讲述，其他组织自然会寻求类似的业务成果。但随后他们又遇到了第三个问题——并不是每个公司都有建立运行自己平台所需内部能力的愿望或资金。

“他们通常不想投资于管理和维护Kubernetes的运维技能。这就是托管Kubernetes云服务的使用迅速扩展的地方，例如OpenShift Delicated、Red Hat OpenShift（ROSA）on AWS和Microsoft Azure Red Hat OpenShift（ARO）。”

在公共云中运行的托管Kubernetes服务的增长，以及在任何云中运行的商业平台，包括自己的数据中心，意味着每个人都有一个选择，包括不希望或不需要建立一个强大的内部团队来管理一切的组织。

Kubecost联合创始人Rob Faraj，预计会出现一种独立但相关的趋势，这种趋势既会影响云原生人才，也会影响商业和托管服务的增长：供应商和内部平台团队将优先考虑使开发人员能够更轻松地使用Kubernetes的功能，而无需解决更复杂的问题。

Faraj说：“组织需要尽一切可能去竞争以吸引开发者，而公司能够提供的关于Kubernetes的开发者体验管理可以——并且将越来越多地——成为一个关键的差异化因素。我认为，到2022年，我们将看到对简化基础设施扩展和围绕Kubernetes管理创建更利于开发的流程的巨大需求。”

5.Kubernetes社区将继续优先重视安全

Kubernetes内置了重要的安全功能，只要你正确调整设置。其蓬勃发展的生态系统也高度重视平台的安全性——OperatorHub.io上有29种不同的安全应用程序，可见一斑。

2022年，企业将使用可用的工具和服务来强化其云和云原生安全战略。红帽的云和DevSecOps策略总监Kirsten Newcomer预测，我们将看到组织在部署时对应用程序进行筛选的方式发生变化。

总的来说，预计整个社区都会继续投资Kubernetes安全性，特别是在简化（而不是降低）团队安全性以及通过将其嵌入到他们用来管理集群的工具中来减少预算。

“Kubernetes发行版将开始直接添加更多安全功能。这将有助于增强发行版的整体安全性，并有助于降低保护Kubernetes部署的成本。”

原文链接：

kubernetes常见故障

kubernetes常见故障

1. 节点CNI不可用，其它节点无法连接到故障节点的Pod

2. Subpath方式挂载的Configmap，特定条件下出现Pod无限重启的问题

3. 集群DNS服务器无法通过上游DNS解析外部名称

4. 节点假死，但是持有的Ceph RBD的Watcher不释放，导致有状态服务的Pod调度走后仍然无法启动

5. 误删Etcd数据、持久卷

有四个有用的命令可以对Pod进行故障排除：

kubectl logs 有助于检索Pod容器的日志

kubectl describe pod 检索与Pod相关的事件列表很有用

kubectl get pod 用于提取存储在Kubernetes中的Pod的YAML定义

kubectl exec -ti bash 在Pod的一个容器中运行交互式命令很有用

常见Pod错误

Pod可能会出现启动和运行时错误。

启动错误包括：

ImagePullBackoff

ImageInspectError

ErrImagePull

ErrImageNeverPull

RegistryUnavailable

InvalidImageName

运行时错误包括：

CrashLoopBackOff

RunContainerError

KillContainerError

VerifyNonRootError

RunInitContainerError

CreatePodSandboxError

ConfigPodSandboxError

KillPodSandboxError

SetupNetworkError

TeardownNetworkError

有些错误比其他错误更常见。

以下是最常见的错误列表以及如何修复它们的方法。

ImagePullBackOff

当Kubernetes无法获取到Pod中某个容器的镜像时，将出现此错误。

共有三个可能的原因：

镜像名称无效-例如，你拼错了名称，或者image不存在

你为image指定了不存在的标签

你尝试检索的image属于一个私有registry，而Kubernetes没有凭据可以访问它

前两种情况可以通过更正image名称和标记来解决。

针对第三种情况，你应该将私有registry的访问凭证通过Secret添加到k8s中并在Pod中引用它。

官方文档中有一个有关如何实现此目标的示例。

CrashLoopBackOff

如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。

通常，在以下情况下容器无法启动：

应用程序中存在错误，导致无法启动

你未正确配置容器

Liveness探针失败太多次

你应该尝试从该容器中检索日志以调查其失败的原因。

如果由于容器重新启动太快而看不到日志，则可以使用以下命令：

$ kubectl logs pod-name –previous 

这个命令打印前一个容器的错误消息。

RunContainerError

当容器无法启动时，出现此错误。

甚至在容器内的应用程序启动之前。

该问题通常是由于配置错误，例如：

挂载不存在的卷，例如ConfigMap或Secrets

将只读卷安装为可读写

你应该使用kubectl describe pod 命令收集和分析错误。

处于Pending状态的Pod

当创建Pod时，该Pod保持Pending状态。

为什么？

假设你的调度程序组件运行良好，可能的原因如下：

集群没有足够的资源（例如CPU和内存）来运行Pod

当前的命名空间具有ResourceQuota对象，创建Pod将使命名空间超过配额

该Pod绑定到一个处于pending状态的 PersistentVolumeClaim

最好的选择是检查kubectl describe命令输出的“事件”部分内容：

$ kubectl describe pod pod name 

对于因ResourceQuotas而导致的错误，可以使用以下方法检查集群的日志：

$ kubectl get events –sort-by=.metadata.creationTimestamp 

处于未就绪状态的Pod

如果Pod正在运行但未就绪(not ready)，则表示readiness就绪探针失败。

当“就绪”探针失败时，Pod未连接到服务，并且没有流量转发到该实例。

就绪探针失败是应用程序的特定错误，因此你应检查kubectl describe中的“ 事件”部分以识别错误。

2. 服务的故障排除

如果你的Pod正在运行并处于就绪状态，但仍无法收到应用程序的响应，则应检查服务的配置是否正确。

service旨在根据流量的标签将流量路由到Pod。

因此，你应该检查的第一件事是服务关联了多少个Pod。

你可以通过检查服务中的端点(endpoint)来做到这一点：

$ kubectl describe service service-name | grep Endpoints 

端点是一对，并且在服务（至少）以Pod为目标时，应该至少有一个端点。

如果“端点”部分为空，则有两种解释：

你没有运行带有正确标签的Pod（提示：你应检查自己是否在正确的命名空间中）

service的selector标签上有错字

如果你看到端点列表，但仍然无法访问你的应用程序，则targetPort可能是你服务中的罪魁祸首。

你如何测试服务？

无论服务类型如何，你都可以使用kubectl port-forward来连接它：

$kubectl port-forward service/service-name 3000:80 

这里：

是服务的名称

3000 是你希望在计算机上打开的端口

80 是服务公开的端口

3.Ingress的故障排除

如果你已到达本节，则：

Pod正在运行并准备就绪

服务会将流量分配到Pod

但是你仍然看不到应用程序的响应。

这意味着最有可能是Ingress配置错误。

由于正在使用的Ingress控制器是集群中的第三方组件，因此有不同的调试技术，具体取决于Ingress控制器的类型。

但是在深入研究Ingress专用工具之前，你可以用一些简单的方法进行检查。

Ingress使用serviceName和servicePort连接到服务。

你应该检查这些配置是否正确。

你可以通过下面命令检查Ingress配置是否正确：

$kubectl describe ingress ingress-name 

如果backend一列为空，则配置中必然有一个错误。

如果你可以在“backend”列中看到端点，但是仍然无法访问该应用程序，则可能是以下问题：

你如何将Ingress暴露于公共互联网

你如何将集群暴露于公共互联网

你可以通过直接连接到Ingress Pod来将基础结构问题与Ingress隔离开。

首先，获取你的Ingress控制器Pod（可以位于其他名称空间中）：

$ kubectl get pods –all-namespaces 

NAMESPACE NAME READY STATUS 

kube-system coredns-5644d7b6d9-jn7cq 1/1 Running 

kube-system etcd-minikube 1/1 Running 

kube-system kube-apiserver-minikube 1/1 Running 

kube-system kube-controller-manager-minikube 1/1 Running 

kube-system kube-proxy-zvf2h 1/1 Running 

kube-system kube-scheduler-minikube 1/1 Running 

kube-system nginx-ingress-controller-6fc5bcc 1/1 Running 

描述它以检索端口：

kubectl describe pod nginx-ingress-controller-6fc5bcc 

–namespace kube-system \ 

| grep Ports 

最后，连接到Pod：

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 –namespace kube-system 

此时，每次你访问计算机上的端口3000时，请求都会转发到Pod上的端口80。

现在可以用吗？

如果可行，则问题出在基础架构中。你应该调查流量如何路由到你的集群。

如果不起作用，则问题出在Ingress控制器中。你应该调试Ingress。

如果仍然无法使Ingress控制器正常工作，则应开始对其进行调试。

目前有许多不同版本的Ingress控制器。

热门选项包括Nginx，HAProxy，Traefik等。

你应该查阅Ingress控制器的文档以查找故障排除指南。

由于Ingress Nginx是最受欢迎的Ingress控制器，因此在下一部分中我们将介绍一些有关调试ingress-nginx的技巧。

调试Ingress Nginx

Ingress-nginx项目有一个Kubectl的官方插件。

你可以用kubectl ingress-nginx来：

检查日志，后端，证书等。

连接到ingress

检查当前配置

你应该尝试的三个命令是：

kubectl ingress-nginx lint，它会检查 nginx.conf

kubectl ingress-nginx backend，以检查后端（类似于kubectl describe ingress ）

kubectl ingress-nginx logs，查看日志

请注意，你可能需要为Ingress控制器指定正确的名称空间–namespace 。

——————————————————————————————————

kubernetes之故障排查和节点维护(二)

系列目录

案例现场:

测试环境集群本来正常,突然间歇性地出现服务不能正常访问,过一会儿刷新页面又可以正常访问了.进入到服务所在的pod查看输出日志并没有发现异常.使用kubectl get node命令正好发现一个节点是NotReady状态

为了方便观察,使用kubectl get node –watch来观测一段时间,发现k8s-node1节点不断的在Ready和NotReady状态之间切换(使用kubectl get node -o wide可以查看节点的ip信息).

进入到出现问题的节点,使用命令journalctl -f -u kubelet来查看kubelet的日志信息,把错误日志截出来一段搜索一下,发现问题和这个问题基本上是一样的,发现这个问题的时间和github上issue提出的时间是在同一天,也没有看到解决办法.但是基本能确定是因为集群中k8s-node1上的kubernetes版本不一致造成的(从上面截图上可以看到,这个节点的版本是1.14.1其它的都是1.13.1,是怎么升上来的不清楚,可能是其它同事误操作升级导致的)

搜索kubernetes NotReady查看了一些解决经验,很多都是重启docker,重启kubectl等,然后都解决不了问题.于是尝试重置这个节点.

从集群中删除Node

由于这个节点上运行着服务,直接删除掉节点会导致服务不可用.我们首先使用kubectl drain命令来驱逐这个节点上的所有pod

kubectl drain k8s-node1 –delete-local-data –force –ignore-daemonsets

以上命令中–ignore-daemonsets往往需要指定的,这是因为deamonset会忽略unschedulable标签(使用kubectl drain时会自动给节点打上不可调度标签),因此deamonset控制器控制的pod被删除后可能马上又在此节点上启动起来,这样就会成为死循环.因此这里忽略daemonset.

实际在使用kubectl drain时候,命令行一直被阻塞,等了很久还在被阻塞.使用kubectl get pod命令查看pod状态时.其中一个叫作busybox的pod一直处于Terminating状态. 使用kubectl delete pod busybox同样无法删除它.这时候可以使用命令kubectl delete pods busybox –grace-period=0 –force来强制马上删除pod.

这时候控制台阻塞状态结束.下面执行命令kubectl delete node k8s-node1来删除这个节点.然后我们重新安装kubelet,kubeadm和kubectl

卸载旧版本

如果是通过yum方式安装的,可以通过yum list installed|grep xxx形式来找到已安装的组件,然后删除它们.删除以后重新安装.

这里之所以要重新安装是因为版本升级成了较为新的版本,如果版本是一样的,其它的不确定因素导致节点不稳定,又找不到具体原因,则可以通过kubeadm reset来重置安装.

重置命令并不会重置设置的iptables规则和IPVS如果想要重置iptables,则需要执行以下命令:

iptables -F iptables -t nat -F iptables -t mangle -F iptables -X

如果想要重置IPVS,则需要执行以下命令:

ipvsadm -C

这里我能够基本确定是由于版本不一致导致的,因此我并不重置iptables和IPVS,仅仅是重装组件.

重新加入集群

重置完成以后,我们把删除掉的k8s-node1节点使用kubeadm join重新加入到集群中

如果忘记了主节点初始化时候生成的加入token,可以在主节点上执行kubeadm token create –print-join-command重新生成加入token,然后把生成的命令复制到要加入集群的节点上执行.

重新加入集群后,观察了一段时间,一直是Ready状态,感觉终于稳定了,但是同事又反馈部署服务时出现以下错误

Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container “5159f7918d520aee74c5a08c8707f34b61bcf1c340bfc444125331034e1f57f6” network for pod “test-58f4789cb7-7nlk8”: NetworkPlugin cni failed to set up pod “test-58f4789cb7-7nlk8_default” network: failed to set bridge addr: “cni0” already has an IP address different from 10.244.4.1/24

幸好有伟大的互联网,通过搜索,找到以下解决方案

由于这次启动以后初次部署pod就失败了,因此此节点上还没有运行的服务,我们不需要执行kubectl drain,可以直接把这个节点删除.然后执行以下命令

kubeadm reset

systemctl stop kubelet

systemctl stop docker

rm -rf /var/lib/cni/

rm -rf /var/lib/kubelet/*

rm -rf /etc/cni/

ifconfig cni0 down

ifconfig flannel.1 down

ifconfig docker0 down

ip link delete cni0

ip link delete flannel.1

systemctl start docker

完了以后重新加入集群.这次可以正常工作了.

—————————————————————–

Kubernetes——Pod控制器详解

Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。

在kubernetes中，有很多类型的pod控制器，每种都有自己的适合的场景，常见的有下面这些：

ReplicaSet的主要作用是 保证一定数量的pod正常运行 ，它会持续监听这些Pod的运行状态，一旦Pod发生故障，就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级。

在这里面，需要新了解的配置项就是 spec 下面几个选项：

创建pc-replicaset.yaml文件，内容如下：

为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。值得一提的是，这种控制器并不直接管理pod，而是通过管理ReplicaSet来简介管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。

创建pc-deployment.yaml，内容如下：

deployment支持两种更新策略: 重建更新 和 滚动更新 ，可以通过 strategy 指定策略类型，支持两个属性:

滚动更新的过程：

镜像更新中rs的变化：

deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看.

kubectl rollout： 版本升级相关功能，支持下面的选项：

Deployment控制器支持控制更新过程中的控制，如“暂停(pause)”或“继续(resume)”更新操作。

比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

删除Deployment

在上面，我们已经可以实现通过手工执行 kubectl scale 命令实现Pod扩容或缩容，但是这显然不符合Kubernetes的定位目标——自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况，实现pod数量的自动调整，于是就产生了Horizontal Pod Autoscaler（HPA）这种控制器。

HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。

接下来，我们来做一个实验

metrics-server可以用来收集集群中的资源使用情况

为了操作简单，直接使用命令

创建pc-hpa.yaml

使用压测工具对service地址 192.168.109.100:31136 进行压测，然后通过控制台查看hpa和pod的变化

hpa变化

deployment变化

pod变化

DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建。

DaemonSet控制器的特点：

下面先来看下DaemonSet的资源清单文件

创建pc-daemonset.yaml，内容如下：

Job，主要用于负责 批量处理(一次要处理指定数量任务) 短暂的 一次性(每个任务仅运行一次就结束) 任务。Job特点如下：

Job的资源清单文件：

创建pc-job.yaml，内容如下：

CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行 时间点 及 重复运行 的方式。也就是说， CronJob可以在特定的时间点(反复的)去运行job任务 。

CronJob的资源清单文件：

需要重点解释的几个选项：

schedule: cron表达式，用于指定任务的执行时间

创建pc-cronjob.yaml，内容如下：

参考：

本文来源：https://www.yuntue.com/post/122698.html | 云服务器网，转载请注明出处！