搜索[k8s]结果-低调大师优秀个人博客

精选列表

搜索[k8s]，共3940篇文章

借助 Okta 和 NGINX Ingress Controller 实现 K8s OpenID Connect 身份验证

原文作者：Amir Rawdat - F5 NGINX 技术营销工程师原文链接：借助 Okta 和 NGINX Ingress Controller 实现 K8s OpenID Connect 身份验证

2026-01-28

每日一博 | 基于 K8s 容器集群的容灾架构与方案

本文介绍如何以 K8s 集群（包括：ACK 集群，他云集群和本地 IDC K8s 集群）为基础，结合阿里云云产品（网络，数据库，中间件，可观测），设计容灾架构，构建一个“韧性”系统。

2024-03-17

最后的组合：K8s 1.24 基于 Hekiti 实现 GlusterFS 动态存储管理实践

mapper/openeuler-root 17G 1.6G 15G 10% / tmpfs 1.7G 0 1.7G 0% /tmp /dev/sda1 974M 151M 756M 17% /boot K8s

2023-07-28

Rancher Prime 为平台工程提供面向 K8s 的弹性能力

release 后，Rancher Prime 在多云多 K8s 集群管理领域已然遥遥领先，可以随时随地管理和部署任意位置的 K8s 集群。

2023-03-01

K8S优雅升级系列（中） | 如何“优雅”滚动发布？看这篇就够了

如何优雅滚动发布前面一篇讲了微服务应用发布方式、应用优雅下线以及容器优雅关闭的相关内容，接下来就分析下K8S滚动更新中，在什么样的情况下服务会中断以及相关的解决方案。

2022-09-01

上千微服务接入 Zadig 的最佳姿势（K8s YAML 篇）

从现有 Kubernetes 批量导入服务适用：K8s YAML 类型项目的场景，可以直接从现有 K8s 集群的命名空间批量导入服务，几乎无迁移成本。

2022-06-28

微服务从代码到k8s部署应有尽有系列（一）

从本篇文章开始，我们用一个系列来讲解从需求到上线、从代码到k8s部署、从日志到监控等各个方面的微服务完整实践。

2022-02-07

【云端技能包】k8s 知识- 模块化方式认识Statefulset和Deployment

在学习干货前，客官请留步——【“云”住民生存训练营--玩转k8s】本周五，即将在线上开播，扫码一键预约直播！

2021-12-15

K8S 生态周报 | Helm 新版本发布增强对 OCI 的支持

“ 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。

2021-11-04

Docker与k8s的恩怨情仇（一）—成为PaaS前浪的Cloud Foundry

