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

精选列表

搜索[k8s]，共4083篇文章

微服务从代码到k8s部署应有尽有系列（二、网关）

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

2022-02-08

为效率而生：如何用 Zadig 1.6.0 全面支持全局 Helm & K8s YAML 模板

这次版本主要包含跨项目级的模版库管理功能，通过全局 Helm Chart 模板、 K8s YAML模板、Dockerfile模板，可以快速定义服务和生成应用，减少99%维护工作量，运维工程师只需配置一次模板

2021-11-24

每日一博 | 石墨文档基于 K8S 的 Go 微服务实践（上篇）

但是当K8S增加服务端副本时，客户端连接是无法及时感知的。因为gRPC DNS Resolver存在的问题，我们自己实现了Kubernetes API Resolver。

2021-09-18

作者｜段超来源｜尔达 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

Docker与k8s的恩怨情仇（四）-云原生时代的闭源落幕

开源vs闭源面对k8s的出现，一场Docker和k8s之间的容器之战就此打响。

2021-07-07

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

Kubernetes联合创始人Brendan Burns：K8s让企业上云更容易

K8s让上云更容易 K8s早已成为业界公认的标准，这离不开所有开发者的努力。Brendan认为，开发人员的需求促进了K8S的诞生，而当初创始团队对K8s的许多设计理念，也促成了云原生如今的盛况。

2020-12-01

非容器应用与K8s工作负载的服务网格化实践-序

WorkloadEntry是k8s集群与ecs集群通信的基础，本系列的第2篇将通过两个实践示例，把WorkloadEntry的用途和作用展示清楚，为后续pod和vm的互访、pod和vm混合场景中的流量转移打好理论基础

2020-09-13

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

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

2020-06-08

k8s+jenkins实现自动化部署应用至k8s集群

} #对k8s集群中的nginx的pod应用进行升级 app_update(){ ssh root@k8s-master-1 "sed -ri 's@image: .

2020-05-17

了解这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-15

重磅合集 | 31 篇技术文章，带你从零入门 K8s （留言赠书）

为了让大家有更好的学习体验，我们把视频课程转为图文，并请讲师重新编辑成文章，在公众号以“从零入门 K8s” 为系列进行每周连载。

2020-04-08

Centos7部署k8s[v1.16]高可用[keepalived]集群

Centos7部署k8s[v1.16]高可用[keepalived]集群实验目的一般情况下，k8s集群中只有一台master和多台node，当master故障时，引发的事故后果可想而知。

2020-04-01

阿里巴巴如何改善开发人员在 K8s 上的体验？

2019 年底，阿里巴巴中的大多数应用都在 K8s 上运行，并且在 K8s 之上构建了数十个原生框架，构筑 K8s 生态系统。

2020-03-26

影响 K8S Pod 分配和调度策略的两大关键特性

在Kubernetes中有一个最复杂的调度器可以处理pod的分配策略。基于在pod规范中所提及的资源需求，Kubernetes调度器会自动选择最合适的节点来运行pod。但在许多实际场景下，我们必须干预调度过程才能在pod和一个节点或两个特定pod之间进行匹配。因此，Kubernetes中有一种十分强大的机制来管理及控制pod的分配逻辑。那么，本文将探索影响Kubernetes中默认调度决定的关键特性。节点亲和性/反亲和性 Kubernetes一向以来都是依赖label和selector来对资源进行分组。例如，某服务使用selector来过滤具有特定label的pod，这些label可以选择性地接收流量。Label和selector可以使用简单的基于等式的条件（=and!=）来评估规则。通过nodeSelector的特性（即强制将pod调度到特定节点上），可以将这一技术扩展到节点中。此外，label和selector开始支持基于集合的query，它带来了基于in、notin和exist运算符的高级过滤技术。与基于等式的需求相结合，基于集合的需求提供了复杂的技术来过滤Kubernetes中的资源。节点亲和性/反亲和性使用label和annotation的基于表达集的过滤技术来定义特定节点上的pod的分配逻辑。Annotation可以提供不会暴露到selector的其他元数据，这意味着用于annotation的键不会包含在query和过滤资源中。但是节点亲和性可以在表达式中使用annotation。反亲和性可以确保pod不会被强制调度到与规则匹配的节点上。除了能够在query中使用复杂的逻辑之外，节点亲和性/反亲和性能够为分配逻辑强制施加硬性和软性规则。硬性规则将会执行严格的策略，可能会阻止将pod分配到不符合条件的节点上。而软性规则则会首先确认节点是否与特定的条件相匹配，如果它们不匹配，它将使用默认的调度模式来分配Pod。表达式requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution将会分别执行硬性规则和软性规则。以下是在硬性和软性规则下使用节点亲和性/反亲和性的示例： affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "failure-domain.beta.kubernetes.io/zone" operator: In values: ["asia-south1-a"] 以上规则将指示Kubernetes调度器尝试将Pod分配到在GKE集群的asia-south1-a区域中运行的节点上。如果没有可用的节点，则调度器将会直接应用标准的分配逻辑。 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "failure-domain.beta.kubernetes.io/zone" operator: NotIn values: ["asia-south1-a"] 以上规则通过使用NotIn运算符来强制执行反亲和性。这是一个硬性规则，它能够确保没有pod被分配到运行在asia-south1-a空间中的GKE节点。 Pod亲和性/反亲和性尽管节点亲和性/反亲和性能够处理pod和节点之间的匹配，但是有些场景下我们需要确保pod在一起运行或在相同的节点上不运行2个pod。Pod亲和性/反亲和性将帮助我们应用强制实施粒度分配逻辑。与节点亲和性/反亲和性中的表达式类似，pod亲和性/反亲和性也能够通过requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution强制实施硬性以及软性规则。还可以将节点亲和性与pod亲和性进行混合和匹配，以定义复杂的分配逻辑。为了能够更好地理解概念，想象一下我们有一个web和缓存deployment，其中三个副本在一个3节点的集群中运行。为了确保在web和缓存pod之间低延迟，我们想要在用一个节点上运行它们。与此同时，我们不想在相同的节点上运行超过1个缓存pod。基于此情况，我们需要实施以下策略：每个节点仅运行1个且只有1个缓存Pod的web pod。首先，我们将使用反亲和性规则来部署缓存，它将阻止超过1个pod运行在1个节点上： affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - redis topologyKey: "kubernetes.io/hostname" topoloyKey使用附加到节点的默认label动态过滤节点的名称。请注意，我们使用podAntiAffinity表达式和in运算符来应用规则的方式。假设在集群的某个节点上安排了3个pod缓存，那么现在我们想要在与缓存Pod相同的节点上部署web pod。我们将使用podAffinity来实施这一逻辑： podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - redis topologyKey: "kubernetes.io/hostname" 以上代码表明Kubernetes调度器要寻找有缓存Pod的节点并部署web pod。除了节点和pod的亲和性/反亲和性之外，我们还能使用taints和tolerations来定义自定义分配逻辑。此外，我们还能写自定义调度程序，它可以从默认的调度程序中接管调度逻辑。

