运维调试:Istio

Istio 生成以下类型的 telemetry(遥测信息) ，以提供整体服务网格可观察性：

在 IstioOperator CR 中增加如下配置：

Requests可能由于各种原因而被拒绝。 理解为什么拒绝请求的最佳方法是检查 Envoy的访问日志 。 默认情况下，访问日志输出到容器的标准输出。 运行以下命令以查看日志：

在默认访问日志默认格式中，在返回码后面有 Envoy response flags 和 Mixer policy status 。

如果您使用的是自定义日志格式，请确保包括 %RESPONSE_FLAGS% 和 %DYNAMIC_METADATA(istio.mixer:status)%

常见的 response flags 有:

常见的 Mixer Policy status 有:

Envoy的当前版本实现中，可能需要多达100个请求才能遵守按权重分发流量

如果路由规则对于Bookinfo示例而言运行良好,但是类似的“版本路由规则”对您自己的应用程序没有影响，则可能需要您对您的Kubernetes服务需要稍作更改。

Kubernetes服务必须遵守某些限制，才能利用 Istio 的L7路由功能。 有关详细信息，请参阅Pod和服务要求。

另一个潜在的可能是路线规则的生效速度有些缓慢。 Kubernetes上的 Istio实现 使用 最终一致的算法 来确保所有Envoy sidecar具有一致的配置，包括所有路由规则。 配置更改将需要一些时间才能传播到所有 sidecars。 在大型部署中，传播将花费更长的时间，并且可能会有几秒钟的延迟时间。

如果在应用DestinationRule后对服务的请求立即生成 HTTP 503错误 ，并且错误一直持续到您删除或还原DestinationRule，则DestinationRule可能会导致服务的 TLS冲突 。

例如，如果你在集群全局配置了双向TLS，那么 DestinationRule必须包含如下的 trafficPolicy :

否则， mode 的默认值是 DISABLE ， 将导致客户端的 proxy sidecar 发出纯HTTP请求而不是TLS加密请求。 因为服务端的 proxy sidecar 期望加密的请求，所以客户端代理发出的请求与服务端代理期望接受的请求发生冲突。

每当您应用DestinationRule时，请确保 trafficPolicy TLS模式 与全局配置匹配。

假设您使用 ingress gateway 和相应的VirtualService访问内部服务。 例如，您的VirtualService看起来像这样：

你还有一个 VirutalService 定义将流量路由到特定的subset,如没告下所示:

在这种情况下，您会注意到，通过入口网关向helloworld服务的请求将不会定向到子集v1，而是将继续使用默认的 round-robin routing(轮询路由) 。

以 gateway host（例如myapp.com）作为入口的请求将激活 myapp VirtualService 中的规则，清橘该规则会将流量路由到helloworld服务的任意endpoint。

以 helloworld.default.svc.cluster.local 作为入口的的内部请求才会激活 helloworld VirtualService 中的规则，该规则会将流量路由到 subset v1 。

要控制以 gateway host（例如myapp.com）作为入口的请求，还需要在 myapp VirtualService 中包括子集规则：

或者将这两个 VirtualService 合并成一个：

检查 ulimit -a 。 很多系统有默认最多打开 1024个fd(file descriptor) 的限制，这会导致 Envoy 的 assert失败并crash，错误信息枯正明如下:

请确保提高了该限制，例如 ulimit -n 16384

Envoy需要upstream服务是 HTTP/1.1 或 HTTP/2 。

例如当你使用Nginx作为上游服务的web server时，你需要设置nginx的 proxy_http_version 1.1 指令，因为nginx的该指令默认值是 1.0

示例

很多traffic管理问题都是由不正确的 TLS配置 导致的。

如果你将 HTTPS请求 发送到声明为HTTP的服务，则 Envoy sidecar 将在转发请求时尝试将请求解析为HTTP，这将失败，因为HTTP意外地被加密。

例如你有如下的 ServiceEntry 定义:

当你发送 HTTPS请求，例如 curl https://httpbin.org , 你会得到一个错误如下 curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Envoy的 access log 会显示一个 400 DPE 的错误

这是因为你将 protocol 声明成了 HTTP 而不是 HTTPS

