随着 Kubernetes 不断彻底改变我们管理和部署应用程序的方式，了解其复杂性对于开发人员和运营团队来说都变得至关重要。如果您没有专门的 DevOps 团队，您可能不应该使用 Kubernetes。尽管如此，在某些情况下，当我们调试问题时，DevOps 工程师可能不在。对于这些情况以及一般的熟悉程度，我们仍然应该熟悉常见的 Kubernetes 问题，以弥合开发和运营之间的差距。我认为这也提供了一项重要技能，可以帮助我们更好地理解 DevOps 的工作，有了这种理解，我们可以提高团队的凝聚力。本指南探讨了常见的 Kubernetes 错误，并提供了故障排除技巧，以帮助开发人员驾驭复杂的容器编排环境。



https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/7c6c52c1a5cbc4124559dd516d33072d.jpg


识别配置问题

在 Kubernetes 中遇到配置问题时，首先要检查的是使用kubectl get pods命令的状态列。常见错误会在这里出现，需要使用 进行进一步检查kubectl describe pod。



https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/7ef9e54308d844313144c28cef61c63f.jpg


常见原因和解决方案

资源不足：请注意，这指的是 POD 本身的资源，而不是容器内的资源。这意味着硬件或周围的 VM 已达到极限。
症状：由于资源限制，Pod 无法调度。
解决方案：通过添加更多节点来扩大集群以满足资源需求。
卷安装失败：
症状：Pod 无法正确挂载卷。
解决方案：确保在 pod 规范中准确定义存储，并检查存储类和持久卷 (PV) 配置。


详细调查步骤

我们可以使用kubectl describe pod：此命令提供 pod 的详细描述，包括已发生的事件。通过检查这些事件，我们可以查明问题的确切原因。

另一个重要步骤是资源配额分析。有时，资源限制是由于命名空间级别的资源配额造成的。用于kubectl get resourcequotas检查配额是否限制了 Pod 的创建。

处理镜像拉取错误

错误类似于ErrImagePull或ImagePullBackOff表示获取容器映像时出现问题。这些错误通常与映像可用性或访问权限有关。

故障排除步骤

第一步是检查图像名称，我们可以使用以下命令执行此操作：



https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/173bbcad7f31986153b669e4c294c2fb.jpg


然后我们需要验证图像名称是否存在拼写错误或无效字符。我通过 grep 管道传输命令来验证名称是否 100% 相同，有些拼写错误很难发现。

凭证也可能是一个重大陷阱。例如，从私有存储库提取图像时授权失败。

我们必须确保 Docker 注册表凭据在 Kubernetes 机密中正确配置。

还应检查网络配置。确保 Kubernetes 节点可以通过网络访问 Docker 注册表。网络策略或防火墙规则可能会阻止访问。

还有不少其他陷阱，例如图像标签问题。确保您使用正确的图像标签。最新标签可能并不总是指向预期的图像版本。

如果您使用的是私有注册表，则可能会遇到访问问题。请确保您的凭据是最新的，并且注册表可从所有区域的所有节点访问。

处理节点问题

与节点相关的错误通常指向物理机或虚拟机问题。这些问题可能会破坏 Kubernetes 集群的正常运行，需要立即引起注意。

要检查节点状态，请使用以下命令：



https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/dacdf7c3592c574d4053f69972df2c4a.jpg


然后我们可以在结果输出中识别有问题的节点。

虽然这是老生常谈，但有时重启节点是解决某些问题的最佳方法。我们可以重启受影响的机器或虚拟机。Kubernetes 应该尝试“自我修复”并在几分钟内恢复。

要调查节点状况，我们可以使用以下命令：



https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/7a49ae7653bb105754b99ef056bdc834.jpg


我们应该寻找诸如MemoryPressure、DiskPressure或 之类的条件NetworkUnavailable。这些条件为我们应在节点中解决的根本问题提供了线索。

预防措施