> 转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。大家在工作中或许或多或少都接触过Docker，那你知道Docker以及容器化背后的原理到底是什么吗？容器化技术满天下，那为什么只有Docker被大家所熟知呢？后Docker时代，到底谁才是云原生时代的王者？我们相信本系列文章能帮您解答这些疑惑。被“嫌弃”的物理服务器在云时代以前，开发者如需构建一个线上的站点，必须自己维护物理服务器。但是随着业务发展，大体量服务器逐渐增多，随之而来的是硬件、场地和维护成本的不断提高。对于面向C端的站点来说，网络热点事件具有随机性，流量的变化并不可控，难免会遭遇站内流量暴涨的情况。此时如果没有备用服务器，突发的大流量很可能会冲垮整个站点。但在没有突发事件的时候，备用服务器的采购和维护成本又让人不可忽略。（运维的传统艺能：上线拜祖，图片来自网络）哪里有问题，哪里就有商机。有人想到，如果买一批服务器放在外网，安排专人管理，然后按照用户的需要租赁出去，不正好解决了这个问题吗？于是，一场云计算的好戏，正式上演。虚拟机还是“超重”了云计算时代的大幕拉开，大厂先后登台，让我们先简单做一下回顾。 2006年，亚马逊成立aws，从云端存储业务开始。 2008年，云计算初创。 2009年，阿里云成立。目前最新的数据表明，2020年度IaaS市场份额调查，阿里云位居全球第三，亚太第一；前两名分别是亚马逊和微软，市场份额达9.5%，超过谷歌的6.1%，亚马逊40.8%，微软17%。国内市场份额40% ，第二是华为云，占18%。 2010年，OpenStack由NASA发布。OpenStack是一个IaaS架构，可以用其架构来搭建自己的私有云，让任何人都可以自行创建和提供云计算服务。对比而言，AWS和aliyun都是自研架构，OpenStack是开源的。所以公司如果需要，完全可以接入OpenStack搭建自己的私有云。（当然前提需要有OpenStack核心开发能力）。 2010-2013年之间，云计算的全球份额被aws和OpenStack瓜分。这时的云计算技术，本质都是虚拟化技术，将硬件资源作为基础设施提供给用户，简称IaaS。简单理解，IaaS就是将一个很大的服务器，通过虚拟化技术拆分成多个小的虚拟服务器，提供服务，类似于在本机装了虚拟机。（云计算主力玩家的进场时间，图片来自网络）但是，IaaS时代的虚拟机还是太过于笨重了。每一台虚拟机都需要消耗CPU、内存等计算资源才能支撑应用的运行。即便应用再小，系统的开销都是固定的成本。如何为IaaS减肥，让虚拟机系统的开销降到最低？ 2013年开始，云计算正式进入了PaaS时代。PaaS时代，云计算所销售的单元，从虚拟机变成了应用运行平台。于是，云厂商提供的服务更多，资源利用率也更高了。什么是PaaS？我们用一个通俗的例子来解释。如果我们现在是一个烧饼店老板，采用IaaS模式意味着我们需要用别人厨房、锅炉、煤气，自己和面做馅料，做烧饼。如果是PaaS，我们烧饼的面粉、馅料和调料都是别人提供好了，我们只需要把饼烤熟。云厂商该如何构建一套好用的PaaS服务呢？借力开源项目，成为各厂商的共识。 Cloud Foundry开启PaaS开源时代 PaaS的核心是平台。最早出现在开发者视野中的PaaS开源项目中，vmware创立的Cloud Foundry是知名度最高的。与IaaS提供云上虚拟机的服务方式不同，基于Cloud Foundry的云计算能够提供应用托管的功能。开发者只需要通过一条简单的命令比如：cf push "我的应用"，就可以将项目打成一个压缩包，上传到Cloud Foundry服务器。而Cloud foundry会开启自己的调度器，在一群云主机中找到满足用户需求的主机（系统版本、性能、个数），然后通过容器化技术，在主机上创建一个容器，在容器中下载压缩包，解压并运行，最终成为一个对外提供服务的应用。此外，Cloud Foundry平台对这些应用项目提供分发，灾备，监控，重启等等服务（这也是我们提供给用户的核心服务）。这种托管服务解放了开发者的生产力，让他们不用再关心应用的运维状况，而是专心开发自己的应用。而这就是PaaS的“初心”，平台即服务。（Cloud Foundry提供的服务）这里就会有同学问了，容器是什么？容器是用来解决多个应用资源冲突与隔离性问题的技术。Linux上的namespace机制和cgroups命令都能用做资源隔离和限制，这些都是容器技术。容器技术并不是Docker创建的，在Docker兴起之前，就已经被其他公司商用了，但是为什么现在一谈起容器，所有人第一时间想到的就是Docker呢？这就要提到Cloud Foundry的死亡。从Cloud Foundry到Docker Cloud Foundry似乎已经和我们现在使用的云功能区别不大，但2021年的现实情况却是Cloud Foundry已经死了。我们看过互联网上很多文章，再结合我们活字格公有云开发的经验，我们认为这个项目的致命缺陷集中它的打包机制上。 Cloud Foundry最核心的组件就是应用的打包和分发机制，也是开发者打交道最多的功能。Cloud Foundry为每一种主流的语言都定义了一套打包的方式，这些方式之间毫无章法。但就是这个打包功能，成了Cloud Foundry的软肋，一直为用户所诟病。开发者不得不为每一种语言，每一种框架，甚至是每个版本应用维护一个打好的包，还有可能出现本机运行成功，打了个包上传上去之后就无法运行的情况。情况最严重的时候，开发者在调试云平台系统上花的时间都已经比开发一个新软件的时间要长了。本来是为赋能开发者的而生的技术，Cloud Foundry却对开发者如此不友好。当开发者的抱怨积累到一定程度，想要在PaaS浪潮中央站稳脚跟的Cloud Foundry被后起之秀Docker“红牌罚出局”也就顺理成章了。最初，Docker是一个当时还叫dotCloud的公司（2010年由所罗门海克斯创建，Y Combinator孵化）开发的容器项目。在Cloud Foundry困于打包问题时，Docker正在悄悄积蓄力量，在开源后的短短几个月内就迅速崛起，成为一个不容忽视的PaaS技术方案，吸引了云服务开发者的眼球。滑稽的是，在Docker刚开源的时候，Cloud Foundry的首席产品经理 James Bayer就在社区做了一次详细的对比，告诉用户Docker和Cloud Foundry一样，都是使用了Namespace和Cgroups技术的沙箱而已，没什么值得关注的。事实上，Docker也确实就和他所说的一样，采用了这个“传统”的技术方案，但是Docker与Cloud Foundry相比，做了一点小小的创新，体现了所罗门海克斯的远见。从2010他就开始考虑应用打包的一致性与复用性问题，并提出了创新的解决方案，最终对Cloud Foundry造成了毁灭性的打击。这个解决方案就是Docker镜像。（Docker，图片来自官网）刚开源的Docker迅速爆火，憨态可掬的小鲸鱼，对用户友好的文档，三分钟部署一个Nginx集群的宣传语，以及Docker Image这个 “微不足道的创新”，让Docker席卷整个PaaS领域。 Docker的制胜法宝：镜像 Docker成功的关键，在于Docker镜像几乎完美地解决了Cloud Foundry在打包方面的软肋。所谓的镜像，其实也是一个压缩包，但是比起Cloud Foundry那种执行文件+启动脚本的打包结果，镜像提供给用户的是一套完整的运行环境，每一个镜像都可以指定操作系统版本，内部可以构建程序执行的文件结构，并且一份镜像可以完全共享在多处使用。此外，Docker还给开发者提供了一套完善的镜像制作流程，这套流程与编程语言和框架无关。开发者只需要按照该流程，定制对应程序所需要的运行的操作系统环境即可。总之，Docker 镜像完美解决了两个问题： 1.本地环境和服务器环境的差异 2.同一份镜像可以让所有的机器进行复用从这一刻开始，PaaS的市场已经完全是Docker的天下。小结本文是系列文章的第一期，我们一起回顾了IaaS取代物理服务器，基于IaaS构建PaaS的发展路线。在构建PaaS时，我们经历了Cloud Foundry的衰败，见证了Docker的成功。但是，只依靠Docker就能构建起完整的PaaS服务吗？我们的活字格公有云版最终选择了哪个技术方案？云计算的故事还没有讲完，敬请期待下期精彩内容。

