Istio

I'm trying to set up a local k8s cluster and on minikube with installed istio and I have an issue with enabling distributed tracing with Jaeger. I have 3 microservices A -> B -> C . I am propagating the all the headers that are needed: {"x-request-id", "x-b3-traceid", "x-b3-spanid", "x-b3-parentspanid", "x-b3-sampled", "x-b3-flags", "x-ot-span-context"} But on Jaeger interface, I can only see the request to the service A and I cannot see the request going to service B. I have logged the headers that are sent in the request. Headers from service A: Header - x-request-id: c2804368-2ff0-9d90-a2aa

作者 | 易立 阿里云资深技术专家 本文整理自易立在 2019 携程技术峰会上发表的题目为《拐点已至，云原生引领数字化转型升级》的演讲。 关注“阿里巴巴云原生”公众号，回复关键词“转型”即可下载本文 PPT。 今天我跟大家分享的题目是“拐点已至，云原生引领数字化转型升级”。先做个简单的自我介绍，我叫易立，来自于阿里云容器平台，从 2015 年开始负责阿里云容器产品，之前在 IBM 工作 14 年，主要负责企业中间件和云计算的产品研发。 今天会跟大家分享我们对云原生领域的简单思考，以及我们对云原生发展四个趋势大概的介绍： 拥抱 Serverless – 极致弹性，无需运维； 服务网格 – 将服务治理能力与应用解耦，并下沉到基础设施层； 云原生应用管理标准化 – 构建高效、自动化和可信赖的应用交付体系； 计算无边界 – 实现云-边缘-IoT 设备的高效协同。 云原生基本概念 先简单介绍云原生一些基本的概念。 我们接触了很多的客户，对于这些客户而言，上不上云已经不是问题，他们关注的是该怎么上云？该如何充分利用云的能力、最大化云的价值？在 All in Cloud 的时代，企业的技术能力已经成为核心竞争力，他们非常愿意用云作为企业 IT 能力的增效器。 云原生计算是一组最佳实践和方法论，在公共云、专有云环境中，构建可伸缩、健壮、松耦合的应用，可以更加快速地创新和低成本试错；容器、服务网格

Does istio authorization have effect if mtls is not used for istio authentication? I was reading https://istio.io/docs/concepts/security/#authorization but I am wondering if mtls has to be enabled for istio authorization rules to have any effect/meaning. Can service A authenticate to service B without mtls and still be subject to the authorization rules? 来源： https://stackoverflow.com/questions/55071965/does-istio-authorization-have-effect-if-mtls-is-not-used-for-istio-authenticatio

上周给大家分享了一篇 必读！Istio Service Mesh中的流量管理概念解析 ，这次再给大家分享一篇Istio中重要功能和概念——授权（authorization）与鉴权（authentication）的解析。 将单体应用程序分解为微服务可提供各种好处，包括更好的灵活性、可伸缩性以及服务复用的能力。但是，微服务也有特殊的安全需求： 为了抵御中间人攻击，需要流量加密。 为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略。 要审核谁在什么时候做了什么，需要审计工具。 Istio Security 尝试提供全面的安全解决方案来解决所有这些问题。 本页概述了如何使用 Istio 的安全功能来保护您的服务，无论您在何处运行它们。特别是 Istio 安全性可以缓解针对您的数据，端点，通信和平台的内部和外部威胁。 Istio 安全概述 Istio 安全功能提供强大的身份，强大的策略，透明的 TLS 加密以及用于保护您的服务和数据的身份验证，授权和审计（AAA）工具。 Istio 安全的目标是： 默认安全 : 应用程序代码和基础结构无需更改 深度防御 : 与现有安全系统集成，提供多层防御 零信任网络 : 在不受信任的网络上构建安全解决方案 访问我们的Mutual TLS Migration docs，开始在部署的服务中使用Istio安全功能。 请访问我们的安全任务

I'm new to istio, and I want to access my app through istio ingress gateway, but I do not know why it does not work. This is my kubenetes_deploy.yaml file content: apiVersion: v1 kind: Service metadata: name: batman labels: run: batman spec: #type: NodePort ports: - port: 8000 #nodePort: 32000 targetPort: 7000 #protocol: TCP name: batman selector: run: batman #version: v1 --- apiVersion: apps/v1 kind: Deployment metadata: name: batman-v1 spec: replicas: 1 selector: matchLabels: run: batman template: metadata: labels: run: batman version: v1 spec: containers: - name: batman image: leowu/batman

11月14日-17日， 2019TOP100全球软件案例研究峰会（TOP100summit）在北京国家会议中心举办。Top100summit是科技界一年一度的案例研究峰会，每年会秉承“从用户角度出发，挑选年度最值得学习案例”的价值理念，甄选今年一年最值得研究和参考的行业100+顶级案例。京东云从超过500件案例中脱颖而出， 《非k8s环境服务网格落地——京东云内部服务网格实践》成功入围“2019年度最值得学习案例” 。 全球软件案例研究峰会（简称“壹佰案例”）是旨在发现科技界有案例教学意义的项目或方法论，如同商业领域的哈佛案例，崇尚专业的力量和案例落地实践的价值，向领先公司和早期实践者征集年度里程碑或杰出成果背后的案例故事，保证了每年发布的壹佰案例学习榜单是最有学习价值的。 京东云作为全平台云计算综合服务提供商，在产品开发时亦有诸多心得体会及成功案例。京东云拥有全球领先的云计算技术和丰富的云计算解决方案经验，在云迁移、混合元容灾、Cloud Native等领域做了非常多的技术积累和探索，而且在达达、京东到家团队中得到实际应用和验证。 在过去近两年的时间里，京东云完成了数次大型的技术产品迭代，凭借着自身的研发以及京东集团商业能力的服务输出，推出及更新多达数百款产品与服务，都具有清晰产业价值标签—— 京东云致力于成为最具产业属性的云智能厂商。 此次获奖的“服务网格

作者| 阿里云智能事业群技术专家牛秋霖（冬岛） 导读 ：从头开发一个Serverless引擎并不是一件容易的事情，今天咱们就从Knative的健康检查说起。通过健康检查这一个点来看看Serverless模式和传统的模式都有哪些不同，以及Knative针对Serverless场景都做了什么思考。 Knative Serving 模块的核心原理如下图所示，图中的 Route 可以理解成是 Istio Gateway 的角色。 当缩容到零时进来的流量就会指到 Activator 上面； 当 Pod 数不为零时流量就会指到对应的 Pod 上面，此时流量不经过 Activator； 其中 Autoscaler 模块根据请求的 Metrics 信息实时动态的扩缩容。 Knative 的 Pod 是由两个 Container 组成的：Queue-Proxy 和业务容器 user-container。架构如下： 咱们以 http1 为例进行说明：业务流量首先进入 Istio Gateway，然后会转发到 Queue-Proxy 的 8012 端口，Queue-Proxy 8012 再把请求转发到 user-container 的监听端口，至此一个业务请求的服务就算完成了。 粗略的介绍原理基本就是上面这样，现在咱们对几个细节进行深入的剖析看看其内部机制： 为什么要引入 Queue-Proxy？

I have read the docs, but seem not able to understand differences between them. Is there any overlap? I mean I would like to draw a definite boundary between them to understand their responsibilities and w.r.t their communication with the envoy proxies in the mesh. (with examples use-cases if possible) The Istio Service Mesh provides the following functionalities: Routing. For example 90% of the traffic goes to the version 1 of a microservice and the remaining 10% goes to the version 2. Or some specific requests go to the version 1 and all the others to the version 2, according to some