节点监控应与 Prometheus、Grafana 等工具配合使用，以监控节点的健康和性能。这些工具对于解决 Kubernetes 的低级问题非常有用，我们也可以将它们用于解决高级应用程序问题。

我们可以利用一些自动修复工具（例如 Kubernetes Cluster Autoscaler）根据工作负载需求自动管理集群中的节点数量。就我个人而言，我不太喜欢这些工具，因为我担心连锁故障会引发额外的资源消耗。

管理缺失的配置密钥或机密

缺少配置密钥或机密是中断 Kubernetes 部署的常见问题。正确管理这些元素对于顺利运行至关重要。

我们需要使用 ConfigMap 和 Secret。它们让我们可以安全地存储配置值和敏感信息。为了避免这种情况，我们需要确保 ConfigMap 和 Secrets 在您的 pod 规范中得到正确引用。

使用以下命令检查 pod 描述：



https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/21d6b2bd1af28284326578eddfd73949.jpg


查看输出并查找缺少的配置详细信息。纠正任何错误配置。

可以使用以下命令验证 ConfigMap 和 secret 创建：



https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/0ffa1238561ef2a7d723ca4ebf004b2f.jpg

https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/30b98cb2d701506f58bb662c5d6232c0.jpg


确保所需的 ConfigMap 和 Secrets 存在于命名空间中并包含预期的数据。

最好将 ConfigMap 的非敏感部分保留在版本控制中，同时排除 Secret 以确保安全。此外，您应该针对不同的环境（开发、暂存、生产）使用不同的 ConfigMap 和 Secret，以避免配置泄露。

利用 Buildg 进行交互式调试

Buildg 是一个相对较新的工具，它通过允许交互式调试来增强 Docker 配置的调试过程。

它以类似于标准调试的方式为配置问题提供交互式调试。它允许我们逐步完成各个Dockerfile阶段并设置断点。Buildg 通过调试适配器协议 (DAP) 与 VSCode 和其他 IDE 兼容。

Buildg 让我们在构建过程的每个阶段检查容器状态，以便尽早发现问题。

结论

调试 Kubernetes 可能具有挑战性，但只要具备正确的知识和工具，开发人员就可以有效地识别和解决常见问题。通过了解配置问题、镜像拉取错误、节点问题以及 ConfigMaps 和 Secrets 的重要性，开发人员可以为更强大、更可靠的 Kubernetes 部署做出贡献。Buildg 等工具在交互式调试方面取得了有希望的进步，进一步缩小了开发和运营之间的差距。

随着 Kubernetes 的不断发展，了解新工具和最佳实践对于成功管理和部署应用程序至关重要。通过主动解决这些常见问题，开发人员可以确保 Kubernetes 运行更顺畅、更高效，最终实现更具弹性和可扩展的应用程序。




调试 Kubernetes - 故障排除指南