2021-06-16

OpenKruise 如何实现 K8s 社区首个规模化镜像预热能力

作者 | 王思宇（酒祝）来源 | 阿里巴巴云原生公众号前言 OpenKruise 是阿里云开源的云原生应用自动化管理套件，也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀，是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件，也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。 OpenKruise 在 2021.3.4 发布了最新的 v0.8.0 版本（ChangeLog），其中一个主要变动是新增了 **镜像预热 **能力。本文由《通过 OpenKruise 实现大规模集群镜像预热&部署发布加速实践》分享整理为文字，为大家介绍我们所提供的镜像预热能力的需求来源、实现方式以及使用场景。背景：为什么镜像预热能力是必要的 “镜像” 也算是 Docker 为容器领域带来的一大创新。在 Docker 之前，虽然 Linux 已经提供了 cgroup 隔离，尽管阿里巴巴从 2011 年已经逐渐基于 LXC 开始容器化，但都缺乏镜像这种对运行环境的封装。不过呢，尽管镜像为我们带来了诸多好处，但不可否认在实际场景中我们也面临各种各样拉镜像带来的问题，其中最常见的一点就是拉镜像的耗时。我们过去听到过很多用户对容器化的期待和认识，比如 “极致弹性”、“秒级扩容”、“高效发布” 等等，但结合 Kubernetes 中一个标准的 Pod 创建过程来看，和用户的期望还是有一定差距的（假设 Pod 中包含 sidecar、app 两个容器）：正常来说，对于小规模集群中调度、分配/挂载远程盘、分配网络等操作耗时较小，对于大规模集群需要做一定优化，但都还在可控的范围内。然而对于拉镜像的耗时，在大规模弹性的集群中则尤为棘手，即使采用了 P2P 等技术手段来优化，对于一个较大的业务镜像还是可能需要较长的时间来拉取，与用户所期望的扩容、发布速度不符。而我们如果能做到将 sidecar 容器的镜像、以及业务容器的基础镜像提前在节点上拉取好，则 Pod 创建过程可以大幅缩短，其中拉镜像的耗时甚至能优化 70% 以上：而 Kubernetes 自身是没有提供任何面向镜像的操作能力的，围绕 Kubernetes 的生态来看，目前也没有比较成熟的规模化镜像预热产品。这是我们在 OpenKruise 中提供镜像预热的原因，并且这套镜像预热能力已经在阿里巴巴内部的云原生环境大面积落地，在后文的实践中也会简单介绍我们的基本用法。 OpenKruise 是如何实现镜像预热的 OpenKruise 实现镜像预热的原理，要先从它的运行架构看起：从 v0.8.0 开始，安装了 Kruise 之后，有两个在 kruise-system 命名空间下的组件：kruise-manager 与 kruise-daemon。前者是一个由 Deployment 部署的中心化组件，一个 kruise-manager 容器（进程）中包含了多个 controller 和 webhook；后者则由 DaemonSet 部署到集群中的节点上，通过与 CRI 交互来绕过 Kubelet 完成一些扩展能力（比如拉取镜像、重启容器等）。因此，Kruise 会为每个节点（Node）创建一个同名对应的自定义资源：NodeImage，而每个节点的 NodeImage 里写明了在这个节点上需要预热哪些镜像，因此这个节点上的 kruise-daemon 只要按照 NodeImage 来执行镜像的拉取任务即可：如上图所示，我们在 NodeImage 中能指定要拉取的镜像名、tag、拉取的策略，比如单次拉取的超时、失败重试次数、任务的 deadline、TTL 时间等等。有了 NodeImage，我们也就拥有了最基本的镜像预热能力了，不过还不能完全满足大规模场景的预热需求。在一个有 5k 个节点的集群中，要用户去一个个更新 NodeImage 资源来做预热显然是不够友好的。因此，Kruise 还提供了一个更高抽象的自定义资源 ImagePullJob：如上图所示，在 ImagePullJob 中用户可以指定一个镜像要在哪些范围的节点上批量做预热，以及这个 job 的拉取策略、生命周期等。一个 ImagePullJob 创建后，会被 kruise-manager 中的 imagepulljob-controller 接收到并处理，将其分解并写入到所有匹配节点的 NodeImage 中，以此来完成规模化的预热。整体的流程如下：而有了镜像预热能力后，我们怎么去使用它，或者说什么场景下需要来使用呢？接下来我们介绍下镜像预热在阿里巴巴中的几种常见使用方式。常见的镜像预热使用方式有哪些 1. 基础镜像 – 集群维度预热最常见的预热场景，是在整个集群维度持续预热一些基础镜像： apiVersion: apps.kruise.io/v1alpha1 kind: ImagePullJob metadata: name: base-image-job spec: image: xxx/base-image:latest parallelism: 10 completionPolicy: type: Never pullPolicy: backoffLimit: 3 timeoutSeconds: 300 如上述 ImagePullJob 有几个特征：不配置 selector 规则，即默认整个集群维度预热存量的节点上统一预热后续新增（导入）的节点上也会立即自动做预热采用 Never 的 completionPolicy 策略来长期运行 Never 策略表明这个 job 持续做预热，不会结束（除非被删除） Never 策略下，ImagePullJob 每隔 24h 左右会触发在所有匹配的节点上重试拉取一次，也就是每天都会确保一次镜像存在根据我们的经验，一个集群中预热基础镜像的 ImagePullJob 在 10~30 个左右，具体视集群以及业务场景而定。 2. sidecar 镜像 – 集群维度预热我们同样也可以对一些 sidecar 的镜像做预热，尤其是那些基本上每个业务 Pod 中都会带有的基础 sidecar： apiVersion: apps.kruise.io/v1alpha1 kind: ImagePullJob metadata: name: sidecar-image-job spec: image: xxx/sidecar-image:latest parallelism: 20 completionPolicy: type: Always activeDeadlineSeconds: 1800 ttlSecondsAfterFinished: 300 pullPolicy: backoffLimit: 3 timeoutSeconds: 300 如上述 ImagePullJob 有几个特征：不配置 selector，默认整个集群维度预热，这一点与基础镜像类似采用 Always 策略一次性预热所有节点做一次预热整个 job 预热超时时间 30min job 完成后过 5min 自动删除当然，这里的 sidecar 预热也可以配置为 Never 策略，视场景而定。以我们的经验来看，尤其在 sidecar 做版本迭代、镜像升级的时候，提前做一次规模化的镜像预热，可以大幅提升后续 Pod 扩容、发布的速度。 3. 特殊业务镜像 – 资源池维度预热对于一些多租的 Kubernetes 集群中会存在多个不同的业务资源池，其中可能需要将一些特定的业务镜像按资源池维度来预热： apiVersion: apps.kruise.io/v1alpha1 kind: ImagePullJob metadata: name: serverless-job spec: image: xxx/serverless-image:latest parallelism: 10 completionPolicy: type: Never pullPolicy: backoffLimit: 3 timeoutSeconds: 300 selector: matchLabels: resource-pool: serverless 如上述 ImagePullJob 有几个特征：采用 Never 策略长期预热指定 selector 预热范围，是匹配 resource-pool=serverless 标签的节点当然，这里只是以资源池为例，用户可以根据自身的场景来定义在哪些节点上预热某种镜像。版本前瞻：原地升级与预热的结合最后，再来介绍下 OpenKruise 的下个版本（v0.9.0）中，我们会基于当前的镜像预热实现怎样的增强能力呢？之前对 OpenKruise 了解过的同学一定知道，我们提供的一大特性就是 “原地升级”，即打破了 Kubernetes 原生 workload 发布时必须将 Pod 删除、重建的模式，支持在原 Pod 上只更新其中某个容器的镜像。对原地升级原理感兴趣的同学可以读这篇文章：《揭秘：如何为 Kubernetes 实现原地升级？》。由于原地升级避免了 Pod 删除、重建的过程，它本身已经能为我们带来了如下的好处：节省了调度的耗时，Pod 的位置、资源都不发生变化节省了分配网络的耗时，Pod 还使用原有的 IP 节省了分配、挂载远程盘的耗时，Pod 还使用原有的 PV（且都是已经在 Node 上挂载好的）节省了大部分拉取镜像的耗时，因为节点上已经存在了应用的旧镜像，当拉取新版本镜像时只需要下载少数的几层 layer 原地升级 Pod 中某个容器时，其他容器保持正常运行，网络、存储均不受影响其中，“节省了大部分拉取镜像的耗时” 后，只需要下载新镜像上层的部分 layer 即可。而我们有没有可能把这个镜像拉取时间彻底优化掉呢？答案是肯定的。如上图所示，在下个版本中 OpenKruise 的 CloneSet 将支持发布过程自动镜像预热。当用户还在灰度升级第一批 Pod 的时候，Kruise 会提前在后续 Pod 所在节点上把新版本的镜像预热好。这样一来，在后续批次的 Pod 做原地升级时候，新镜像都已经在节点上准备好了，也就节省了真正发布过程中的拉镜像耗时。当然，这种 “发布+预热” 的模式也只适用于 OpenKruise 的原地升级场景。对于原生 workload 如 Deployment 而言，由于发布时 Pod 是新建出来的，我们无法提前预知到它会被调度到的节点，自然也就没办法提前把镜像预热好了。如果大家对 OpenKruise 项目感兴趣，有任何希望交流的话题，欢迎大家访问 OpenKruise 官网、GitHub，以及钉钉搜索群号：23330762，加入交流群！

