在 Kubernetes 集群边缘对外提供网络服务的时候，通常需要借助 Ingress 对象，这个对象提供了暴露 Service 所必须的核心要素，例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候，往往会有更多的具体需求，这时 Ingress 对象所提供的核心功能就有些力不从心了，各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解，来完成对 Ingress 特定行为的控制，完成各自的个性化功能，例如认证、路径变更、黑白名单等，这就让 Ingress 对象变成了一个奇怪的东西：结构化的核心结构，和非结构化的标注结合起来形成各种 Ingress 方言，并且后期还出现了 Traefik Middleware 这样的 CRD 配置，这给 Ingress 功能的集中管理造成了一个较大的困扰；另外 Ingress 中可以随意定制主机名、路径以及后端服务，也给共享集群的用户造成了一定的安全隐患。包括 Cotour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达，客观上也让 Ingress 世界更为分裂。 例如要移除路径前缀，Nginx Ingress 控制器需要使用 nginx.ingress.kubernetes.io/rewrite-target 注解，而 Traefik 1.7 中则需要使用 traefik.ingress.kubernetes.io/rule-type: PathPrefixStrip 注解。
Rancher是一套容器管理平台，它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes，满足IT需求并为DevOps团队提供支持。
您可以使用多种解决方案，例如 Swarm、Kubernetes……从一定数量的应用程序和/或基础设施中，Kubernetes在高可用性和弹性方面往往占主导地位。这就是为什么本文的目的是向您解释如何从使用 Docker Compose 的环境迁移到 Kubernetes。
对于基于HTTP的服务来说，不同的URL地址经常对应到不同的后端服务（RS）或者虚拟服务器（ Virtual Host），这些应用层的转发机制仅通过Kubernetes的Service机制是无法实现的。
Envoy/Istio 1.1 中有个有趣的新特性：负载均衡提供了区域感知的能力。简单说来，就是在分区部署的较大规模的集群，或者公有云上，Istio 负载均衡可以根据节点的区域标签，对调用目标做出就近选择。在跨区部署的应用中，原始的 Kubernetes 负载均衡可能会把来自 A 区的请求发送给远在 B 区的服务，造成高成本的跨区调用。要缩减这种损耗，通常都需要实现更多的逻辑，Istio 的区域感知特性在某种程度上提供了一种解决办法。
Rancher简介 Rancher是一套容器管理平台，它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes，满足IT需求并为DevOps团队提供支持。 Kubernetes不仅已经成为的容器编排标准，它也正在迅速成为各类云和虚拟化厂商提供的标准基础架构。Rancher用户可以选择使用Rancher Kubernetes Engine(RKE)创建Kubernetes集群，也可以使用GKE，AKS和EKS等云Kubernetes服务。 Rancher用户还可以导入和管理现有的Kubernetes集群。 Rancher支持各类集中式身份验证系统来管理Kubernetes集群。例如，大型企业的员工可以使用其公司Active Directory凭证访问GKE中的Kubernetes集群。IT管理员可以在用户，组，项目，集群和云中设置访问控制和安全策略。 IT管理员可以在单个页面对所有Kubernetes集群的健康状况和容量进行监控。 Rancher为DevOps工程师提供了一个直观的用户界面来管理他们的服务容器，用户不需要深入了解Kubernetes概念就可以开始使用Rancher。 Rancher包含应用商店，支持一键式部署Helm和Compose模板。Rancher通过各种云、本地生态系统产品认证，其中包括安全工具，监控系统，容器仓库以及存储和网络驱动程序。下图说明了Rancher在IT和DevOps组织中扮演的角色。每个团队都会在他们选择的公共云或私有云上部署应用程序。
从 Linkerd 2.9 版开始，有两种方式可以让 Linkerd 代理 与您的 Ingress Controller 一起运行。
调试服务网格(service mesh)可能很困难。当某些东西不起作用时， 是代理(proxy)有问题吗？与应用程序(application)？与客户端(client)？与底层网络？(underlying network)有时， 没有什么比查看原始网络数据更好的了。
Ingress、Istio 和 APISIX 都是与云原生环境紧密相关的技术，在现代应用部署中扮演着重要角色，尤其是在微服务架构中。今天这篇文章内容，先弄明白他们都是干嘛的，然后有什么区别，后面的文章再分别深入展开实例了解。
Helm是一个作用于k8s的包管理工具。类似于其它的包管理工具如apt/yum ,应用开发者可以管理应用包chart之间的依赖关系，以便于部署复杂的k8s应用。
Ingress是Kubernetes中实现负载均衡和路由的重要组件，它可以将流量路由到不同的服务中。Ingress支持HTTP和HTTPS两种协议，但默认情况下只支持HTTP。如果要实现HTTPS访问，需要进行一些配置。
https://github.com/jenkinsci/kubernetes-plugin
如果需要将TKE的信息展示给多个部门的人查看，但是又不想让他们通过控制台查看，这边可以搭建一个dashborad用来展示。
我们知道真正提供服务的是后端的pod，但是为了负载均衡，为了使用域名，为了….,service诞生了，再后来ingress诞生了，那么为什么需要有Ingress呢？先看看官网怎么说的：
Kubernetes入口（Ingress）是一种将集群服务连接到集群外部的方法。为了正确地将流量路由到服务后端，集群需要一个入口控制器。Ingress控制器负责根据Ingress API对象的信息为后端设置正确的目的地。实际流量通过代理服务器路由，代理服务器负责诸如负载平衡和SSL/TLS（稍后的“SSL”指SSL或TLS）终止等任务。由于涉及加密操作，SSL终止是一个CPU密集型操作。为了从CPU中卸载一些CPU密集型工作，基于OpenSSL的代理服务器可以利用OpenSSL引擎API和专用加密硬件的优势。这将为其他事情释放CPU周期，并提高代理服务器的总体吞吐量。
Service 是由 kube-proxy 组件，加上 iptables 来共同实现的。
在快节奏的软件开发世界中，有效管理依赖关系对构建安全可靠的应用程序至关重要。在开源软件安全领域获得认可的一款工具是 OWASP Dependency-Track。本文旨在全面介绍 Dependency Track，深入了解其功能、目的以及在 Kubernetes 上部署的方法。
Kubernetes是一个开源的容器调度和编制系统，最初由谷歌创建，然后捐赠给云计算基金会。Kubernetes自动安排容器在服务器集群中均匀运行，从开发人员和操作人员中抽象出这个复杂的任务。最近，Kubernetes已经成为最受欢迎的容器协调器和调度器。
凭借明确定义的一致性和分层API模型，Gateway API已经展现出许多前景和长远发展的可能。
最近，有人问我 NodePort，LoadBalancer 和 Ingress 之间的区别是什么。 它们是将外部流量引入群集的不同方式，并且实现方式不一样。 我们来看看它们是如何工作的，以及什么时候该用哪种。
翻译人：Ksher，该成员来自云+社区翻译社
作为上个月发布的Linkerd 1.0的一部分，我们发现一些人已经开始注意Linkerd的服务网格API。随着1.0版本的发布，我们认为需要花些时间来解释这个API的作用，以及这对于Linkerd的未来意味着什么。我们还将展示这个API的即将发布的功能之一 —— 动态控制Linkerd的每项服务的通信策略。
service是k8s中的一个重要概念，主要是提供负载均衡和服务自动发现。 Service 是由 kube-proxy 组件，加上 iptables 来共同实现的。
Istio 从 v1alpha3 开始，用 Ingress Gateway 组件替代了符合 Kubernetes 规范的 Ingress Controller，因此对入站流量具有了更大的控制能力，但是用法也有了较大不同。
上一篇我们通过deployment实现了pod的横向扩展，但是仍然不能负载，也不能对外提供服务，现在我们来看看如何通过k8s实现负载与外网访问
Kubernetes Dashboard 终于发布 2.0 正式版本，从 Betat版本 到 v2.0.0正式版本 发布，历时一年多。
在工作中有一个在切面中需要记录一下操作日志的需求，而且要求这些操作日志要存入数据库，并且无论业务层有什么异常，日志照常记录，那就不能沿用业务层的事务，而是需要新启一个事务了。 sping的声明式事务就是靠AOP来实现的，一般事务都在业务层中启用，那如果要在AOP的逻辑中启用一个新的事务要怎么做呢？比如下面的例子：
2.准备尝试下软键盘是否起作用，结果在机器右下方任务管理器向上箭头处藏着2个特殊图标：1个是启用了筛选键，另1个是启用了鼠标键，有疑点；
该博客描述了 Cilium 如何在不使用 Sidecar 的情况下提供服务网格。在这篇博客中，我们将扩展 mTLS 的主题，并研究 Cilium 如何提供具有出色安全性和性能特征的基于 mTLS 的无边车身份验证。
简单服务路由，将 Node 的入站流量从 80 端口转发到服务 blog-anoyi， 查看 ingress 规则：
毛艳清，富士康工业互联网科技服务事业群运维中心主管，现负责公有云和私有云的运维工作，聚焦在云计算和云原生领域，主要关注企业迁云的策略与业务价值、云计算解决方案、云计算实施与运维管理，以及云原生技术的布道和落地实践。
渐进式交付是持续交付的下一步， 它将新版本部署到用户的一个子集，并在将其滚动到全部用户之前对其正确性和性能进行评估， 如果不匹配某些关键指标，则进行回滚。
Rancher 是为使用容器的公司打造的容器管理平台。Rancher 简化了使用 Kubernetes 的流程，方便开发者可以随处运行 Kubernetes（Run Kubernetes Everywhere），以便于满足 IT 需求规范，赋能 DevOps 团队。
故事的起因是朋友所在的部门最近基于auth2实现单点登录，他们在测试环境单点登录，运行得好好的，但他们把单点登录上到预发布环境，发现单点登录不好使了。他们有部分系统是以授权码式接入，发现第一次登录拿到授权码进行换取token时，会提示授权码失效。而他们测试环境和预发布环境的代码是一样的。
最近，很多人问我 NodePorts，LoadBalancer和 Ingress 之间的区别是什么？它们是将外部流量引入集群的不同方式，而且它们的运行形式各不相同。接下来，请你跟我一起，来看看他们是如何工作的，以及它们各自的适用情况。
创建一个nginx deployment并修改了默认页面 /usr/share/nginx/html/index.html为hello nginx，这里先通过http方式创建ingress：
作为我们上个月发布的Linkerd1.0的一部分，我们已经悄悄地看到了很少有人注意的东西——Linkerd的服务网格API。随着1.0版本的发布，我们认为我们需要花些时间来解释这个API的作用，以及它对Linkerd的未来意味着什么。我们还将展示这个API的即将发布的一个功能——动态控制Linkerd的每项服务的通信策略。
关注容器圈的朋友一定会注意到最近一年的高频词：Service Mesh。这么绕口的词，到底是什么意思？引用一篇文章里对其的解释：
安装 Longhorn 的 Kubernetes 集群中的每个节点都必须满足以下要求：
「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/container )。
这次介绍的是在 SPIRE Server 和 Vault Server 之间建立 OIDC 联邦的方法。设置联邦之后，SPIRE 认证的工作负载就能使用 JWT-SVID 来通过 Vault Server 的认证。这样工作负载就无需使用 AppRole 或者用户名密码的方式来进行认证了。
free -h，显示内存和利用率 用swapon -s可以检查特定分区，逻辑卷或文件的交换，-s是摘要的含义，用它来获取交换的详细信息，以千字节为单位 或者使用top命令 vmstat，可以用该命令查看交换和交换信息，无法查看交换的总值
● 在kubernetes中，Pod是应用程序的载体，我们可以通过Pod的IP来访问应用程序，但是Pod的IP地址不是固定的，这就意味着不方便直接采用Pod的IP对服务进行访问。
本文所讲的配置规则，都配置在 annotations（局部配置） 中，Ingress Nginx Deployment 必须配置 --annotations-prefix 参数，默认以 nginx.ingress.kubernetes.io 开头。
该文为前期热门文章《eBPF将如何提供服务网格解决方案--告别sidecar》的后续。其介绍了Cilium提供非sidecar模式的服务网格的解决方案。在本篇文章中，我们将目光扩展到mTLS的主题上，并研究Cilium如何提供基于mTLS非sidecar模式的双向认证，其同时具备出色的安全性和性能优势。
我们知道在 Kubernetes 集群内部使用 kube-dns 实现服务发现的功能，那么我们部署在 Kubernetes 集群中的应用如何暴露给外部的用户使用呢？我们知道可以使用 NodePort 和 LoadBlancer 类型的 Service 可以把应用暴露给外部用户使用，除此之外，Kubernetes 还为我们提供了一个非常重要的资源对象可以用来暴露服务给外部用户，那就是 Ingress。对于小规模的应用我们使用 NodePort 或许能够满足我们的需求，但是当你的应用越来越多的时候，你就会发现对于 NodePort 的管理就非常麻烦了，这个时候使用 Ingress 就非常方便了，可以避免管理大量的端口。
原文地址：https://dzone.com/articles/a-service-mesh-for-kubernetes-part-ix-grpc-for-fun
领取专属 10元无门槛券
手把手带您无忧上云
