首页 文章 精选 留言 我的

精选列表

搜索[k8s]，共3940篇文章
优秀的个人博客,低调大师

k8s 如何 Failover？- 每天5分钟玩转 Docker 容器技术（127）

上一节我们有 3 个 nginx 副本分别运行在 k8s-node1 和 k8s-node2 上。现在模拟 k8s-node2 故障，关闭该节点。 等待一段时间，Kubernetes 会检查到 k8s-node2 不可用，将 k8s-node2 上的 Pod 标记为Unknown状态，并在 k8s-node1 上新创建两个 Pod，维持总副本数为 3。 当 k8s-node2 恢复后，Unknown的 Pod 会被删除，不过已经运行的 Pod 不会重新调度回 k8s-node2。 删除nginx-deployment： 下一节我们学习如何控制 Pod 运行的位置。 书籍： 1.《每天5分钟玩转Docker容器技术》https://item.jd.com/16936307278.html2.《每天5分钟玩转OpenStack》https://item.jd.com/12086376.html 本文转自CloudMan6 51CTO博客，原文链接:http://blog.51cto.com/cloudman/2067968
2017-11-13
优秀的个人博客,低调大师

基于 CoreDNS 和 K8s 构建云原生场景下的企业级 DNS

容器作为近些年最火热的后端技术，加快了很多企业的数字化转型进程。目前的企业，不是在使用云原生技术，就是在转向云原生技术的过程中。在容器化进程中，如何保持业务的平稳迁移，如何将现有的一些服务设施一并进行容器化迁移，也是众多企业较为关注的点。 以 DNS 为例，如何构建一个云原生的企业 DNS 系统？ CoreDNS 简介 CoreDNS 是一个 Go 语言编写的灵活可扩展的 DNS 服务器，在 Kubernetes 中，作为一个服务发现的配置中心，在 Kubernetes 中创建的 Service 和 Pod 都会在其中自动生成相应的 DNS 记录。Kubernetes 服务发现的特性，使 CoreDNS 很适合作为企业云原生环境的 DNS 服务器，保障企业容器化和非容器化业务服务的稳定运行。 构建企业 DNS 服务器时，一般会有以下需求： 用户外网域名访问服务； 混合云业务迁移、数据共享、容灾； 开发代码 IP 写死导致架构可用性、弹性无法实现； 统一 DNS 管理需求，含上下级平台对接； DNS 劫持等网络安全风险； 存量代码固定域名访问； 集群外域名访问； 相比于 Bind 开源方案或 Windows Server DNS 商业 DNS 服务器，CoreDNS 有以下优势： 无商业许可要求，降低投资成本； 轻量化，通过插件实现功能添加； 支持 DNS，DNS over TLS，DNS over HTTP/2，DNS over gRPC 协议； 提供 kubernetes 服务发现； 支持对接 Route53/Google Cloud DNS/AzureDNS； 支持集成 Prometheus， OpenTracing，OPA，带来更全面的运维体验； 支持整合容器管理平台，提供统一 DNS 系统运维。 构建企业云原生 DNS 前，对 CoreDNS 做一个更深入的了解。 CoreDNS 运行原理与插件介绍 CoreDNS 基于 Caddy 框架实现模块化设计，每个插件承载相应的具体功能，对于 DNS 系统而言，CoreDNS 使用 File，ETCD 插件等加载 DNS 记录，使用 Kubernetes 插件实现集群服务发现，外部 DNS 请求到达 CoreDNS 后，根据插件调用链依次处理 DNS 请求。 CoreDNS 社区官方提供了 50 多种插件，开发者亦可根据需求开发个性化的外部插件。CoreDNS 常用插件如下图，根据使用场景，可分为运维、DNS 处理、后端数据存储等三个类别。 CoreDNS 定义 Corefile 配置文件，服务器在加载 Corefile 后处理 DNS 请求，对于以下插件，只需在 Corefile 中引用即可，之后 CoreDNS 会使用插件链进行调用，插件链可参考以下链接： https://github.com/coredns/coredns/blob/master/plugin.cfg 设计一个基于 CoreDNS 的分层 DNS 架构 在熟悉 CoreDNS 特性后，可设计企业的 DNS 架构： DNS 架构以外网 DNS、内网 DNS、分区 DNS 组成： 外网 DNS： 使用 DNSSEC、DOT、DOH 等保障 DNS 安全； 缓存 DNS 记录； 构建 DNS 实例自动伸缩，应对高 QPS 需求； 内网 DNS： Kubernetes 服务发现； 构建上游 DNS 区域； 分区 DNS： 建立开发、测试、UAT、生产等区域 DNS； NodeLocalDNS 提高性能； 设置转发器处理递归 DNS 请求； KubeSphere 部署 CoreDNS 由于 CoreDNS 是一个 CNCF 毕业的云原生项目，是目前支持云原生最好的一个 DNS 服务器，用户可直接在 KubeSphere 应用商店一键安装。KubeSphere 提供了基于 Helm 模板的应用商店，支持云原生应用的生命周期管理，提供开发人员应用上传、测试，版本提交，应用管理人员进行审核、发布等流程管理。用户在应用商店选择 CoreDNS 应用后，可按需部署于不同集群的不同项目中，并自定义应用模板配置： 服务发现与 DNS 配置 部署 CoreDNS 后，对于运维人员来说，CoreDNS 的配置大体分为两类：一类为 Kubernetes 配置，一类为 DNS 配置。CoreDNS 提供了 Kubernetes 插件，支持在 kubernetes 集群中读取区域数据，并根据 Pod 和 Service 的域名记载相应的 A 记录和 PTR 记录。 这是一个 Kubernetes 集群中的 CoreDNS corefile 默认配置，CoreDNS 会在 53 端口读取 cluster.local 后缀的 Kubernetes 集群 A 记录和 PTR 记录。并将 CoreDNS 收集到的监控指标通过 9153 端口输出到集群内的 Prometheus。而 Kubernetes 不同类型 Service 的 DNS 记录格式，CoreDNS 也有相应标准进行记录。 设置完 Kubernetes 后，可以设置其他业务需求的 DNS 配置，如： 设置不同的存根域； 设置存根域静态 DNS 条目； 面对存量代码，设置域名重写； 面对集群外服务，设置 DNS 转发； 设置日志和监控集成； 设置缓存、健康、就绪检查及链路追踪； 根据以上配置，就构建了一个基础的企业云原生 DNS 系统： DNS 服务暴露 对于集群外的服务而言，存量业务可能还是一些虚拟化和裸机的应用，若和集群网络无法互联，如何在业务迁移时访问新的 DNS 服务？ KubeSphere 提供了一个开源项目——OpenELB 来解决云原生环境下的服务暴露问题，这是一个 CNCF 的沙箱项目。OpenELB 通过物理环境的交换机使用 BGP 协议将 LoadBalancer 类型服务的 ExternalIP 宣告出去，在 IP 可达的环境下集群外部业务即可通过 EIP 访问 Kubernetes 服务资源。 对于集群外需要设置 DNS 服务器的服务资源，可通过 OpenELB 使用 EIP 暴露 CoreDNS ，即可访问 DNS 服务 。 在 KubeSphere 3.3 版本，用户可在开启集群网关 / 项目网关时，在网关访问 LoadBalancer 模式下，选择“OpenELB”负载均衡提供商，之后创建的 LoadBalancer 服务都会从 OpenELB 建立的 EIP Pool 中分配 EIP，供集群外部访问。 DNS 监控运维 为保障 CoreDNS 稳定运行，运维人员还需在基础设施侧完善 DNS 系统的日志、监控、告警、通知功能，KubeSphere 提供了简单易用的监控面板、日志管理与落盘，多维度的告警策略和消息，以及对接多个企业应用（邮件，钉钉， 企业微信）的通知系统，时刻关注业务运行状态。 此处以一个系统管理员视角，展示了在 KubeSphere 日志系统搜寻 NXDOMAIN 类型 DNS 回复的结果。 通过 KubeSphere 自定义监控面板，设置一个基于 CoreDNS 指标的监控面板，KubeSphere 内置了众多监控面板，用户可直接使用模板构建亦可使用 PromQL 创建面板： 通过 KubeSphere 告警和通知组件，用户可基于预置规则模板（CPU、内存、磁盘、网络、异常率）或使用 PromQL 语句自定义告警规则，此处定义当 CoreDNS CPU 用量大于等于 0.1Core 系统触发告警： KubeSphere 针对租户设计了通知模板，包含多种通知系统集成，此处使用邮件将“重要告警”，“危险告警”条件的告警消息发送给邮件接收人。 当告警触发后，即可在告警消息和通知历史处查看到相应的条目，此时用户也会收到一封告警邮件了： 在高并发 DNS 请求场景中，还需对 CoreDNS 进行自动伸缩设计，通常考虑到服务高可用性和性能考量，可参考以下计算规格和调度策略设计： 副本打散，跨可用区 / 节点。 避免所在节点 CPU、内存过高。 通常设计副本数为 2。QPS 与 CPU 消耗正相关，单 CPU——1w+QPS Kubernetes 集群下，CoreDNS 副本数与集群节点配置 1:8。 业务峰值 CPU 占用 >1Core，水平扩容。 通过 KubeSphere 自动伸缩机制，可设置基于 CPU 用量的自动伸缩策略，保障 CoreDNS 在瞬时高并发场景稳定运行。 总结 以上就是建设一个云原生的 DNS 系统的全部内容了，可以看出，在云原生时代，新的技术层出不穷，IT 系统的部门和人员也越发趋于协同作战，以往构建一个 DNS 系统可能只需要安装一套稳定能进行 DNS 解析的系统，并实现主备切换即可。在应用驱动基础架构转型的云原生时代，基础服务应用还更需要考虑异构系统的连接，灵活简便的安装升级管理，更强大的可靠性和自愈能力，日志监控通知系统的完善，还有更适合实际业务需求的弹性设计，来加速应用现代化，推动业务应用持续转型。 本文由博客一文多发平台 OpenWrite 发布！
2022-09-20
优秀的个人博客,低调大师