2020-01-26

阿里云如何基于标准 K8s 打造边缘计算云原生基础设施

作者 | 黄玉奇（徙远）阿里巴巴高级技术专家导读：伴随 5G、IoT的发展，边缘计算正在成为云计算的新边界，而规模和复杂度的日益提升对边缘计算的效率、可靠性、资源利用率等一系列能力又提出了新的诉求。试想，如果能将云能力从中心往边缘触达，上述问题是不是将迎刃而解？在云原生时代构建云到边的触达通路，保持云边一致性体验，我们的抓手又在哪里呢？本文将一一为你揭晓。云原生的理念现今正如火如荼。它不仅仅是一种技术，更是随着云生态的发展而被逐渐提炼出的一系列技术、最佳实践与方法论的集合；它带来了资源利用率提升、分布式系统的弹性扩展与可靠性等能力，能够让 IT系统最大程度的享受云计算红利，业界全面拥抱云原生就是最好的佐证。云原生概念云原生的概念最早是在 2013 年被提出，经过近几年的发展，尤其是从 2015 年 Google 牵头成立

2019-12-19

高手问答 —— K8S 从懵圈到熟练，资深架构师在线解答

近几年，Kubernetes 已从一个新生事物发展为一个影响全球 IT 技术的基础设施平台，也推动了云原生应用、微服务架构、ServiceMesh 等热门技术的普及和落地。现在，Kubernetes 已经成为明星项目，成为开源历史上发展速度超快的项目之一。与此同时，关注 Kubernetes 的读者量一直在增加，读者抛出 Kubernetes 相关问题的频率也很高，因此本期高手问答以期为大家提供一个与权威专家在线讨论的渠道。 OSCHINA 本期高手问答（10 月 28 日 - 11月 03日）特邀请到《Kubernetes 权威指南》主要作者吴治辉@zzzxgswd 在线答疑，解答各位读者或者 Kubernetes 爱好者的各种技术疑问。嘉宾简介吴治辉，HPE 资深架构师，拥有近 20 年软件研发经验，专注于电信软件和云计算方面的软件研发，拥有丰富的大型项目架构设计经验，是业界少有的具备很强 Coding 能力的资深架构师，也是《架构解密：从分布式到微服务》《Kubernetes 权威指南：企业级容器云实战》等书作者。为了鼓励踊跃提问，@博文视点会在问答结束后从提问者中抽取5名幸运网友赠予《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触（第4版）》一书。购书地址：https://u.jd.com/j1FkFE OSChina 高手问答一贯的风格，不欢迎任何与主题无关的讨论和喷子。下面欢迎大家向吴治辉老师@zzzxgswd 积极提问，直接回帖提问即可。

2019-10-27

ASP.NET Core on K8S深入学习（3-2）DaemonSet与Job

agent，Ganglia gmond等系统程序，比如kube-proxy，kube-dns，glusterd，ceph等 Prometheus Node Exporter Dashboard 1.2 K8S

2019-08-18

ASP.NET Core on K8S深入学习（2）部署过程解析与Dashboard

上一篇《K8S集群部署》中搭建好了一个最小化的K8S集群，这一篇我们来部署一个ASP.NET Core WebAPI项目来介绍一下整个部署过程的运行机制，然后部署一下Dashboard，完成可视化管理。

2019-08-04

云原生生态周报 Vol. 9 | K8s 1.15 后的性能提升

业界要闻 Helm这款包管理工具，作为业界Kubernetes上应用分发的事实标准，其 v3.0.0-alpha.1正式发布，这是Helm 3的第一个Alpha版本。（https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1），标志着 Tiller 这个 Server 端组件正式从 Helm 体系中谢幕 Talos发布。Talos是一款专门用于部署Kubernetes的操作系统。相对于CoreOS，RancherOS或者LinuxKit这些容器操作系统，Talos更为精简。但是由于去除了ssh等基础工具，这对于Ansible等基于ssh的Kubernetes部署工具影响巨大。(https://github.com/talos-systems/talos) Google推出深度学习容

2019-07-10

资源下载

更多资源

Mario

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

Nacos

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

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

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