大型语言模型是 2023 年生成式人工智能热潮背后的推动力。然而，它们已经存在了一段时间了。
LLM是黑盒 AI 系统，它使用深度学习对超大数据集进行处理，以理解和生成新文本。现代 LLM 开始成型于 2014 年，当时一篇题为“通过联合学习对齐和翻译的神经机器翻译”的研究论文中引入了注意力机制（一种旨在模仿人类认知注意力的机器学习技术）。2017 年，另一篇论文“注意力就是你所需要的”中引入了 Transformer 模型，这种注意力机制得到了进一步完善。
当今一些最著名的语言模型都是基于 transformer 模型的，包括生成式预训练 transformer 系列LLM 和来自 transformer 的双向编码器表示 (BERT)。
ChatGPT运行在 OpenAI 的一组语言模型上，在 2022 年发布后仅两个月就吸引了超过 1 亿用户。此后，许多竞争模型相继发布。其中一些属于谷歌和微软等大公司；另一些则是开源的。
以下是当今最相关的一些大型语言模型。它们进行自然语言处理并影响未来模型的架构。
BERT
BERT是 Google 于 2018 年推出的 LLM 系列。BERT 是一种基于 Transformer 的模型，可以将数据序列转换为其他数据序列。BERT 的架构是 Transformer 编码器的堆栈，具有 3.42 亿个参数。BERT 在大量数据上进行了预训练，然后进行了微调以执行特定任务以及自然语言推理和句子文本相似性。它被用于提高 Google 搜索 2019 年迭代中的查询理解能力。
Claude 
Claude 法学硕士专注于体质人工智能，它以一系列原则为指导塑造人工智能输出，这些原则有助于它所支持的人工智能助手有用、无害且准确。Claude 由 Anthropic 公司创建。Claude 法学硕士的最新版本是 Claude 3.0。
Cohere
Cohere 是一个企业 AI 平台，提供多种 LLM，包括 Command、Rerank 和 Embed。这些LLM 可以根据特定公司的用例进行定制训练和微调。创建 Cohere LLM 的公司是由《Attention Is All You Need》的作者之一创立的。Cohere 的优势之一是它不依赖于单一云——不像 OpenAI 那样依赖于 Microsoft Azure。
Ernie
Ernie 是百度的大型语言模型，为 Ernie 4.0 聊天机器人提供支持。该机器人于 2023 年 8 月发布，已拥有超过 4500 万用户。据传 Ernie 拥有 10 万亿个参数。该机器人最适合普通话，但也能够处理其他语言。
Falcon  40B
Falcon 40B 是一种基于 Transformer 的因果解码器专用模型，由技术创新研究所开发。它是开源的，并基于英语数据进行训练。该模型还有两个较小的版本：Falcon 1B 和 Falcon 7B（10 亿和 70 亿个参数）。亚马逊已在Amazon SageMaker上提供 Falcon 40B 。它也可以在 GitHub 上免费获取。
Gemini
Gemini是 Google 的 LLM 系列，为该公司的同名聊天机器人提供支持。该模型取代了 Palm 为聊天机器人提供支持，在模型切换后，聊天机器人从 Bard 更名为 Gemini。Gemini 模型是多模式的，这意味着它们可以处理图像、音频和视频以及文本。Gemini 还集成在许多 Google 应用程序和产品中。它有三种尺寸——Ultra、Pro 和 Nano。Ultra 是最大、功能最强大的模型，Pro 是中端模型，Nano 是最小的模型，专为提高设备上任务的效率而设计。Gemini 在大多数评估基准上都优于 GPT-4。
Gemma
Gemma是 Google 的开源语言模型系列，使用与 Gemini 相同的资源进行训练。Gemma 有两种规模——20 亿参数模型和 70 亿参数模型。Gemma 模型可以在个人电脑本地运行，并且在多个评估基准上超越了类似规模的 Llama 2 模型。
GPT-3
GPT-3是 OpenAI 于 2020 年发布的大型语言模型，拥有超过 1750 亿个参数。GPT-3 采用仅解码器的 Transformer 架构。2022 年 9 月，微软宣布独家使用 GPT-3 的底层模型。GPT-3 比其前身大 10 倍。GPT-3 的训练数据包括 Common Crawl、WebText2、Books1、Books2 和 Wikipedia。
GPT-3 是 OpenAI 公开参数计数的 GPT 系列模型中的最后一款。GPT 系列于 2018 年首次推出，当时 OpenAI 发表了一篇论文《通过生成式预训练提高语言理解能力》。
GPT-3.5
GPT-3.5 是 GPT-3 的升级版，参数更少。GPT-3.5 使用来自人类反馈的强化学习进行了微调。GPT-3.5 是支持 ChatGPT 的 GPT 版本。据 OpenAI 称，有几种模型，其中 GPT-3.5 turbo 是最强大的。GPT-3.5 的训练数据延伸到 2021 年 9 月。
它也曾被集成到 Bing 搜索引擎中，但后来被 GPT-4 取代。
GPT-4
GPT-4是OpenAI 的 GPT 系列中最大的模型，于 2023 年发布。与其他模型一样，它也是基于 Transformer 的模型。与其他模型不同的是，它的参数数量尚未向公众公布，尽管有传言称该模型的参数数量超过 170 万亿。OpenAI 将 GPT-4 描述为多模态模型，这意味着它可以处理和生成语言和图像，而不仅限于语言。GPT-4 还引入了系统消息，让用户可以指定语调和任务。
GPT-4 在多项学术考试中表现出了与人类水平相当的表现。在该模型发布时，有人猜测 GPT-4 已经接近通用人工智能(AGI)，这意味着它与人类一样聪明甚至比人类更聪明。GPT-4 为 Microsoft Bing 搜索提供支持，可在 ChatGPT Plus 中使用，最终将集成到 Microsoft Office 产品中。
GPT-4o
GPT-4 Omni（GPT-4o）是 OpenAI 的 GPT-4 继任者，与之前的模型相比有多项改进。GPT-4o 为 ChatGPT 创造了更自然的人机交互，是一个大型多模态模型，接受音频、图像和文本等各种输入。对话让用户可以像在正常的人类对话中一样参与，实时互动还可以捕捉情绪。GPT-4o 可以在交互过程中查看照片或屏幕并提出相关问题。
GPT-4o 的响应时间仅为 232 毫秒，与人类的响应时间相似，比 GPT-4 Turbo 更快。GPT-4o 模型是免费的，将提供给开发者和客户产品。
Lamda
Lamda（对话应用语言模型）是 Google Brain 于 2021 年发布的 LLM 系列。Lamda 使用了仅解码器的转换器语言模型，并在大量文本语料库上进行了预训练。2022 年，当时的谷歌工程师 Blake Lemoine 公开声称该程序具有感知能力， LaMDA 引起了广泛关注。它建立在 Seq2Seq 架构上。
Llama
大型语言模型 Meta AI (Llama) 是 Meta 于 2023 年发布的 LLM。最大版本的大小为 650 亿个参数。Llama 最初发布给经批准的研究人员和开发人员，但现在已开源。Llama 的规模较小，使用、测试和实验所需的计算能力较少。
Llama 使用转换器架构，并在各种公共数据源上进行训练，包括 CommonCrawl、GitHub、Wikipedia 和 Project Gutenberg 的网页。Llama 被有效泄露并衍生出许多后代，包括 Vicuna 和 Orca。
Mistral 
Mistral 是一个 70 亿参数的语言模型，在所有评估基准上都优于 Llama 类似规模的语言模型。Mistral 还拥有一个经过微调的模型，专门用于遵循指令。其较小的尺寸使其能够实现自托管，并具有出色的业务性能。它是根据 Apache 2.0 许可证发布的。
Orca
Orca 由微软开发，拥有 130 亿个参数，这意味着它足够小，可以在笔记本电脑上运行。它旨在通过模仿 LLM 实现的推理过程来改进其他开源模型所取得的进步。Orca 以明显更少的参数实现了与 GPT-4 相同的性能，并且在许多任务上与 GPT-3.5 相当。Orca 建立在 130 亿个参数版本的 LLaMA 之上。
Pathways 
Pathways 语言模型是谷歌推出的一款基于 5400 亿参数转换器的模型，为它的 AI 聊天机器人Bard提供支持。该模型在多个TPU 4 Pod（谷歌为机器学习定制的硬件）上进行训练。Palm 擅长推理任务，例如编码、数学、分类和问答。Palm 还擅长将复杂任务分解为更简单的子任务。
PaLM 的名称源自 Google 的一项研究计划，该计划旨在构建 Pathways，最终创建一个单一模型，作为多种用例的基础。Palm 有多个经过微调的版本，包括用于生命科学和医疗信息的 Med-Palm 2 以及用于网络安全部署以加快威胁分析的 Sec-Palm。
Phi-1
Phi-1 是微软推出的一款基于 Transformer 的语言模型。Phi-1 仅包含 13 亿个参数，在一系列教科书级数据上训练了四天。Phi-1 是使用更高质量数据和合成数据进行训练的小型模型趋势的一个例子。
特斯拉前人工智能总监、OpenAI 员工 Andrej Karpathy 在推文中写道：“我们可能会看到更多富有创意的缩减工作量的做法：优先考虑数据质量和多样性而不是数量，生成更多的合成数据，以及小型但功能强大的专家模型。”
Phi-1 专注于Python编码，由于规模较小，通用能力较差。
StableLM
StableLM 是 Stability AI 开发的一系列开源语言模型，该公司是图像生成器 Stable Diffusion 的幕后推手。截至撰写本文时，已有 30 亿和 70 亿参数模型可用，150 亿、300 亿、650 亿和 1750 亿参数模型正在开发中。StableLM 的目标是透明、可访问且支持性强。
Vicuna 33B
Vicuna 是另一个有影响力的开源 LLM，源自 Llama。它由 LMSYS 开发，并使用 sharegpt.com 的数据进行了微调。根据几个基准测试，它比 GPT-4 更小、功能更弱，但对于其大小的模型来说，它表现不错。Vicuna 只有 330 亿个参数，而 GPT-4 有数万亿个参数。