面对大规模 K8s 集群，这款诊断利器必须要“粉一波”！

作者｜段超 来源｜尔达 Erda 公众号 背景 我们是一家做商业软件的公司，从一开始我们就把软件交付流程做的非常标准且简单，所有的软件都是基于我们的企业数字化平台 Erda（现已开源）来交付，底层基于 Kubernetes，为企业提供 DevOps、微服务治理、多云管理以及快数据管理等云厂商无绑定的 IT 服务。 ​ 随着我们服务的客户数量越来越多，如今我们管理着相当规模数量的 Kubernetes 集群，集群的稳定性决定了服务质量以及对外口碑，很长一段时间内我们在这件事情上都显得很被动，经常会出现 Erda 支持同学或者客户将问题反馈到我们说：有业务出现了问题，需要我们协助查询一下是不是平台导致的，然后我们上去一顿操作最后解决问题，答复客户。看似专业且厉害，急用户之所急，实则无章无法，一地鸡毛。 通常我们依赖监控系统来提前发现问题，但是监控数据作为一个正向链路，很难覆盖到所有场景，经常会有因为集群配置的不一致性或者一些更底层资源的异常，导致即使监控数据完全正常，但是整个系统依然会有一些功能不可用。对此，我们做了一套巡检系统，针对系统中一些薄弱点以及一致性做诊断，美中不足的是，这套系统的扩展性不是很好，对集群跟巡检项的管理也相对粗暴了一点。 ​ 最后，我们决定做一个更加云原生的诊断工具，使用 operator 来实现集群跟诊断项的管理，抽象出集群跟诊断项的资源概念，来解决大规模 Kubernetes 集群的诊断问题，通过在中心下发诊断项到其他集群，并统一收集其他集群的诊断结果，来实现任何时刻都可以从中心获取到其他所有集群的运行状态，做到对大规模 Kubernetes 集群的有效管理以及诊断。 ​ Kubeprober 项目介绍 项目地址： https://github.com/erda-project/kubeprober ​ KubeProber 是一个针对大规模 Kubernetes 集群设计的诊断工具，用于在 Kubernetes 集群中执行诊断项以证明集群的各项功能是否正常，KubeProber 有如下特点: ​ 支持大规模集群：支持多集群管理，支持在管理端配置集群跟诊断项的关系以及统一查看所有集群的诊断结。 云原生：核心逻辑采用 operator 来实现，提供完整的 Kubernetes API 兼容性。 可扩展：支持用户自定义巡检项。 ​ 其核心架构如下： ​ 区别于监控系统，kubeProber 从巡检的角度来证明集群的各项功能是否正常，监控作为正向链路，无法覆盖系统中的所有场景，系统中各个环境的监控数据都正常，也不能保证系统是 100% 可以用的，因此需要一个工具从反向来证明系统的可用性、从根本上做到先于用户发现集群中不可用的点，比如： ​ 集中的所有节点是否均可以被调度，有没有特殊的污点存在等。 pod 是否可以正常的创建、销毁，验证从 Kubernetes，Kubelet 到 Docker 的整条链路。 创建一个 Service，并测试连通性，验证 kube-proxy 的链路是否正常。 解析一个内部或者外部的域名，验证 CoreDNS 是否正常工作。 访问一个 ingress 域名，验证集群中的 ingress 组件是否正常工作。 创建并删除一个 namespace，验证相关的 webhook 是否正常工作。 对 Etcd 执行 put/get/delete 等操作，用于验证 Etcd 是否正常运行。 通过 mysql-client 的操作来验证 MySQL 是否正常运行。 模拟用户对业务系统进行登录、操作，验证业务的主流程是否常常。 检查各个环境的证书是否过期。 云资源的到期检查。 更多... ​ 组件介绍 Kubeprober 整体采用 Operator 来实现核心逻辑，集群之间的管理使用 remotedialer 来维持被纳管集群跟管理集群之间的心跳链接，被纳管集群通过 RBAC 赋予 probe-agent 最小所需权限，并且通过心跳链接实时上报被纳管集群元信息，以及访问 apiserver 的 token，实现在管理集群可以对被管理集群的相关资源进行操作的功能。 ​ probe-master 运行在管理集群上的 operator，这个 operator 维护两个 CRD，一个是 Cluster，用于管理被纳管的集群；另一个是 Probe，用于管理内置的以及用户自己编写的诊断项，probe-master 通过 watch 这两个 CRD，将最新的诊断配置推送到被纳管的集群，同时 probe-master 提供接口用于查看被纳管集群的诊断结果。 ​ probe-agent 运行在被纳管集群上的 operator，这个 operator 维护两个 CRD，一个是跟 probe-master 完全一致的 Probe，probe-agent 按照 probe 的定义去执行该集群的诊断项，另一个是 ProbeStatus，用于记录每个 Probe 的诊断结果，用户可以在被纳管的集群中通过 kubectl get probestatus 来查看本集群的诊断结果。 ​ 什么是 Probe kubeprobe 中运行的诊断计划我们称之为 Probe，一个 Probe 为一个诊断项的集合，我们建议将统一场景下的诊断项作为一个 Probe 来运行，probe-agent 组件会 watch probe 资源，执行 Probe 中定义的诊断项，并且将结果写在 ProbeStatus 的资源中。 我们期望有一个输出可以清晰的看到当前集群的运行状态，因此，我们建议所有的 Probe 都尽可能属于应用、中间件、Kubernets、基础设置这四大场景，这样我们可以在展示状态的时候，自上而下清楚地查看究竟是系统中哪个层面引起的问题。 ​ 目前的 Probe 还比较少，我们还在继续完善，也希望跟大家一起共建。 ​ 自定义 Probe ​ 对比其他诊断工具 目前社区已经有 Kuberhealthy 以及 kubeeye 来做 Kubernetes 集群诊断这件事情。 ​ kuberheathy 提供一套比较清晰的框架可以让你轻松编写自己的诊断项，将诊断项 CRD 化，可以轻松地使用 Kubernetes 的方式来对单个 Kubernetes 进行体检。 ​ kubeeye 同样是针对单个集群，主要通过调用 Kubernetes 的 event api 以及 Node-Problem-Detector 来检测集群控制平面以及各种节点问题，同时也支持自定义诊断项。 ​ kubeprober 做的也是诊断 Kubernetes 集群这件事情，提供框架来编写自己的诊断项。除此之外，kubeprober 主要解决了大规模 Kubernetes 集群的诊断问题，通过中心化的思路，将集群跟诊断项抽象成 CRD，可以实现在中心 Kubernetes 集群管理其他 Kubernetes 诊断项配置、诊断结果收集，未来也会解决大规模 Kubernetes 集群的运维问题。 ​ 如何使用 kubeprober 主要解决大规模 Kubernetes 集群的诊断问题，通常我们选择其中一个集群作为 master 集群，部署 probe-master，其他集群作为被纳管集群，部署 probe-agent。 ​ 安装 probe-master probe-master 使用了 webhook，webhook 的运行需要校验证书，需要先部署一下 cert-manager 的服务: ​ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml ​ 然后安装 probe-master： ​ APP=probe-master make deploy 安装 probe-agent 在逻辑上，一个 cluster 资源对应一个 probe-agent，在部署 probe-agent 之前，需要先创建一个 cluster 资源，probe-master 会给每一个 cluster 生成一个 secreykey，用于跟 probe-master 交互的唯一凭证。 ​ kubectl apply -f config/samples/kubeprobe_v1_cluster.yaml kubectl get cluster -o wide #可以获取到集群的secretkey ​ 部署 probe-agent 前，需要先修改 probe-agent 的 configmap： ​ vim config/manager-probe-agent/manager.yaml --- apiVersion: v1 kind: ConfigMap metadata: name: probeagent namespace: system data: probe-conf.yaml: | probe_master_addr: http://kubeprober-probe-master.kubeprober.svc.cluster.local:8088 cluster_name: moon secret_key: 2f5079a5-425c-4fb7-8518-562e1685c9b4 ​ 最后安装 probe-agent： ​ APP=probe-agent make deploy ​ 安装好 probeagent 后我们就可以在 master 集群中看到 cluster 信息。 配置 probe 有了 cluster，我们还需要在 master 集群中创建 probe 资源，比如： ​ kubectl apply -f config/samples/kubeprobe_v1_cron_probe.yaml ​ 使用 kubectl get probe 来查看 probe 列表，使用 kubectl label 来将一个 probe 跟 cluster 关联起来，则对用的 probe-agent 会在本集群内执行相关的诊断项。 ​ kubectl label cluster moon probe/probe-link-test1=true kubectl label cluster moon probe/probe-cron-sample=true ​ 最后，我们可以在被诊断的集群中使用 kubectl get probestatus 来查看诊断本集群的诊断结果。 ​ 欢迎参与开源 当前 kubeprobe 已经发布了第一个版本 0.0.1，还有许多功能不太完善，probe-master 的管理能力还可以进一步的被放大挖掘，probe 的编写也需要更加的简单易用。我们希望跟社区一起共建，共同打造一个大规模 Kubernetes 集群的管理神器。欢迎大家关注、贡献代码和 Star！ ​ Erda Github 地址：https://github.com/erda-project/erda Erda Cloud 官网：https://www.erda.cloud/ Contributing to KubeProber：https://github.com/erda-project/kubeprober/blob/master/CONTRIBUTING.md
2021-07-09
优秀的个人博客,低调大师

