Istio

Service Mesh（服务网格） 什么是Service Mesh（服务网格）Service mesh 又译作 “服务网格”，作为服务间通信的基础设施层。Buoyant 公司的 CEO Willian Morgan 在他的这篇文章 WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE? 中解释了什么是 Service Mesh，为什么云原生应用需要 Service Mesh。 如 Willian Morgan 所言：A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside

我们正按照计划进行停机维护。服务随时可能中断。 * 我们在现场发现部分光模块损坏，已经要求供应商重新发货，由于疫情和物流影响，可能无法按时到货，预计恢复时间顺延2天。 以下是详细内容，随时将会更新。时间为 GMT+8 2020/04/21 [15:25:17] 搬迁前设备盘点 2020/04/21 [19:34:18] 目的机房柴电设备检查，UPS放电测试 2020/04/21 [20:49:44] 目的机房机柜AOC线缆检查 2020/04/22 [01:39:11] 磁盘完整性检查 2020/04/22 [08:26:21] 下架 2020/04/22 [12:00:12] 北京机房正在装车 2020/04/22 [12:49:33] 大禹平台资产录入 2020/04/22 [13:54:14] 设备正在运输，目的地 昌平数据中心 2020/04/22 [16:31:18] 设备已到达 昌平数据中心 2020/04/22 [21:30:24] 设备已通电，正在配置网络 2020/04/23 [00:34:38] 正在解决内网DNS故障和路由的问题 2020/04/23 [02:28:03] 准备PXE和iDrac 2020/04/23 [19:28:56] istio准备完毕，准备服务 2020/04/23 [19:35:13] Job #523694723 triggered

我们正按照计划进行停机维护。服务随时可能中断。 * 我们在现场发现部分光模块损坏，已经要求供应商重新发货，由于疫情和物流影响，可能无法按时到货，预计恢复时间顺延2天。 以下是详细内容，随时将会更新。时间为 GMT+8 2020/04/21 [15:25:17] 搬迁前设备盘点 2020/04/21 [19:34:18] 目的机房柴电设备检查，UPS放电测试 2020/04/21 [20:49:44] 目的机房机柜AOC线缆检查 2020/04/22 [01:39:11] 磁盘完整性检查 2020/04/22 [08:26:21] 下架 2020/04/22 [12:00:12] 北京机房正在装车 2020/04/22 [12:49:33] 大禹平台资产录入 2020/04/22 [13:54:14] 设备正在运输，目的地 昌平数据中心 2020/04/22 [16:31:18] 设备已到达 昌平数据中心 2020/04/22 [21:30:24] 设备已通电，正在配置网络 2020/04/23 [00:34:38] 正在解决内网DNS故障和路由的问题 2020/04/23 [02:28:03] 准备PXE和iDrac 2020/04/23 [19:28:56] istio准备完毕，准备服务 2020/04/23 [19:35:13] Job #523694723 triggered

系列文章: 总目录索引： 九析带你轻松完爆 istio 服务网格系列教程 目录 1 前言 2 邀约 3 正文 1 前言 如果你对博客有任何疑问，请告诉我。 2 邀约 你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料： 3 正文 一切都是那么明亮，光线照在身上，暖暖的。 仰起头，依稀能听到风声。庭院里早春的鸟儿在围墙上啁啾，三五个下人在打扫着庭院，丫鬟婆子们在天井嗑着瓜子闲聊天，嬉笑声惊动了房脊上的信鸽，扑棱棱扇动双翅滑向远处湛蓝的天空…… 我是刘全，和府的总管。外表虽然光鲜，实质却仍是一个仆人。我清楚知道自己的身份，每天小心谨慎、兢兢业业、如履薄冰般尽忠职守，日复一日、年复一年。 很多人背后指责我狐假虎威、狗仗人势，我不解释也不能解释。我明白很多脏活必须我来做，很多坏人必须我来当。我必须做到多面，这是我的工作，更是我的天职。我知道太多讳莫如深、彼此心知肚明、但又不能点破说破的潜规则，我只能自己默默消化。我不被人理解，我习惯了。很多时候我都必须像鹰一般敏锐注视整个府邸的动态，并时时保持警惕，我不能有一丝疏漏，我不能让大人为难。 一切波澜不惊之下往往隐藏着狂流暗涌。 庞大帝国的中枢体系并不在黄墙之内，而是尽在府邸之中。1300 万平方公里疆域的数据全部汇集于此，并在此处做流转、做分发。咫尺便是天涯、天涯又近在咫尺。 每天这里都在上演国泰民安、妻离子散；朔漠狼烟、塞外江南……

As a full stack Developer, if you have been spending a lot of time in developing apps recently, you already understand a whole new set of challenges related to Microservice architecture. Although there has been a shift from bloated monolithic apps to compact, focused Microservices for faster implementation and improved resiliency but the fact is developers have to really worry about the challenges in integrating these services in distributed systems which includes accountability for service discovery, load balancing, registration, fault tolerance, monitoring, routing, compliance, and security.