要修复这个问题，修改 ServiceEntry 定义如下:

将 virtual service 绑定到 gateway 时，可能会发生两种常见的TLS不匹配:

gateway终结了TLS而virtual service配置了TLS路由示例

假设你有如下的配置:

上面的这个配置， gateway 终结了TLS，而 virtual service 使用了基于TLS的路由规则， 这个路由规则不会生效 ，因为当路由规则被 evaluted(评估) 时，TLS已经被终结。

使用这个配置，你会得到 404状态码 。

你可以通过 istioctl proxy-config routes 命令来确认这个信息

gateway passthrough TLS ，而 virtual service 没有配置 TLS路由示例

假如你有如下的配置

上面的这个配置， gateway passthrough TLS，而 virtual service 没有使用基于TLS的路由规则， 这个路由规则不会生效

你可以通过 istioctl proxy-config listener 和 istioctl proxy-config routes 命令来确认这个信息

当配置 Istio 执行 TLS origination 时，你需要确保发送到 sidecar 的请求是纯文本的， sidecar 随后发起 TLS origination

假定你有如下的配置

使用此配置， Sidecar 希望应用程序在端口443上发送TLS流量（例如 curl https://httpbin.org ），但它还将在转发请求之前执行 TLS origination 。 这将导致请求被双重加密。