2024 年 19 种最佳大型语言模型

https://devopsnow-website-1251941469.cos.ap-guangzhou.myqcloud.com/public/b0e4dde8e841f0d070ecaa6676925600.png

分布式系统：常见的陷阱和复杂性

开发者图鉴 | 什么是DevSecOps？

优维“统一开放平台”：开放、开发、集成、客制化

调试 Kubernetes - 故障排除指南

开发者图鉴 | API网关是做什么的？

优维“态势感知监控”产品：像“上帝”一样掌控应用系统

2024 年 19 种最佳大型语言模型

优维运营治理三件套：可用性x性能x容量管理

优维「Easy分析」：一款故障根因分析小神器

14 个必须了解的微服务设计原则

优维科技Easy DevOps全栈运维平台国产化认证5连击

金融行业| 光大银行打造智能化运维支撑数字化业务运营

云智一体|产业类客户案例解析

IT资源轻松管理！优维架构&模型视图上线啦！

案例｜优维＆百丽打造传统行业统一运维平台

案例| 优维&东莞银行打造自动化运维平台

UGeek大咖说第十二期 | 大咖云集：可观测性的应用创新与落地研讨会

涨知识| 什么是个人碳账户？如何使用？

UGeek大咖说第十一期 | B站：以SLO为核心的可用性观测与质量运营