最近闲下来，打算把Knative的核心组件Serving给学习下，会继续采用k8s源码学习的方式，管中窥豹以小击大，学习serving的主要目标: 可观测性基础设施、自动伸缩、流量管理等核心组件的设计与实现，今天先简单臆测下，感兴趣的同学， 一起来学习吧 1. 基于云原生的单体应用构建 大多数公司的服务可能都已经经过单体、SOA演进到了当下流行的微服务架构，微服务给我们带来了独立演进、扩容、协作、数据自治等便利的背景下，也带来了诸如稳定性保障、维护、服务治理等实际的问题，我们今天来一起来回归单体，比如我们要新开一个业务，新上一个小的模块这个场景，在云原生的场景下，是如何玩的 1.1 云原生下的单体应用 云原生有很多大佬有很多的解释，我就简单理解成是基于云构建而来，可以使用云上所有已知的现有的服务，同时享受云所带来的弹性、按需付费、高可用等方面的原生能力 一个基础的单体应用通常会依赖如下几部分：持久化数据存储、高性能缓存、全文索引、消息队列等常见组件， 各家云厂商大多数会包含这些基础的服务，我们只需要引入对应的类库完成我们的应用逻辑即可, 然后程序就完成代码的coding后,下一步就是交付了 1.2 基于k8s的云原生交付 基于k8s的云原生已经成为一个事实上的标准，将代码和应用的数据打包成docker镜像，基于Pod的交付模式，让我们并不需要关注我们是使用IDC里面的实体机

1.和社区版Istio的区别 OpenShift 4.2的Service Mesh和upstream的Istio项目的增强，除了产品化之外，借用官方文档，区别在于： Red Hat OpenShift Service Mesh differs from Istio in ways that help resolve issues, provide additional features, and ease deployment on OpenShift Container Platform. An installation of Red Hat OpenShift Service Mesh differs from upstream Istio community installations in multiple ways: OpenShift Service Mesh installs a multi-tenant control plane by default OpenShift Service Mesh extends Role Based Access Control (RBAC) features OpenShift Service Mesh replaces BoringSSL with OpenSSL Kiali and Jaeger are enabled by

系列文章: 总目录索引： 九析带你轻松完爆 istio 服务网格系列教程 目录 1 前言 2 邀约 3 NodePort 样例 4 访问流程 5 实例演示 6 缺点 1 前言 如果你对博客有任何疑问，请告诉我。 2 邀约 你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料： 3 NodePort 样例 跟 hostNetwork 和 hostPort 不同，NodePort 属于 service 类型之一。hostPort 和 hostNetwork 作用对象是 Pod，而 NodePort 作用对象则是 service。 pod 文件如下所示： service 文件如下： 创建 NodePort 服务时，用户可以在 30000 ~ 32767 范围内指定一个端口，也可以通过 patch 打补丁的方式修改 service 类型，这样 NodePort 端口将会在范围 30000 ~ 32767 之间自动分配。 kubectl patch svc svc_name -n ns_name -p '{"type": "NodePort"}' 4 访问流程 下图展示当 k8s svc 创建之后，k8s 集群内部都发生了哪些变化。 当 client 发送 kubectl apply 指令给 APIServer 后，会生成相关的 service 对象，k8s 集群内的所有节点

系列文章: 总目录索引： 九析带你轻松完爆 istio 服务网格系列教程 目录 1 前言 2 邀约 3 hostPort 样例 4 hostPort 与 hostNetwork 异同 4.1 相同点 4.2 不同点 5 hostPort 使用场景 6 注意 1 前言 如果你对博客有任何疑问，请告诉我。 2 邀约 你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料： 3 hostPort 样例 样例代码如下所示： pod 发布之后，便会将容器端口开放给了外部网络。外部可以通过 pod 所在宿主机和 hostPort 值访问到 Pod 内的容器提供的服务。 4 hostPort 与 hostNetwork 异同 4.1 相同点 hostPort 与 hostNetwork 本质上都是暴露 pod 宿主机 IP 给终端用户，因为 pod 生命周期并不固定，随时都有可能被完爆，故 IP 的不确定最终导致用户使用上的不方便；此外宿主机端口占用也导致不能在同一台机子上有多个程序使用同一端口。因此一般情况下，不要使用 hostPort 方式。 4.2 不同点 使用 hostNetwork，pod 实际上用的是 pod 宿主机的网络地址空间：即 pod IP 是宿主机 IP，而非 cni 分配的 pod IP，端口是宿主机网络监听接口。 使用 hostPort，pod IP 并非宿主机

总目录索引： istio从入门到放弃系列 1、jaeger 介绍 jaeger 官网： https://www.jaegertracing.io/ jaeger 是 Uber 开源的分布式跟踪系统，用于微服务的监控和全链路跟踪，其设计思想来自于 Dapper 和 zipkin。jaeger 特征包括： 分布式上下文传播 分布式事务监控 Root 原因分析 服务依赖性分析 性能/延迟优化 2、jaeger 安装 如果你使用 istioctl profile demo 安装 istio 的话，jaeger 默认就是安装好的 为了可以将 jaeger 暴露在 k8s 集群外访问，需要将 jaeger-query 的 ClusterIP 服务类型更改为 NodePort。执行语句如下 kubectl patch svc -n istio-system jaeger-query -p '{"spec":{"type": "NodePort"}}' 3、kiali 关联 jaeger kiali 是可视化服务网格组件，截图如下： 点击上面箭头 Distributed Tracing 链接可以打开 jaeger。如果访问不到，说明你本地的浏览器并不能直接访问到 kiali 设置的 jaeger 外部链接。 4、设置 kiali jaeger 外部链接地址 编辑 kiali configmap：