CoreDNS

作者 | 新胜 阿里云技术专家 导读： OpenYurt 开源两周以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，我们特地推出 【深度解读OpenYurt】 系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩展能力。 系列文章推荐： OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力 深度解读 OpenYurt ：边缘自治能力设计解析 OpenYurt 介绍 阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt ，跟其他开源的容器化边缘计算方案的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 系统零修改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。 同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念： 非侵入式增强 K8s

作者 | 新胜 阿里云技术专家 导读： OpenYurt 开源两周以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，我们特地推出 【深度解读OpenYurt】 系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩展能力。 系列文章推荐： OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力 深度解读 OpenYurt ：边缘自治能力设计解析 OpenYurt 介绍 阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt ，跟其他开源的容器化边缘计算方案的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 系统零修改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。 同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念： 非侵入式增强 K8s

假如你正在一家典型的企业里工作，需要与多个团队一起工作，并为客户提供一个独立的软件，组成一个应用程序。你的团队遵循微服务架构，并拥有由多个Kubernetes集群组成的广泛基础设施。 由于微服务分布在多个集群中，你需要设计一个解决方案来集中管理所有微服务。幸运的是，你正在使用Istio，提供这个解决方案只不过是另一个配置的变化。 像Istio这样的服务网格技术可以帮助你安全地发现和连接分布在多个集群和环境中的微服务。今天我们来讨论一下使用Istio管理托管在多个Kubernetes集群中的微服务。 架构说明 Istio使用以下组件提供跨集群服务发现： Istio CoreDNS：每个Istio控制平面都有一个CoreDNS。Istio使用它来发现全局范围上定义的服务。例如，如果一个托管在集群1上的微服务需要连接到另一个托管在集群2上的微服务，你需要为运行在集群2上的微服务在Istio CoreDNS上做一个全局条目。 Root CA：由于Istio需要在不同集群上运行的服务之间建立mTLS连接，因此需要使用共享的Root CA为两个集群生成中间CA证书。这就在不同集群上运行的微服务之间建立了信任，因为中间CA共享同一个Root CA。 Istio Ingress网关：集群间的通信通过Ingress网关进行，服务之间没有直接连接。因此，你要确保Ingress网关是可发现的