优维案例|智慧监狱优维一体化管控平台解决方案

分布式系统：常见的陷阱和复杂性

开发者图鉴 | 什么是DevSecOps？

优维“统一开放平台”：开放、开发、集成、客制化

调试 Kubernetes - 故障排除指南

开发者图鉴 | API网关是做什么的？

优维“态势感知监控”产品：像“上帝”一样掌控应用系统

2024 年 19 种最佳大型语言模型

优维运营治理三件套：可用性x性能x容量管理

优维「Easy分析」：一款故障根因分析小神器

14 个必须了解的微服务设计原则

优维科技Easy DevOps全栈运维平台国产化认证5连击

金融行业| 光大银行打造智能化运维支撑数字化业务运营

云智一体|产业类客户案例解析

IT资源轻松管理！优维架构&模型视图上线啦！

案例｜优维＆百丽 打造传统行业统一运维平台

案例| 优维&东莞银行 打造自动化运维平台

UGeek大咖说第十二期 | 大咖云集：可观测性的应用创新与落地研讨会

涨知识| 什么是个人碳账户？如何使用？

UGeek大咖说第十一期 | B站：以SLO为核心的可用性观测与质量运营

优维案例|智慧监狱 优维一体化管控平台解决方案

案例｜优维＆百丽打造传统行业统一运维平台

案例| 优维&东莞银行打造自动化运维平台

优维案例|智慧监狱优维一体化管控平台解决方案