2021-03-25

Kubernetes实战指南（三十四）：高可用安装K8s集群1.20.x

安装说明虽然K8s 1.20版本宣布将在1.23版本之后将不再维护dockershim，意味着K8s将不直接支持Docker，不过大家不必过于担心。

2020-12-12

解决k8s集群环境内存不足导致容器被kill问题

背景最近线上环境上出现了一个问题， k8s集群环境Pod中的tomcat容器运行一段时间后直接被killd，但有时一切看起来正常，不能准确判断在什么时机出现被Killd问题。

2020-10-15

处理一次k8s、calico无法分配podIP的心路历程

network: netplugin failed but error parsing its diagnostic message "": unexpected end of JSON input 会k8s

2020-10-13

将原生 K8s 下放边缘计算：阿里云 OpenYurt 成为 CNCF 沙箱项目

在 K8s 一统云计算服务端开发之际，有开发者开始探索用它来管理边缘端的资源调度和编排。

2020-09-18

K8S的名称空间创建&&版本的升级、回滚操作

客户端访问k8s群集中的任意一个节点的31111端口访问其pod提供的服务如果需要在线修改pod提供的网页文件，可以先查看到pod的name，然后直接在主节点上登录到此pod即可，命令如下 [root@

2020-08-26

Jenkins在K8s下的三种部署流程和实战演示

【讲座整理】一般来说，Jenkins在K8s上部署，无论是有状态运维也好，或者无状态运维也好，无非通过以下三个手段进行：第一，原生控制器和资源，即利用已有的K8s基础架构和技术控制器，如deployment

2020-05-25

ASP.NET Core on K8S深入学习（13）Ocelot API网关接入

本篇已加入《.NET Core on K8S学习实践系列文章索引》，可以点击查看更多容器化技术相关系列文章。

2020-05-15

基于centos 7.2部署k8s v1.18.0集群

基于centos 7.2部署k8s v1.18.0集群最近k8s的官方版本已经更新到最新版本，小编在centos7.2的系统上部署最新的v1.18.0并将安装步骤记录下来，本文对k8s的基础知识不做介绍

2020-04-09

Ansible-在云原生K8S环境中有多大用处？(翻译)

前言最近经常被问到这么一个问题：在K8S项目中你为啥还在用Ansible呢？下一个问题往往是：既然你已经开始用K8S,为啥还要写《Ansible for Kubernetes》这么一本书呢？

2020-04-04

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。