Istio

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Kiali提供了问题的答案 我的Istio服务网格中的微服务是做什么的？ 描述 微服务架构将整体结构分解成许多组合在一起的小块。已经出现了用于保证服务之间的通信的模式，例如容错（通过超时，重试，断路等）以及分布式跟踪，以便能够看到呼叫的去向。 服务网格现在可以在平台级别上提供这些服务，并使应用程序编写者从这些任务中解放出来。路由决策在网格级别完成。 Kiali与Istio合作，可视化服务网格拓扑，断路器或请求率等功能。 Kiali还包括Jaeger Tracing，可以提供开箱即用的分布式跟踪功能。 https://github.com/kiali/kiali 来源： oschina 链接： https://my.oschina.net/u/866802/blog/1861605

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 资料： https://www.2cto.com/kf/201805/749007.html https://blog.csdn.net/wenwenxiong/article/details/80068697 一、前言 Istio是Google/IBM/Lyft联合开发的开源项目，2017年5月发布第一个release 0.1.0，Service Mesh微服务新秀，采用sidecar的实现方式，有着高性能、极低的资源开销、无代码入侵等优秀特性，扛起微服务大旗，并与当下火热的k8s Paas容器云平台深度整合。官方描述为: An open platform to connect, manage, and secure microservices 1 Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，与k8s深度整合。 各组件工作图： 控制层面组件： 1.Pilot：负责将调度的配置下发到各svc endpoint后pod中注入的Envoys 2.Mixer：负责流量策略等统一调度 3.Citadel：负责安全策略，如TLS证书颁发 数据层面组件： Envroys：将envroys proxy容器，以sidecar的方式注入到svc后端的pod中

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在微服务领域，分布式跟踪正逐渐成为调试和跟踪应用程序最重要的依赖工具。 最近的聚会和会议上，我发现很多人对分布式跟踪的工作原理很感兴趣，但同时对于分布式跟踪如何与Istio和 Aspen Mesh 等服务网格进行配合使用存在较大的困惑。特别地，我经常被问及以下问题： Tracing如何与Istio一起使用？在Span中收集和报告哪些信息？ 是否必须更改应用程序才能从Istio的分布式跟踪中受益？ 如果目前在应用程序中报告Span，它将如何与Istio中的Span进行交互？ 在这篇博客中，我将尝试回答这些问题。 在我们深入研究这些问题之前，建议先快速了解为什么我要写与分布式跟踪相关博客。如果您关注 Aspen Mesh 的博客，您会注意到我写了两篇与tracing相关的博客，一篇关于 ”使用Istio跟踪AWS中的服务请求“ ，另一篇关于 ”使用Istio跟踪gRPC应用程序” 。 我们在Aspen Mesh有一个非常小的工程团队，如果经常在子系统或组件上工作，您很快就会成为（或标记或分配）常驻专家。我在微服务中添加了分布式跟踪，并在AWS环境中将其与Istio集成，在此过程中发现了值得分享的各种有趣的经验。在过去的几个月里，我们一直在大量使用跟踪来了解我们的微服务，现在这种方法已经成为我们排查问题首先采用的手段

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者 | 徐迪、张晓宇 导读 ：本文根据徐迪和张晓宇在 KubeCon NA 2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次，会分享几个阿里巴巴经济体的通用场景，以及他们是如何解决这些挑战的。 Sidecar 简介 Sidecar 容器并不是一个新鲜事物。它是一种设计模式，主要用来做一些辅助的工作，比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话，就会发现 Docker Ambassador 其实就是 Sidecar。 如上所示，Service Consumer 和 Redis Provider 强耦合，部署在同一个节点上。如果这个时候，Redis Provider 出现问题，需要连接到另外一个 Redis 实例上，需要重新配置，并重启 Service Provider。 那么在引入了 Ambassador 以后，问题变得相对简单些，只需要重启这里的 Redis Ambassador 即可，并不需要 Service Consumer 进行任何变动。 当然这种模式，还可以进行跨节点通信，比如下图。这样 Service Consumer 和 Redis Provider 就可以部署在不同的节点上。在某种程度上

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者 | 孙健波、汪萌海、陈有坤、李鹏 业界要闻 CNCF 宣布 TUF 毕业 CNCF 宣布 TUF（The update Framework）项目正式毕业，成为继 Kubernetes、Premetheus、Envoy、CoreDNS、containerd、Fluentd Jaeger 以及 Vitess 之后，第九个正式毕业的项目。TUF 是一项用于保护软件更新系统的开源安全技术，也是从云原生计算基金会毕业的第一个以规范与安全性为重点的项目。与此同时，TUF 还是首个源自高校的 CNCF 毕业项目。 Istio 发布安全公告 CVE-2019-18801：该漏洞通过向下游发送 HTTP/2 大 header 请求影响 Envoy 的 HTTP/1 编解码器，利用此漏洞可能导致拒绝服务、权限逃逸或信息泄露； CVE-2019-18802：HTTP/1 编解码器没有修剪掉 header 值之后的空格，使攻击者可以绕开 Istio 的策略，最终导致信息泄露或特权升级； CVE-2019-18838：收到不带 "Host" header HTTP 请求后， Envoy 路由管理器会由于空指针导致 Envoy 进程异常终止。 解决方案 对于 Istio 1.2.x 版本：升级到 Istio 1.2.10 或以上；

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 图为 KubeCon NA 2019 大会分享现场照 Speaker: 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张晓宇 阿里云技术专家：负责阿里巴巴云原生应用容器平台的生态建设，主要设计和研发节点稳定性和资源利用率相关解决方案，同时也是 Kubernetes 社区热心的成员和贡献者。 本文根据徐迪和张晓宇在 KubeCon NA2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次，我们会分享几个蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。当然，现在还是有很多的挑战需要后续继续解决，邀请大家与我们一同努力。 Sidecar 简介 Sidecar 容器并不是一个新鲜事物。它是一种设计模式，主要用来做一些辅助的工作，比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话，就会发现 Docker Ambassador 其实就是 Sidecar。 看看如上这个例子，Service Consumer 和 Redis Provider 强耦合，部署在同一个节点上。如果这个时候，Redis Provider 出现问题，需要连接到另外一个

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> > 原文链接： Istio 1.4 部署指南 Istio 一直处于快速迭代更新的过程中，它的部署方法也在不断更新，之前我在 1.0 版本中介绍的安装方法，对于最新的 1.4 版本已经不适用了。以后主流的部署方式都是用 istioctl 进行部署，helm 可以渐渐靠边站了~~ 在部署 Istio 之前，首先需要确保 Kubernetes 集群（kubernetes 版本建议在 1.13 以上）已部署并配置好本地的 kubectl 客户端。 1. Kubernetes 环境准备 为了快速准备 kubernetes 环境，我们可以使用 sealos 来部署，步骤如下： 前提条件 下载 kubernetes 离线安装包 下载 最新版本sealos 务必同步服务器时间 主机名不可重复 安装 kubernetes 集群 $ sealos init --master 192.168.0.2 \ --node 192.168.0.3 \ --node 192.168.0.4 \ --node 192.168.0.5 \ --user root \ --passwd your-server-password \ --version v1.16.3 \ --pkg-url /root/kube1.16.3.tar.gz