作者 | 褚杏娟 当地时间 8 月 31 日,Istio 1.15.0 正式发布,这是 2022 年的第三个 Istio 版本,Kubernetes 1.22 到 1.25 版本已正式支持 Istio 1.15.0。 根据公告,Istio 1.15.0 版本的重要更新是支持 arm64,用户可以在 Raspberry Pi 或 Tau T2A VM 上运行。 2019 年时,就有开发者抱怨无法在 arm64 上使用 Istio。当时开发者“iecedge”通过修改代码在私人环境里构建了 Istio 1.2
Google 声明[2]将选择 Cilium[3] 作为 GKE 网络的数据面 V2 以便增加其容器安全性和可观测性。
Envoy/Istio 1.1 中有个有趣的新特性:负载均衡提供了区域感知的能力。简单说来,就是在分区部署的较大规模的集群,或者公有云上,Istio 负载均衡可以根据节点的区域标签,对调用目标做出就近选择。在跨区部署的应用中,原始的 Kubernetes 负载均衡可能会把来自 A 区的请求发送给远在 B 区的服务,造成高成本的跨区调用。要缩减这种损耗,通常都需要实现更多的逻辑,Istio 的区域感知特性在某种程度上提供了一种解决办法。
渐进式交付是持续交付的下一步, 它将新版本部署到用户的一个子集,并在将其滚动到全部用户之前对其正确性和性能进行评估, 如果不匹配某些关键指标,则进行回滚。
关注容器圈的朋友一定会注意到最近一年的高频词:Service Mesh。这么绕口的词,到底是什么意思?引用一篇文章里对其的解释:
自Google Anthos推出以来在混合云领域受到极大关注,作为Google进入ToB混合云市场的战略级产品,Anthos集成了如GKE (Google Kubernetes Engine)、GKE On-Prem、Istio on GKE等……引起业界的关注。可以说这又是Google又一大利器。那么混合云作为企业数字化转型的重要基础设施建设,既留了核心数据,降低了迁移风险,又能在原来资源的基础上增加公共云的弹性,一举多得,成为当前云计算发展的热门话题。而作为数字化转型的另外一个风向标DevOps如何与当前的混合云发展进行协作,带向企业进入云原生时代,将会成日今后数字化建设的一个重要主题。
Istio 在网格中部署的Pod中注入initContainer,istio-init。该istio-init容器设置荚的网络流量重定向到/从Istio三轮代理。这就要求将用户或服务帐户部署到网格上的Pod具有足够的Kubernetes RBAC权限才能部署具有NET_ADMIN和NET_RAW功能的容器。对于某些组织的安全合规性,要求Istio用户具有提升的Kubernetes RBAC权限是有问题的。Istio CNI插件是istio-init执行相同网络功能但不要求Istio用户启用提升的Kubernetes RBAC权限的容器的替代。
互联网后台架构技术的发展一日千里。身处技术变革浪潮的后台同学,应该都深切地感受到了云原生技术在公司内外的蓬勃发展。云原生技术正在逐渐成为后台工程师与架构师们的必修课,而 kubernetes 正是云原生的基石,聚光灯下的焦点。
随着Google发布了其混合云服务:云服务平台(Cloud Service Platform,以下简称CSP)测试版,正式进军混合云领域,公有云三巨头全部拥有了混合云相关产品,云巨头角力混合云的时代正式开启。早在2015年,微软率先推出Auzre Stack混合云产品;2018年年底,AWS则跟进推出了其混合云产品OutPosts。
在 Istio 项目的 istioctl 目录中,有一些子目录,每个目录都有不同的作用和功能。以下是这些子目录的详细介绍:
最初于2018年11月17日在Medium发布。自此以来,该帖子已更新,可以使用最新版本的JHipster(6.3.0)和Istio(1.3.0)。
微服务架构中,各服务间常有通信交互,以完成复杂业务流程,这给安全性和可扩展性带来挑战。启用双向 TLS(mTLS)可提高安全性,本文将详述 mTLS 的使用入门方法。
使用的CNCF项目包括:Envoy、Fluentd、Helm、Kubernetes、Prometheus
最近看到了一份收集Kubernetes故障案例的资料,资料由ZalandoTech的高级首席工程师Henning Jacobs加以维护。这个由社区驱动的项目全面介绍了Kubernetes反模式以及为何导致Kubernetes运行错误的原因。
根据CNCF的最新年度调查,很明显,很多人对在他们的项目中使用服务网格表现出了浓厚的兴趣,并且许多人已经在他们的生产中使用它们。近69%的人正在评估Istio,64%的人正在研究Linkerd。Linkerd是市场上第一个服务网格,但是Istio使服务网格更受欢迎。这两个项目都是最前沿的,而且竞争非常激烈,因此选择一个项目是一个艰难的选择。在此博客文章中,我们将了解有关Istio和Linkerd体系结构,其运动部件的更多信息,并比较其产品以帮助您做出明智的决定。
最近,很多人问我 NodePorts,LoadBalancer和 Ingress 之间的区别是什么?它们是将外部流量引入集群的不同方式,而且它们的运行形式各不相同。接下来,请你跟我一起,来看看他们是如何工作的,以及它们各自的适用情况。
将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性、可伸缩性和可复用性。但这也带来了一些安全问题:
作者 | 褚杏娟 近日,云原生应用网络公司 Solo.io 推出了集成产品 Gloo 平台——一个模块化的解决方案,将 API 网关、服务网格、安全性和云原生网络技术集成到了一个统一的应用网络平台中。 Gloo 平台由开源项目 Istio、Envoy 和 Cilium 提供支持,提供集成的 API 网关、Kubernetes 入口、多集群和多租户服务网格、Kubernetes 网络、安全性和可观察性。据官方数据,Gloo 平台框架可以将企业运营成本降低 30-40%。据悉,Gloo 平台的功能包括: 跨
最近,有人问我 NodePort,LoadBalancer 和 Ingress 之间的区别是什么。 它们是将外部流量引入群集的不同方式,并且实现方式不一样。 我们来看看它们是如何工作的,以及什么时候该用哪种。
毛艳清,富士康工业互联网科技服务事业群运维中心主管,现负责公有云和私有云的运维工作,聚焦在云计算和云原生领域,主要关注企业迁云的策略与业务价值、云计算解决方案、云计算实施与运维管理,以及云原生技术的布道和落地实践。
Google Next18 活动中,Google 宣称将会把 GKE 上的无服务器插件以 Knative 的名称进行开源。当时它被描述为无服务器平台的构建块,由此推断,Knative 可能需要 Google、Pivotal 或者 RedHat 的协助才能使用。这可能是开源的古怪时机。从我最初的摸索来看,Knative 能工作;当我把 Heroku/Cloud Foundry buildpacks 加入进来之后,整个系统变得越来越像 Heroku/Cloud Foundry,相对于原始 Kubernetes,我更加了解和喜爱这一系统。
第1章 你好,Istio 前言 服务网格是服务(包括微服务)之间通信的控制器。随着越来越多的容器应用的开发和部署,一个企业可能会有成百上千或数万计的容器在运行,怎样管理这些容器或服务之间的通信,包括服务间的负载均衡、流量管理、路由、运行状况监视、安全策略及服务间身份验证,就成为云原生技术的巨大挑战 依据CNCF基金会(Cloud-Native Computing Foundation)的定义,云原生是对在现代的动态环境下(比如云计算的三大场景:公有云、私有云及混合云)可用来构建并运行可扩展应用的技术的总称;
该文为前期热门文章《eBPF将如何提供服务网格解决方案--告别sidecar》的后续。其介绍了Cilium提供非sidecar模式的服务网格的解决方案。在本篇文章中,我们将目光扩展到mTLS的主题上,并研究Cilium如何提供基于mTLS非sidecar模式的双向认证,其同时具备出色的安全性和性能优势。
周五下午在公司的服务网格月度讨论会上,一位同事为大家分享了在服务网格中使用 ebpf 来优化提升 istio 中 sidecar 和 RS 间的通信效率。听过之后手痒难,想测试一把 ebpf。当这位同事在这方面做的还是比较深入的,而且给内核和 istio 中提交了pr。有兴趣的同学可以看看他的 github:https://github.com/ChenLingPeng 还有他的 blog。
客座撰稿人:Karen Bruner,StackRox技术专员。原文可以在这里找到。
原文:http://mp.weixin.qq.com/s/dHaiX3H421jBhnzgCCsktg 当我们使用k8s集群部署好应用的Service时,默认的Service类型是ClusterIP,这种类型只有 Cluster 内的节点和 Pod 可以访问。如何将应用的Service暴露给Cluster外部访问呢,Kubernetes 提供了多种类型的 Service,如下: ClusterIP ---- ClusterIP服务是Kuberntets的默认服务。它在集群内部生成一个服务,供集群内的其他应用
周五下午在公司的服务网格月度讨论会上,一位同事为大家分享了在服务网格中使用 ebpf 来优化提升服务网格 istio 中 sidecar 和 RS 间的通信效率。听过之后手痒难,想测试一把 ebpf。这位同事在这方面做的还是比较深入的,而且给内核和 istio 中提交了pr。有兴趣的同学可以看看他的 github:https://github.com/ChenLingPeng 还有他的 blog。
本文档介绍了一些用于创建具有弹性和可扩展性的应用程序的模式和实践,这是许多现代架构练习的两个基本目标。设计良好的应用程序会随着需求的增加和减少而上下扩展,并且具有足够的弹性以承受服务中断。构建和运行满足这些要求的应用程序需要仔细规划和设计。
其中包括服务网格。从Istio到谷歌Kubernetes引擎(GKE)到Aspen Mesh的公开测试版,有关微服务规模化运营的成熟解决方案已经随处可见。
甫一见面,方璞便向梁胜抛出了一个重磅问题:“在K8S之后,你觉得未来最有前途的容器技术是什么呢?”方璞是华为云容器服务域的产品总监,主要负责华为云容器的构建和部署。
通过将一个单一应用划分为多个原子服务的方式,可以提供更好的灵活性,可扩展性以及重用服务的能力。然而微服务对安全有特殊的要求:
在 2018 年,Etsy 将它的服务基础设施从自我管理的数据中心迁移到云端配置(我们当时在博客上写了这件事)。这种改变提供了改善整个公司技术流程的机会。对于 Search 团队而言,云环境所带来的灵活扩展让我们可以完全重新评估一个有些繁琐的部署流程。在已有的金丝雀发布架构模式的启发下,我们编写了一个新的自定义工具来补充现有的部署基础设施。
该博客描述了 Cilium 如何在不使用 Sidecar 的情况下提供服务网格。在这篇博客中,我们将扩展 mTLS 的主题,并研究 Cilium 如何提供具有出色安全性和性能特征的基于 mTLS 的无边车身份验证。
Top Google Cloud tools for web application development. Google gives a wide scope of instruments and administrations for its clients. As one of the top cloud suppliers, Google must stay aware of the aggressive idea of the cloud and discharge administrations to address the issues of its clients. Like AWS and Azure, there is a scope of Google Cloud apparatuses for clients to look over to help facilitate a portion of the pressure that accompanies the open cloud.
在谷歌发明 Kubernetes 后的几年中,它彻底改变了 IT 运维的方式,并逐渐成为了事实标准,可以帮助组织寻求高级容器编排。那些需要为其应用程序提供 最高级别可靠性、安全性和可扩展性 的组织选择了谷歌 Kubernetes 引擎(Google Kubernetes Engine, GKE)。光是 2020 年二季度,就有 10 多万家公司使用谷歌的应用现代化平台和服务(包括 GKE)来开发和运行他们的应用。到目前为止, Kubernetes 还需要手工装配和修补程序来优化它才能满足用户需求。如今,谷歌推出了 GKE Autopilot,这是一个管理 Kubernetes 的革命性运营模式,让用户专注于软件开发,而 GKE Autopilot 则负责基础架构。
Kubernetes是当前最为流行的开源容器编排平台,成为众多企业构建基础架构的首选。在本文中,我们将探讨针对你的用例构建基础设施的最佳方式,以及你可能要根据各种限制条件做出的各种决定。
嗨,在当今动态的环境中,在 450 多家经过 Kubernetes 认证的服务提供商和众多经过 Kubernetes 认证的发行版中进行导航可能是一项艰巨的挑战。本博客旨在通过展示精心整理的2023 年最常用和最流行的 Kubernetes 工具列表来简化此过程。
Ambient 是 Istio 刚刚宣布支持的一种新的数据面模式,在本篇文章中,我们将尝试安装 Istio 的 ambient 模式,并采用 bookinfo demo 来体验 ambient 提供的 L4 和 L7 能力。
istio/pilot/pkg/networking/core/v1alpha3/loadbalancer/loadbalancer.go是Istio项目中负责负载均衡的文件。它定义了一些结构体和函数,用于处理负载均衡策略。
Ambient is a new data-plane model that Istio has just announced support for. In this post, we will try to install Istio’s ambient model and use the bookinfo demo to experience the L4 and L7 capabilities offered by ambient.
Kube-Bench是一款针对Kubernete的安全检测工具,从本质上来说,Kube-Bench是一个基于Go开发的应用程序,它可以帮助研究人员对部署的Kubernete进行安全检测,安全检测原则遵循CIS Kubernetes Benchmark。
新智元报道 来源:Google Cloud Next18 作者:新智元编辑部 【新智元导读】谷歌云年度Next大会召开,李飞飞和李佳的“佳飞?”组合也迎来了她们在谷歌云的又一座里程碑:度过艰辛时刻
客座文章作者:Gianluca Arbezzano,Equinix Metal 软件工程师,CNCF 大使;Alex Palesandro,都灵理工学院研究助理
原文链接:https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870
Cilium 1.11测试版(Beta)为你带来了一系列引人注目的功能和增强功能,包括OpenTelemetry支持、感知拓扑的负载均衡、Kubernetes APIServer策略匹配,以及更多功能。本文将为您详细介绍这个令人振奋的版本,以及它为现代应用程序网络安全和性能带来的突破。
随着软件供应链攻击的增加,保护我们的软件供应链变得更加重要。此外,在过去几年中,容器的采用也有所增加。有鉴于此,对容器镜像进行签名以帮助防止供应链攻击的需求日益增长。此外,我们今天使用的大多数容器,即使我们在生产环境中使用它们,也容易受到供应链攻击。在传统的 CI/CD 工作流中,我们构建镜像并将其推入注册中心。供应链安全的一个重要部分是我们构建的镜像的完整性,这意味着我们必须确保我们构建的镜像没有被篡改,这意味着保证我们从注册中心中提取的镜像与我们将要部署到生产系统中的镜像相同。证明镜像没有被篡改的最简单和最好的方法之一(多亏了 Sigstore)是在构建之后立即签名,并在允许它们部署到生产系统之前验证它。这就是 Cosign 和 Kyverno 发挥作用的地方。
Rancher 是为使用容器的公司打造的容器管理平台。Rancher 简化了使用 Kubernetes 的流程,方便开发者可以随处运行 Kubernetes(Run Kubernetes Everywhere),以便于满足 IT 需求规范,赋能 DevOps 团队。
在 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 注解。
领取专属 10元无门槛券
手把手带您无忧上云