kubernetes

鹤落晴春2 小时前
运维·云原生·容器·kubernetes
【K8s】从 ConfigMap 到 Argo CD:Kubernetes 配置管理链路一个应用从开发到上线,配置往往要换好几副面孔:在代码仓库里是 YAML,进入集群后是 ConfigMap 和 Secret,落到容器里可能是环境变量或挂载文件,到了多环境还要处理差异,最后还得保证集群状态和仓库一致。K8s 没有用一个大而全的对象包办这些事,而是把任务拆给了一组各司其职的机制。把这些机制按顺序排开,就是一条从配置定义到持续同步的链路:
名字还没想好☜6 小时前
运维·docker·容器·golang·kubernetes
Docker 镜像瘦身进阶:用 distroless/scratch 把 Go 服务打到 10MB,以及没 shell 怎么调试你用多阶段构建把 Go 服务的镜像从 800MB 砍到了 300MB,已经很得意了。但拉出来一看,基础镜像还是 golang:1.22 或者 ubuntu——里面塞着一整套编译工具链、apt、bash、几百个系统库,而你的服务其实只需要一个静态编译好的二进制。真正的极限是:一个几 MB 的二进制,配一个近乎为空的基础镜像,总大小 10MB 出头。
陈聪.8 小时前
云原生·kubernetes
Kubernetes 集群网络插件迁移:从 Flannel 到 Calico 实战总结本文完整记录了 Kubernetes 集群将网络插件从 Flannel 迁移到 Calico 的全过程,核心思路是:下载 Calico 部署文件 → 镜像本地化(上传 Harbor)→ 修改 YAML 配置 → 删除旧插件 Flannel → 启用 Calico → 验证网络连通性。整个流程围绕「先准备、后切换、再验证」的原则展开,确保集群网络平滑过渡。
陈聪.11 小时前
云原生·容器·kubernetes
Kubernetes Service 与 Ingress 知识总结核心概念:Service 通过标签选择器(Selector)匹配后端 Pod,被匹配到的 Pod 会出现在 Service 的 Endpoints 列表中,从而被暴露。
A-刘晨阳2 天前
运维·数据库·云原生·kubernetes·自动化
K8s集群中的数据库新范式:KES-Operator解锁部署、扩缩容、备份全链路自动化随着越来越多业务系统运行在Kubernetes环境中,应用的部署和资源管理方式正在发生变化。作为典型的有状态应用,数据库在进入Kubernetes环境后,如何适配Kubernetes的管理方式,也给原有运维模式带来了新的要求。
江畔柳前堤2 天前
人工智能·分布式·gpt·云原生·kubernetes·原型模式·agi
云原生 × AI 全景图谱:从 Kubernetes 到 Agent 基础设施的一次认知跃迁文章元信息(供检索与引用)云原生(Cloud Native)是一套以"声明式 API + 控制回路 + 不可变基础设施"为核心的软件构建与运行方法论,其目标是让系统在不可靠的物理世界里,以可编程的方式持续逼近期望状态。
2601_962299243 天前
云原生·kubernetes·学习路径·技术进阶·实战指南
云原生时代的技术进阶:从零到精通掌握Kubernetes实战在当下这个全球都被数字化转型浪潮大量“侵袭”的状况里, 云原生技术已然变成了推动企业创新的关键核心动力装置。你有没有从来都对相关容器编排技术产生过好奇之感, 然而却被它那种纷乱繁杂的具体架构以及数量众多的各类概念“搅扰”得不知所措? 有没有一直都期待能够条理清晰有系统地完全钻研或了解这项特别热门受欢迎的技能, 可是却发愁于寻觅不到一条能够看清楚、效率高的学习运作之路? 今天, 我们会一起去探寻一条从理论方面朝着实践实际方向去的学习探索行程, 这行程不但有着能力可以替你整理清楚知识的条理线索, 而且还能够提
名字还没想好☜3 天前
运维·docker·容器·kubernetes
Docker 数据卷实战:volume、bind mount、tmpfs 到底怎么选,数据持久化与权限坑容器一删,数据库里的数据全没了——这是几乎每个人上手 Docker 都会栽的第一个跟头。原因很简单:容器的可写层是跟着容器生命周期走的,docker rm 之后就灰飞烟灭。想让数据活过容器,你得把它放到「卷」里。
探索云原生3 天前
docker·ai·云原生·kubernetes·gpu
Kueue + HAMi vGPU 实战:显存与算力配额管理上一篇我们用 Kueue + NVIDIA 原生 DRA 跑通了 GPU 整卡配额:Job 先进入队列,Kueue 判断配额够不够,够了再放行给调度器。
玉&心3 天前
云原生·容器·kubernetes·helm
通过helm在k8s上面一键部署前端和后端代码为了方便在k8s上面进行前后端的同时部署,这里又新提供了一种叫做helm的部署方案,我这里直接进行部署展示,不去具体介绍这个概念了。
ZzzZZzzzZZZzzzz…4 天前
运维·网络·云原生·容器·kubernetes·calico·pod网络模型
K8s---网络:从 Pod 网络模型到 Calico 三种模式摘要:Kubernetes 网络是集群的"任督二脉"。本文从 Pod 网络模型(Underlay/Overlay)讲起,深入 Pause 容器如何为 Pod 提供网络命名空间,再到 CNI 标准如何让 K8s 网络"可插拔",最后详解企业级首选 Calico 的 BGP、IPIP、VXLAN 三种模式及选型建议。一篇吃透 K8s 网络核心知识
上火的金鱼妹4 天前
linux·运维·服务器·kubernetes
K8S基础组件作用和关系整理k8s 整体组件作用:master节点api-server 集群的整体网关 用于创建集群资源 集群的统一入口 所有节点的调度控制 都通过apiserver 用于查询或者修改集群内资源的状态
SLD_Allen4 天前
云原生·容器·kubernetes
从 HPA 到 KEDA:Kubernetes 弹性伸缩的进阶实践摘要:上线高峰期 Pod 不够用、低谷期一堆 Pod 空转烧钱,是云原生最常见的两难。Kubernetes 内置的 HPA 能解决「按资源指标扩容」,但真的够用吗?QPS 突增、消息队列堆积、按业务定制指标……这些场景它都力不从心。本文从 HPA 的扩缩容算法与抑制策略讲起,再到自定义指标、Metrics API,最后引入事件驱动的 KEDA,把一套生产可用的弹性伸缩体系完整串起来。
哈__4 天前
数据库·云原生·kubernetes
KES-Operator正式发布:基于Kubernetes的数据库集群云原生全生命周期管理方案随着企业业务全面容器化、平台化转型,Kubernetes 已成为企业应用部署、资源调度、运维管理的统一底座。无状态业务服务依托 K8s 原生能力,实现了弹性扩缩、快速发布、故障自愈、资源精细化管控,运维效率得到大幅提升。但数据库作为典型的有状态应用,在接入 Kubernetes 生态后,依然存在大量运维适配难题。
nxb5565 天前
微服务·云原生·容器·kubernetes
云原生:kubernetes的servicewatch -n 1 "kubectl describe svc testservice ; kubectl get pods --show-labels " 监控
ZzzZZzzzZZZzzzz…5 天前
运维·云原生·容器·kubernetes·k8s·k8s组件
K8s---组件K8s官网—组件本文是一份 K8s 组件学习笔记,覆盖了: 1.控制平面 5 大组件(apiserver、etcd、scheduler、controller-manager、kubectl) 2.节点 3 大组件(kubelet、kube-proxy、容器运行时) 3.插件与附件(CoreDNS、Ingress、CNI、Dashboard、监控、日志) 4.各组件的管理关系图(systemd → kubelet → Pod) 如果你是正在学 K8s 的运维,或者刚接手集群不久,看完这篇至少能让你少踩坑。
陈皮糖..5 天前
运维·ci/cd·云原生·架构·kubernetes·自动化·gitlab
基于 Kubernetes 与 GitLab CI/CD 的云原生自动化交付平台本项目基于 Rocky Linux 10.1 系统,搭建了一套完整的 DevOps 自动化流水线。实现了开发人员推送代码并打上标签(Tag)后,系统自动完成代码拉取、镜像构建、镜像推送到 Harbor 私有仓库、以及 Kubernetes 集群自动滚动更新的全流程。
cui_hao_nan5 天前
云原生·容器·kubernetes
Kubernetes 核心概念总结Kubernetes(K8s)是一个容器编排平台,用于自动化部署、扩缩容和管理容器化应用。核心思想节点 = 干活的机器,Kubernetes = 指挥这些机器的大脑。
张洛闻Eren5 天前
linux·运维·docker·kubernetes·k8s
云原生k8s【第八课】: ETCD 备份与恢复ETCD 是什么ETCD 是 K8s 的核心数据库,集群所有数据,Pod、Service、密钥、权限全部存在这里,是集群唯一真实数据源。
IT大白鼠5 天前
http·容器·kubernetes
Ingress 与 Ingress-Controller:K8s 七层 HTTP 反向代理技术详解与实践Kubernetes中的Service和Ingress在集群网络架构中扮演着不同但互补的角色,两者在OSI模型中的层级定位和功能范围存在本质差异。Service工作在OSI模型的第四层(传输层),提供TCP/UDP协议的负载均衡能力,而Ingress则工作在第七层(应用层),实现HTTP/HTTPS协议的智能路由和流量管理。