你会得到一个错误 (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

要修复这个问题，你可以将 ServiceEntry 中的 protocol 更改为 HTTP

然后用 curl http://httpbin.org:443 的方式发出请求

幸运的是从 Istio 1.8 开始，你可以向80端口发出请求，然后将请求重定向到 443以进行TLS发起, 如下所示:

使用相同的TLS证书配置多个网关 将导致利用 HTTP/2连接重用 的浏览器（即大多数浏览器） 在与一主机的建立连接之后 访问第二主机时产生 404错误 。

假定你有如下配置:

由于两个网关由相同的工作负载（即 selector = istio: ingressgateway ）提供服务，因此对两个服务（ service1.test.com 和 service2.test.com ）的请求都将解析为相同的IP。

如果首先访问 service1.test.com ，它将返回通配符证书（ *.test.com ），指示与 service2.test.com 的连接可以使用同一证书。 因此，Chrome和Firefox等浏览器将重复使用现有连接来请求对 service2.test.com 的请求。 由于 Gateway gw1 没有 service2.test.com 的路由，因此它将返回 404响应 。

要避免这个问题，你可以配置一个单独的 Gateway , 而不是两个( gw1 和 gw2 ) 。就像下面这样 :

当使用相同的 selector 配置多个 Gateway 时，如果它们都暴露了相同的 HTTPS 端口，你必须确保它们使用了不同的端口名称。否则后创建的Gateway会无效（ 虽然不会报错 ）

加入你有如下配置:

使用这个配置，发送到 myhost2.com 的请求会失败，因为两个 Gateway 使用了相同的端口名称 https ， curl 请求会产生如下的错误:

你可以通过检查 Pilot 的日志来确认发生了什么，如下所示：

要避免这个问题，可以将第二个gateway的端口名称修改（例如 https2 ）

(TODO 待补充)

https://istio.io/latest/docs/ops/common-problems/security-issues/

Istio被安装，并且所有的事情看起来都正常，除了Zipkin中没有追踪数据

这可能是由一个已知的Docker问题引起的，就是容器内部的时间可能与主机上的时间显著不同。（这个问题在 OSX *** 作系统上出现）

你可以通过在容器内部和外部执行 date 命令来确认。

要解决这个问题，你需要关闭并重启 Docker ，然后重新安装 Istio

同样可能是时间的问题

当你从本地web客户端连接到远端的Grafana时，如果你不能获取Grafana的输出，请确认本地客户端时间和服务端的时间是否相同

本地web客户端(例如 Chrome)影响Grafana的输出

Istio CNI插件 在Kubernetes Pod生命周期的网络设置阶段执行 Istio Mesh Pod流量重定向 ，从而消除了将Pod部署到Istio Mesh中的用户对 NET_ADMIN 和 NET_RAW 功能的要求。

Istio CNI插件 取代了 istio-init容器 提供的功能。

(TODO 待补充)

https://istio.io/latest/docs/ops/common-problems/injection/

(TODO 待补充)

https://istio.io/latest/docs/ops/common-problems/validation/

如果输出列表中缺少某个proxy，则表示该proxy当前未连接到Pilot实例，因此不会接收任何配置。

此外，如果proxy被标记为 stale(陈旧) ，则可能意味着存在网络问题或需要 扩充Pilot实例的数量 。

Istiod 使用灵活的 Introspection（自省）框架（称为 ControlZ ）构建，这使得它很容易检查和 *** 作 istiod 实例 的内部状态。

Istiod 打开一个web端口，可以通过浏览器使用交互视图更改其状态，或者通过REST API的方式。

当 istiod 启动时，通过它的日志信息可以看到连接到 ControlZ 的IP和端口

你可以通过在本地使用 istioctl dashboard 命令开启对 Istio组件 的访问

然后打开浏览器 http://localhost:9876

Istio组件使用灵活的日志框架构建，该日志框架提供了许多功能和控件，以帮助 *** 作这些组件并促进诊断。

启动组件时，可以通过传递 命令行选项 来控制这些日志记录功能。

1. Logging scopes

组件输出的日志消息按 scopes 分类。 scope 代表一组可以整体控制的相关日志消息。 根据组件提供的功能，不同的组件具有不同的 scopes 。 所有组件都有 default scope ，该scope用于未分类的日志消息。

例如，在撰写本文时， istioctl 具有24个 scope ，代表命令中的不同功能区域： ads, adsc, analysis, attributes, authn, authorization, cache, cli, default, grpcAdapter, installer, mcp, model, patch, processing, resource, secretfetcher, source, spiffe, tpath, translator, util, validation, validationController

Pilot-Agent，Pilot-Discovery和Istio Operator 具有它们自己的scopes，您可以通过查看它们的参考文档来发现它们。

每个scope都有一个唯一的log level 为以下之一：

none error warning info debug

none 不产生任何输出， debug 则产生最多的输出

所有scopes的默认level是 info

要控制输出的level，可以使用 --log_output_level 命令行选项，如下所示：

2. 控制输出位置

日志消息通常发送到组件的标准输出流。 使用 --log_target 选项，您可以将输出定向到任意数量的不同位置。 您可以为该选项提供一个用逗号分隔的文件系统路径列表，以及特殊值 stdout和stderr ，分别表示标准输出和标准错误流。

日志消息通常以人类友好的格式输出。 --log_as_json 选项可用于将输出强制转换为JSON，这样工具可以更轻松地进行处理。

3. Log rotation

Istio控制平面组件 可以自动管理 Log rotation ，这使将大型日志分解为较小的日志文件变得很简单。 使用 --log_rotate 选项，您可以指定用于rotation的基本文件名。 派生名称将用于单个日志文件。

使用 --log_rotate_max_age 选项可以指定文件rotation之前的最大天数，而使用 --log_rotate_max_size 选项可以指定文件rotation之前的最大大小（以megabytes为单位）。 最后， --log_rotate_max_backups 选项使您可以控制要保留的最大rotation文件数，较旧的文件将被自动删除。

3. 组件调试

使用 --log_caller 和 --log_stacktrace_level 选项，您可以控制日志信息是否包括 programmer-level 的信息。 当试图跟踪组件中的bug时，这很有用，但通常在日常 *** 作中不使用。

该命令被 pilot 使用， pilot 是 istiod 的一部分，所以你可以在 istiod pod内执行该命令

该命令被 istio-operator namespace中的 istio-operator deployment 使用，所以你可以在 istio-operator pod内执行该命令

该命令被注入的pod中的 istio-proxy container 使用，所以你可以在任意被注入的pod的 istio-proxy container 内执行该命令

每年的CES，消费电子品们最大的忧伤在于总是担心被汽车/出行企业各种花式抢走风头，囿于产品的展示方式，手机电视游戏机在CES的展场内尚可以与静态展示的汽车别别苗头，但是在拉斯维加斯的街头，就是各种汽车品牌和Tire1供应商的天下了。

好不容易等到今年拉斯维加斯的街头不再有各种自动驾驶的车队炫技，唯一能够成为一道风景的只有全新定制的BMW i3 Urban Suite。但是，Sony、Samsung和Panasonic想不到的是，这次，地面干净了，他们却迎来了一个“天敌”——最炫的，在天上。

固特异的飞艇天下闻名，而这一次，是固特异第一次将飞艇带到了CES的现场供众多媒体和合作伙伴体验，毕竟飞跃赌城的体验难得可贵，而固特异的飞艇又绝非普通的直升机可比。

其实飞行员Taylor Deen的行程介绍只是一个序曲，来自固特异位于旧金山的创新实验室的Jose Diaz的简短发言才是固特异此次CES之行的重点所在。就在美国西部时间1月7日的晚上，固特异由全球董事长、首席执行官兼总裁Richard J. Kramer发布了两项重磅消息：

Goodyear Ventures基金

固特异在出行领域的探索和实践正在以更多样的方式向更丰富的维度拓展，用科技推动出行是固特异从始至终坚持的原则。除了不断推动自身的技术发展，固特异寻求与其他行业优秀企业的合作也从未停止过，其中既包括拥有成熟商业模式的公司，也包括一些小而美的初创企业。因此，Richard J. Kramer宣布固特异出资一亿美元，设立Goodyear Ventures全新创业投资基金，该创投基金计划主要面向出行领域的各种企业，旨在推动孵化更多面向未来的出行解决方案。

Goodyear Ventures将专注于以下八个消族主题领域：

?????电气化和自动驾驶技术

?????智能网联出行方案

?????新一代公共出行

?????新一代航空出行

?????未来交通基础设施

?????未来出行工具的维护和运营

?????新兴技术

?????新型轮胎材料

事实上，仅仅一亿美金，要在以上八个领域开花结果显得有些难度，但是除了能够提供资金支持外，Goodyear Ventures还能为所投资的公司提供固特异丰富的技术和创新资源、强大的车辆服务网络以及遍布全球各地的生产制造和产品研发设施来丰富技术经验储备、提升自身实力，而这一切才是任何一家公司在出行领域想要有所作为所需要的重要筹码——毕竟在出行领域，两眼一抹黑的楞烧钱已经被证明了是一种无法治愈的残缺。

AndGo车队服务平台

当晚，Richard J. Kramer还发布了整合预测性软件和可靠的全国性服务网络的AndGo车队服务平台，确保乘用车车队能够享受更为高效便捷的服务体验。除轮胎服务外，AndGo平台还提供整车相关服务，从而帮助乘用车车队提升运营表现。通过监测服务需求以及快捷简便的服务安排流程，AndGo平台可以利用固特异庞大的服务网络来为车队提供更有保障的服务，有助于车队延长正常运营时间。

正如Richard J. Kramer表示的，AndGo平台有助于推动当今及未来出行领域的发展。凭借强大的服务网络、智能轮胎解决方案以及预测性软件，固特异可以帮助车队更高效地进行商务运营。

事实上，和出行领域所有的技术成果一样，AndGo的发布和运营并非无迹可寻的横空出世。

2019年3月21日，固特异宣布与Envoy Technologies开启新的合作计划。Envoy Technologies是一家基于社区的按需共享电动汽车的服务提供商，而固特异官方对这项合作的目标描述是“聚焦于以数据收集及分析为共享出行赋能”。

固特异为车队提供的独特的预测性轮胎维修解决方案可用于预测并自动安排所需的轮胎维护和更换计划。Envoy的车队经理可以查看其车队的状态，安排维护需求并通过拿带弊固特异的按需计划程序来更新维修的预约时间，从而保持其车队的正常运转并避免一些无法预料的问题发生。。

为此，固特异会从行粗Envoy的联网车辆中收集安全的匿名数据，并将其用于预测和计划服务需求。然后，固特异在利用其网点和移动货车网络为车队提供服务。移动货车可以在其充电站现场安装轮胎，从而使Envoy的工作人员所花费的时间最短。

固特异首席技术官Chris Helsel表示：“随着按需汽车共享和乘车服务的增长，固特异将其车队服务业务模式扩展到共享出行服务提供商，以改善城市车队的运营。”而Envoy的联合创始人Aric Ohana则表示，随着Envoy的业务在全国范围内继续扩张，固特异所能提供的服务网络支持将变得至关重要。

同样，2019年5月30日，固特异开始了与位于加利福尼亚州西好莱坞的短期全电动汽车订阅服务公司Borrow的全新合作。

固特异可以使用其独特的预测性轮胎维修解决方案为车队预测并自动计划所需的轮胎维护和更换计划，利用固特异在轮胎方面的专业知识、基于云平台可以通过车辆数据和专有算法预测并自动安排轮胎维修时间表。而通过这项合作，固特异位于旧金山的创新实验室将在为车队提供服务的同时测试全新的技术解决方案。

固特异对于未来出行的关注点将会重点放在车队服务和电动汽车上，而与Borrow的这种合作关系延续了固特异对车队的数字化服务解决方案的测试，从而使固特异在这一领域继续处于领先地位。

固特异的关注点首先是为车队的轮胎提供基础服务，同时可以提供其他延伸性服务以最大程度地提高Borrow的正常运行时间和客户体验。目前，这些服务均由固特异的移动货车提供，但随着双方合作的深入以及合作规模的扩大，固特异会逐渐让自己的经销商网络和固特异拥有的一些零售店加入到整个服务网络之中，从而进一步提高服务效率和用户体验。

我们突然转向Envoy和Borrow并非没有原因，事实上，如果现在到AndGo的主页https://www.andgonow.com/进行注册，在你收到的邮件中，固特异提供了专门的两个链接，指向了之前与Envoy和Borrow的合作介绍——显而易见的是，这两个合作项目，正是今天AndGo计划的前身和基础。

对于固特异而言，身为行业的头部企业之一，对未来出行行业的理解和参与，早已不仅仅再限于单一的产品和技术提升，不管是Goodyear Ventures基金的设立还是AndGo平台的发布，都表现出固特异以更高阶和深入的方式切入出行行业的决心，而其丰富的产品储备、领先的软硬件相结合的数字化解决方案以及庞大的服务网络，将会为固特异今后在出行行业充任更重要的角色提供具有差异化的筹码。

本文来源于汽车之家车家号作者，不代表汽车之家的观点立场。

Sealos 是一个 Go 语言开发的简单干净且轻量的 Kubernetes 集群部署工具， Sealos 能很好的支持在生产环境中部署高可用的 Kubernetes 集群。

无论是通过 KeepAlived 还是 HAProxy 进行高可用集群调度都会存在以下一些劣势。

Sealos 高可用实现是通过本地负载方式完成的。本地负载实现方式有多种，比如： IPVS 、 Envoy 、 Nginx 等，而 Sealos 采用的是通过内核 IPVS 来实现的。

本地负载：在每个 Node 节点上都启动一个负载均衡，同时监听集群中的多个 Master 节点。

Sealos 选择通过内核 IPVS 来实此念慎现主要有以下几个原因：

1）如果使用 Envoy 等需要在每个节点上都跑一个进程，消耗更多资源。虽然森敬 IPVS 实际上也会多跑一个 lvscare 进程 ，但是 lvscare 只是负责管理 IPVS 规则，原理和 Kube-Proxy 类似。真正的流量直接从内核层面走，不需要把数据包先走到用户态中去处理。

2）使用 Envoy 存在启动优先级的问题，比如：Join 集群时，如果负载均衡没有建立，Kubelet 就会启动失败。使用 IPVS 则不会存在这样的问题，因为我们可以在 Join 集群前先建立好转发规则。

1）解决默认证书有效期只有一年的问题。

2）更方便的实现本地负载。

3）核心的功能均集成到 Kubeadm 中了，Sealos 只管分发和执高培行上层命令，相对就更轻量了。

离线包包含所有二进制文件配置文件和镜像

服务器用户名：root，服务器密码：123456

升级系统内核

修改Cgroup Driver

设置hostname

多master

kubectl命令自动补全

sealos默认已经帮我们安装命令补全功能。

---