个人理解. Kubernetes资源相关: 1 CPUThrottlingHigh CPU的limit合理性指标 表达式: sum(increase(container_cpu_cfs_throttled_periods_total{container!="", }[5m])) by (container, pod, namespace) / sum(increase(container_cpu_cfs_periods_total{}[5m])) by (container, pod, namespace) > ( 25 / 100 ) 作用: 查出最近5分钟，超过25%的CPU执行周期受到限制的container,使用到kubelet的两个指标 container_cpu_cfs_periods_total：container 生命周期中度过的cpu周期总数 container_cpu_cfs_throttled_periods_total：container 生命周期中度过的受限的cpu周期总数 2 KubeCPUOvercommit 集群CPU过度使用 表达式: sum(namespace:kube_pod_container_resource_requests_cpu_cores:sum{}) / sum(kube_node_status_allocatable_cpu

Dubbo-go k8s注册中心设计方案与实现 随着云原生的推广，越来越多的公司或组织将服务容器化，并将容器化后的服务部署在k8s集群中。 今天这篇文章将会介绍dubbo-go将k8s作为服务注册中心的方案设计，以及具体实现。到目前为止该方案的实现已经被合并到dubbo-go的master分支。具体实现为 关于Kubernetes的PullRequest 。 k8s管理资源的哲学 k8s作为容器集群化管理方案可以将管理资源的维度可主观的分为服务实例管理和服务接入管理。 服务实例管理，主要体现方式为Pod设计模式加控制器模式。控制器保证具有特定标签（Label）的Pod保持在恒定的数量（多删，少补）。 服务接入管理，主要为Service，该Service默认为具有特定标签（Label）的一批Pod提供一个VIP（ClusterIP）作为服务的接入点，默认会按照round-robin的负载均衡策略将请求转发到真正提供服务的Pod。并且CoreDNS为该Service提供集群内唯一的域名。 k8s服务发现模型 为了明确k8s在服务接入管理提供的解决方案，我们以kube-apiserver 提供的API(HTTPS)服务为例。k8s集群为该服务分配了一个集群内有效的ClusterIP，并通过CoreDNS为其分配了唯一的域名 kubernetes

前言： 最近在研究k8s集群ELK收集容器里面的日志，部署elk时发现Kibana没有连接到es中，报错信息如下: {"type":"log","@timestamp":"2020-06-30T07:09:33Z","tags":["warning","elasticsearch","admin"],"pid":6,"message":"No living connections"} {"type":"log","@timestamp":"2020-06-30T07:09:36Z","tags":["warning","elasticsearch","data"],"pid":6,"message":"Unable to revive connection: http://elasticsearch-0.elasticsearch.kube-system:9200/"} {"type":"log","@timestamp":"2020-06-30T07:09:36Z","tags":["warning","elasticsearch","data"],"pid":6,"message":"No living connections"} {"type":"log","@timestamp":"2020-06-30T07:09:36Z","tags":["license",

作者 | 王夕宁 阿里云高级技术专家 导读 ：本文摘自于阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实战》一书，讲述了如何使用 Istio 进行多集群部署管理来阐述服务网格对多云环境、多集群即混合部署的支持能力。 前文详情： 《如何使用 Istio 进行多集群部署管理：单控制平面 VPN 连接拓扑》 《如何使用 Istio 进行多集群部署管理：单控制平面 Gateway 连接拓扑》 在多控制平面拓扑的配置中，每个 Kubernetes 集群都会安装相同的 Istio 控制平面，并且每个控制平面只会管理自己集群内的服务端点。通过使用 Istio 网关、公共根证书颁发机构（CA）以及服务条目 ServiceEntry，可以将多个集群配置组成一个逻辑上的单一服务网格。这种方法没有特殊的网络要求，因此通常被认为是在 Kubernetes 集群之间没有通用网络连接时的一种最简单方法。 在这种拓扑配置下，Kubernetes 跨集群通信需要服务之间的双向 TLS 连接，要在集群之间启用双向 TLS 通信，每个集群的 Citadel 将配置由共享的根 CA 生成的中间 CA 证书，如图所示。 （多控制平面） 部署控制平面 从共享的根 CA 为每个集群的 Citadel 生成中间 CA 证书，共享的根 CA 启用跨不同集群的双向 TLS 通信。为了便于说明，我们将 samples

coredns之所以如此名声大噪，就是因为从kubernetes1.9开始引入，作为kubernetes内部服务发现的默认dns。毫无疑问kubernetes是coredns的后端之一，所以我们讲coredns，就从kubernetes作为其后端开始。 coredns的诸多特性网上很多文章都有提及，在这里不再赘述。简单对比下其相对于bind和skydns的优势： bind可以将解析存储到mysql或者文件中，coredns也可以将解析存储到etcd或者文件中，也支持将kubernetes作为其后端，直接调用kubernetes的api获取解析数据，然后缓存到本地内存。coredns支持插件扩展，目前在第三方插件中还同时支持将powerdns及amazondns作为其后端，后续还会支持越来越来的后端。bind在kubernetes的应用场景下，基本无用武之地。 coredns本身就是skydns的继任者，支持skydns的所有特性，而且性能更好，更易于扩展。其插件式特性无论是bind还是skydns都无法比拟。 coredns官方网站地址： https://coredns.io coredns代码地址： https://github.com/coredns/coredns coredns官方插件地址： https://coredns.io/plugins coredns第三方插件地址

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 作者 | 新胜 阿里云技术专家 导读： OpenYurt 开源两周以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，我们特地推出【深度解读OpenYurt】系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩展能力。 OpenYurt 介绍 阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt，跟其他开源的容器化边缘计算方案的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 系统零修改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。 同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念： 非侵入式增强 K8s 保持和云原生社区主流技术同步演进 YurtHub 架构说明