QPS 最高提升 91% | 腾讯云 TKE 基于 Cilium eBPF 提升 k8s Service 性能

前言 Kubernetes 已经成为容器管理领域的事实标准，而网络系统是 Kubernetes 核心部分，随着越来越多的业务部署在 Kubernetes，对容器网络也提出了一些新的需求 怎么提升网络的可观测性，serverless 类产品该需求尤为突出 怎么尽可能减少容器引入的网络性能损耗 上述需求冲击了 iptables，IPVS 等传统防火墙，负载均衡器技术。也促使我们思考容器网络访问链路能否不依赖于节点，进而缩短容器访问链路，提升网络性能 eBPF 是一项革命性技术，它可以以一种安全的方式在内核中许多 hook 点执行程序，该项技术可编程能力强，并且也无需维护内核模块，可维护性好，该项技术为满足上述需求提供了可能。Cilium则是基于 eBPF 技术的容器网络开源项目，提供了网络互通，服务负载均衡，安全和可观测性等解决方案 由此，腾讯云容器服务 TKE 基于 Cilium 和 eBPF 实现了独立网卡模式下的高性能 ClusterIP Service 方案。TKE 致力于提供更高性能、更安全和更易用的容器网络，也因此会不断关注 Cilium 等前沿的容器网络技术方案，后续会推出更多更完善的 Cilium 产品化能力。 独立网卡 Service 方案 TKE 于去年推出了新一代容器网络方案，该方案实现了一个 Pod 独占一张弹性网卡，不再经过节点网络协议栈（default namespace）。而当前的 kube-proxy 实现 ClusterIP 的方案都依赖于在节点侧的网络协议栈里设置相应的 iptables 规则，也因此该方案对于独立网卡方案不再适用。 其中一个解决方案便是 Cilium，Cilium 提供了基于 eBPF 的地址转换能力，从而可支持 ClusterIP Service。但其原生方案仅支持 veth pair 和 ipvlan l3 的数据面，并不支持 Pod 完全不经过节点网络协议栈的数据面，因此不能原生解决独立网卡 ClusterIP 的访问问题。 TKE 由此对 Cilium 加以改造，使其支持了除原生支持的 veth 和 ipvlan l3 的第三种数据面方案，如图（假设 pod 访问 Service IP 为 172.16.0.2），数据面上，将原本挂载到节点侧的 veth 上的 bpf 程序，挂载到 pod 内的独立网卡（同时也是弹性网卡）上，使得 Pod 的网络报文在发出的时候做 DNAT（目的地址转换），而回报文在网卡接收的时候做反向 DNAT，从而支持 ClusterIP 的访问。该数据面方案可作为一个通用方案适配 Ipvlan l2、SRIOV 等数据面场景。 而控制面上，将 Cilium 与 TKE 的 VPC-CNI 模式（含共享网卡模式和独立网卡模式）深度集成，用户无需对业务代码逻辑做任何修改，即可使用 Cilium 的功能特性。 性能对比 本文使用 wrk 工具对 Cilium 的产品化解决方案进行了性能压测，测试保证 Client Pod 和 Server Pod 分布在不同节点。 测试环境： TKE 集群，4 个 CVM节点，配置为 Server S5.2XLARGE8，Client S5.SMALL2。 测试数据表明，基于 Cilium 的独立网卡 ClusterIP 访问方案性能最好。在短连接场景下，其 QPS 相比共享网卡的 iptables 和 ipvs 方案提升48%和74%，相比全局路由的 iptables 和 ipvs 方案提升了62%和91%。在长连接场景下，其 QPS 相比共享网卡的 iptables 和 ipvs 方案提升了33%和57%，而相比全局路由的 iptables 和 ipvs 方案提升了49%和66%。iptables 的性能较 ipvs 性能较好是因为测试环境中 Service 数量还不够多，ipvs 的优势在于大量 Service 的场景。 产品化过程中的相关问题 TKE 团队在实现 Cilium 产品化解决方案过程中，也发现了 Cilium 项目中一些问题，相应的解决方案和 Cilium 支持新数据面方案将于近日以 pr 的形式整理提交给 Cilium 社区。 独立网卡方案下的 ClusterIP 自访问不通 以上方案其实不能完全解决 ClusterIP 访问问题，存在一类特殊的场景会访问不通。这类场景就是 Pod 访问的 ClusterIP，其后端包括其自身。这类场景下，独立网卡的 Pod 发出的网络报文会直接到达 IAAS 层，不符合预期。 由于独立网卡 Pod 内，其实只有两个网络设备：回环设备（lo）和弹性网卡，因此一个简单的思路就是在出报文之前，对自访问流量，通过 bpf_redirect 调用将报文直接转发（redirect）到回环（lo）设备。基于此，TKE 团队修改了 cilium 的相关 bpf 代码，提供了一个解决方案。经过测试，该方案可以解决独立网卡方案下的 ClusterIP 自访问问题。 Cilium 加载 bpf 程序的名字缺失 Cilium 项目的可调试性存在一个问题，其 bpf 程序开发得比较早，底层用了很多老的工具集，例如 tc，来加载 bpf 代码。 老的 tc 基于老的内核版本(<4.15)设计的，它在加载 bpf 程序时，将 bpf 程序的名字忽略了，导致 Cilium 加载的 bpf 程序都是无名字的。这影响了对代码的理解，追踪和调试。 对此 TKE 团队结合较新的内核对 tc 工具进行了修正，使得它加载 bpf 程序时，会正确的传入名字。通过这名字，可以搞清楚实际运行的 bpf 函数具体是哪一个，从而提高 Cilium 的可调试性。 用法 申请 Cilium 支持 ClusterIP 产品化内测开通后，创建 TKE 集群时高级设置中打开 ClusterIP 增强 即可： 总结与展望 本文介绍了 TKE 团队实现的基于 Cilium 和 eBPF 的独立网卡模式下高性能 ClusterIP service 方案，该方案相比当前基于 iptables 和 ipvs 的传统网络方案大量的提升了性能（33%-91%）。 显然，Cilium 提供的能力还不止于此，其基于 eBPF 这项革命性的技术，还提供了安全、可观测性、QoS 等方面的能力，而提供更高性能、更安全和更易用的容器网络正是 TKE 的服务目标，因此，后续 TKE 将会积极参与 Cilium 社区，与社区一道共同推出更强大、更完善的容器网络能力。 参考资料 Cilium 项目官网 eBPF 介绍和参考指南 腾讯云容器服务 TKE 推出新一代零损耗容器网络 Kubernetes Service 【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
2021-07-07
优秀的个人博客,低调大师

OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力

作者| 郑超 阿里云高级开发工程师 随着物联网技术以及 5G 技术的高速发展，将云计算的能力延伸至边缘设备端，并通过中心进行统一交付、管控，已成为云计算的重要发展趋势。为服务更多开发者把握这一趋势，5 月 29 日，阿里巴巴正式对外开源了基于 ACK@Edge（边缘集群托管服务）的云原生边缘计算框架—— OpenYurt。 自 OpenYurt 开源以来受到了开发者的关注，今天这篇文章将带大家快速上手 OpenYurt ，介绍如何使用 OpenYurt 提供的命令行管理工具 Yurtctl， 高效快速地部署 OpenYurt 集群。 OpenYurt 介绍 OpenYurt 主打“云边一体化”概念，依托 Kubernetes 强大的容器应用编排能力，满足了云-边一体化的应用分发、交付、和管控的诉求。相较于其他基于 Kubernetes
2020-06-09
优秀的个人博客,低调大师

了解这5大K8S管理服务，为你节省50%的部署时间！

云栖号资讯：【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ Kubernetes已然成为IT世界的重要组成部分，并且仍在不断地发展壮大，现阶段，Kubernetes已经可以帮助企业进行微服务训练，加速企业数字化转型。尽管Kubernetes是一款如此令人印象深刻的容器编排工具，但它仍旧非常复杂。要运行和维护Kubernetes集群，您需要具备丰富的容器领域相关经验。再进一步，即便您已经拥有相关的经验，设置集群并部署它也将花费您不少的时间和精力。一旦您成功设置了Kubernetes环境，您就需要对其进行监控和管理。 对于一些组织而言，维护一个Kubernetes生态系统所涉及的成本以及风险超过了实现它所带来的好处。然而，在内部构建Kubernetes虽然很便宜，但是却非常棘手及复杂。在实施Kubernetes过程中的一个小错误，可能会在生产环境中才被发现，并且导致灾难性的后果。重新部署则可能导致延迟交付。这正是一些组织推迟采用Kubernetes所存在的主要顾虑。在这样的背景下，管理Kubernetes服务应运而生。 管理Kubernetes服务不仅拥有质量更好的交付服务，还可以确保您的Kubernetes环境更具备灵活性、高可用性、安全性以及更高的效率。开发人员需要Kubernetes平台具有高可用性，内部平台则需要整个团队来确保Kubernetes平台的可用性及安全性。然而，在Kubernetes平台上设置监控服务比部署平台本身更为艰巨。这就意味着运维人员在帮助开发人员解决问题之前，就已经极大地浪费了他们更多的时间。对于许多组织而言，它们的诉求并不仅是建立一个可用的Kubernetes平台，还需要搭建CI/CD流水线和Jenkins。 这些诉求加重了IT团队的负担，他们必须设置、实现和管理多个不同的服务。管理Kubernetes服务帮助IT团队解决了以上诉求，它们可以管理和维护Kubernetes环境，并通过监控集群在统一仪表盘上的多个指标，从而确保集群的健康状况。 那么，管理Kubernetes服务应当解决哪些方面的问题呢？管理Kubernetes服务解决方案需要高效执行控制面板的管理及操作任务，能够快速部署Kubernetes面板，并允许客户轻松插入各种环境。除此之外，理想的管理Kubernetes服务解决方案需要满足跨所有Kubernetes环境更新Kubernetes版本的需求，而不会出现任何问题。管理Kubernetes服务需要建立有效的集群监控机制，提供集群健康状况的实时可视化视窗，并尝试自行修复集群问题。对于客户需要注意的问题，管理Kubernetes服务应当及时发送告警。 五大管理Kubernetes服务一览 Rancher 尽管Rancher拥有自己的容器编排平台，但它还提供了开源的管理Kubernetes服务。Rancher允许您通过单个界面管理多个集群。Rancher基于容器的安装程序Rancher Kubernetes Engine（RKE）支持云和本地部署。更为关键的是，Rancher拥有直观极简的操作体验，让您在无需拥有任何Kubernetes深入知识的情况下即可开始工作。 Rancher可以开箱即用地部署Prometheus和Grafana，以便对集群和工作负载的指标进行可视化。另一方面，Rancher使新Kubernetes用户部署工作负载变得十分简单，同时仍然保留所有传统的访问通道供高级用户使用。Rancher简单的管理架构可以为用户带来更安全的系统、更高效的团队，以及企业转向市场的灵活性。 Rancher旨在成为一个避免供应商锁定（Lock-in）的Kubernetes管理平台，它允许用户导入使用管理Kubernetes服务构建的现有集群。Rancher是业界首个且唯一可以管理所有云上、所有发行版、所有Kubernetes集群的平台，充分赋予用户选择基础设施的自由。 尤为值得一提的是，Rancher是业界唯一一个与全球所有领先云供应商达成合作、支持其托管的Kubernetes集群的Kubernetes管理平台。在中国，Rancher拥有包括阿里云、腾讯云、华为云、百度智能云、平安云在内的主流领先公有云的全面支持，用户可以在Rancher平台上直接创建和管理公有云托管的Kubernetes服务，并实现多公有云托管Kubernetes服务的统一纳管。 Platform9 Platform9的管理Kubernetes服务集成了云和本地上的多个基础架构。Platform9的上游主服务器可以部署到各种云供应商，并且可以通过统一的界面进行管理。Platform9支持Google Cloud、裸机、Azure、AWS、vSphere和Nutanix AHV。此外，Platform9还提供了一个无服务器框架来编写可以触发Kubernetes集群中事件的短期函数。 在使用Platform9进行管理Kubernetes服务的第二天即可实现自动化操作，您还可以在无需中断服务器的情况下实现一键升级。Platform9还提供了适用于所有Kubernetes环境的即时安全补丁。 在集群监控方面，Platform9可以持续远程监控所有集群，并自动修复所有issue，预先包装的仪表盘帮助您轻松监控所有应用程序和集群。 通过Platform，您可以实现5分钟部署并集成您选择的内容。插入现有的集群也并非难事。一旦您连接了集群，Platform9将自动发现您的基础架构，并开始对其进行管理。最后，无论您的集群是关闭还是断开，Platform都将进行集群监控。 GiantSwarm 和Platform9完全一样，GiantSwarm提供了基于标准Kubernetes API的完整管理Kubernetes服务。由于它是基于Kubernetes API进行集成的，所以GiantSwarm可以运行位于任何位置的Kubernetes集群。GiantSwarm为您的Kubernetes环境提供即时管理，以帮助您更快地进行交付。它希望开发人员更专注于创新而非管理。GiantSwarm还可以帮助您每天数次部署新增的更新。 与Platform9类似的是，GiantSwarm允许您在几种不同的环境运行工作负载。GiantSwarm还通过持续升级和高效的故障排除，帮助您确保高正常运行时间。它提供即时安全补丁，以确保您的集群安全无懈可击。GiantSwarm拥有Adidas、Vodafone和饿Valliant等知名客户。API驱动程序平台允许您轻松地创建和扩展集群。 Pivotal Pivotal Container Service（PKS）专为第二天的操作而构建，它允许您在私有云和公有云上部署和运行工作负载。PKS还会密切监视您的集群并定期进行健康检查。 借助PKS，您可以使用网络分段，将不同的容器隔离在单个集群当中。无论PKS何时遇到新服务，它都会迅速应用补丁程序，以确保应用程序和集群安全。您还可以通过编程的方式管理虚拟网络，以确保全面的安全性。 Kublr Kublr是一个简化了不同环境中的部署的管理Kubernetes服务。您可以通过Kublr UI或者是API部署集群。每次部署集群时，Kublr都会自动将其连接到日志收集和监控系统。 Kublr通过Prometheus和Elasticsearch收集指标，并使用Grafana或Kibana来实现集群指标的可视化。Kublr的告警管理器可以连接至电子邮件、Slack和Pagerduty，以确保您不会错过告警信息。 另外，Kublr还确保了集群的可移植性，安装在每个集群上的轻量级代理执行安装及配置，并持续监视运行状况。Kublr还提供自我修复和自我编排功能。 管理Kubernetes服务：让组织按下“简单”按钮 随着越来越多的组织采用Kubernetes，围绕Kubernetes的工具生态系统必然将持续且强劲地增长。对于刚入门的开发人员而言，使用Kubernetes是一件很复杂的事情。同时，如果缺乏正确的知识，创建和部署集群的成本可能变得非常高昂。Kubernetes将使组织的IT发展变慢，从而失去Kubernetes真正的意义。 因此，组织需要借助管理Kubernetes服务来轻松管理持续增长的Kubernetes集群的所有活动。Kubernetes集群不仅难以构建和部署，并且难以运行及管理。以上的解决方案将帮助您升级Kubernetes版本和应用安全补丁。另一方面，通过出色的集群监控功能，您可以追踪集群的性能。除此之外，这些工具还提供了持续的运行状况检查，以确保您的集群具有伸缩性和高可用性。 上述解决方案仅为市场上众多可用服务的一部分，这些服务可以帮助您在无需投入过多精力的情况下充分利用Kubernetes的优势。尽管这些工具做的是相同的工作，但是它们自身仍在不断发展，它们适应Kubernetes的方式将使它们持续立于潮流之巅。 【云栖号在线课堂】每天都有产品技术专家分享！课程地址：https://yqh.aliyun.com/live 立即加入社群，与专家面对面，及时了解课程最新动态！【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间：2020-04-15本文作者：Rancher本文来自：“dockone”，了解相关信息可以关注“dockone”
2020-04-16

资源下载

更多资源
Mario

Mario

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

时间: 2025-12-12 大小: 211.28KB 下载: 54次
腾讯云软件源

腾讯云软件源

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

时间: 2026-03-01 大小: 1MB 下载: 6次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2025-12-21 大小: 189MB 下载: 2次
Sublime Text

Sublime Text

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

时间: 2025-12-03 大小: 9.84MB 下载: 39次
热门标签
OpenAi SpringCloud SpringBoot4 Kubernetes Redis DeepSeek Jdk25 Service Mesh Docker Nacos3 HarmonyOS6 Rocky Gemini3

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册