使用ksniff和Wireshark在Kubernetes中验证service
除了来自[]()的[Nic ]()，我最近在几次会议和网络研讨会上介绍了在现代应用程序中需要跨end-to-end或“[user to ]()”的传输级加密。从用户浏览器到应用边缘的TLS加密（和）一直是API网关、CDNS和edge 的长期，但是直到最近， mesh技术才使得TLS服务于服务流量成为我们大多数人的现实方法。
许多 mesh都承诺实现低接触TLS，允许使用人员通过一个配置选项或一个几行的YAML来启用它。但是，您如何知道集群间的通信量实际上已经被成功加密了？当然，您可以在集群中运行的Pod中启动，但这可能很难管理，特别是对于那些不太熟悉Linux工具的人。在最近一系列的 mesh调查和TLS调试之后，我偶然遇到了Eldad 的[]() 插件，这已经被证明是一个非常有用的工具，可以用来检查集群内部的流量。
现在我将分享使用的一些经验教训，并根据我最近对API网关与 mesh的第一个内部跳之间的TLS通信的调查，提供一些示例。
— 拥有的所有优点，可在中运行
根据该项目的 repo，是一个“使用和来轻松嗅探 pod的插件”。我使用和来检查网络流量已经很多年了，但是我发现在中使用它有些困难。而使用像这样的简单的插件，几乎消除了配置两个流量监听工具的所有手动工作。
您可以使用插件包管理器krew安装：
$ kubectl krew install sniff
现在，您已经安装了工具，让我们进行演示。
您还需要在本地计算机上安装。我通常通过网站下载完成此操作，但是您也可以通过apt和brew等大多数软件包管理器找到。
我以前曾手动安装了（因为我想使用krew软件包中当时不提供的功能），这很容易做到，并且也有据可查。
未加密的 edge-to- 流量
我已经通过Helm 将 API网关和的 mesh部署到GKE托管的集群中。由于和之间的集成，我可以向通过（正在管理GCP负载均衡器）公开的API端点发出请求，并可以进行动态路由此请求，通过TLS连接将其从网关路由到任何内部服务。我还可以使用作为的一个简单的服务发现机制，它允许动态路由流量，但不使用传输加密。我们先这样做，这样就可以通过看到未加密的通信量。
我已经安装了，和“quote of the (QOTM)（QOTM）”服务，如/mesh集成文档前半部分所述。在集群中，我看到以下服务正在运行：
我可以向通过/qotm-/端点公开的QOTM应用程序发出外部请求，该请求通过和进行路由
$ curl -v 34.67.222.12/qotm-consul/
* Trying 34.67.222.12...
* TCP_NODELAY set
* Connected to 34.67.222.12 (34.67.222.12) port 80 (#0)
> GET /qotm-consul/ HTTP/1.1
> Host: 34.67.222.12
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: application/json
< content-length: 174
< server: envoy
< date: Mon, 05 Aug 2019 08:30:18 GMT
< x-envoy-upstream-service-time: 1
<
{"hostname":"qotm-7fcb555cdf-xb27c","ok":true,"quote":"Nihilism gambles with lives, happiness, and even destiny itself!","time":"2019-08-05T08:30:18.802450","version":"1.7"}
* Connection #0 to host 34.67.222.12 left intact
我们再发出一个请求，但通过查看内部集群间网络流量。首先，我需要获取QOTM服务的Pod的名称，因为这是我要附加的地方
有了这个请求，一切看起来都很好。
现在，我可以通过本地计算机通过简单的命令将附加到此Pod：
您可以在CLI输出中看到所有配置，如果一切顺利，应该启动，它将显示以下窗口：
一开始， UI可能看起来有些令人生畏，但实际上并不太复杂。顶部的菜单栏允许您启动和停止网络流量捕获，还可以搜索和导航捕获的流量数据。菜单栏下方还有一个显示过滤器。顶部的窗口显示了来往Pod网络接口的流量数据包，中间的窗口提供了流量的概述（例如协议详细信息和标头元数据），底部的窗口显示了流量数据包的内容。
您只需在过滤器框中（菜单栏下方）键入“ http”并点击回车键，即可将显示过滤器仅显示HTTP流量。现在，如果您通过网关发出请求，则应该看到Pod处理该请求并生成响应：
$ curl 34.67.222.12/qotm-consul/
{“hostname”:”qotm-7fcb555cdf-xb27c”,”ok”:true,”quote”:”Nihilism gambles with lives, happiness, and even destiny itself!”,”time”:”2019–08–05T08:40:28.469624",”version”:”1.7"}
您可以忽略大量的GET/ HTTP请求，因为这些请求是通过节点的生成的，在部署了这个Pod后，这是部署成功就绪后检查的结果。
有趣的是GET/HTTP请求，它由红色框突出显示。您可以看到入站HTTP请求来自10.60.2.2，这将产生一个由QOTM服务的服务器（通过第一个红色箭头显示）生成的200 HTTP状态代码的响应，HTTP负载（通过第二个红色箭头显示）与向集群发出curl请求时查看的结果相同。
如果查看所有10.60.2.2Pod 的配置，可以看到群集中的流量源IP 属于 Pod，而目的地则10.60.1.6属于QOTM Pod。这似乎是合理的，因为我向外部请求通过服务查找路由到Pod IP。
在这一点上，我鼓励您向集群提出更多请求，也许还可以部署自己的服务，并继续探索在集群周围流动的请求。
现在让我们启用和服务mesh mTLS集成，它将对来自边缘和-to-的所有流量进行加密，并查看使用此配置生成的流量。
达到加密的edge-to-流量的峰值
为简单起见，我建议您终止与QOTM Pod的当前连接，并从集群中删除当前的QOTM服务和映射。
之后，您可以返回到和集成文档中的“加密”部分，并安装第二版QOTM服务，该服务使用 和Envoy 来管理往返于Pod（以及如果您继续关注，请不要忘记应用--.yaml，否则将无法正常运行演示。）
一切正常运行之后，您应该能够通过新端点向服务的此修改版本发出请求 /qotm--tls/
现在，将附加到新的QOTM pod。如果您在Pods处进行检查，您会注意到此版本的QOTM有两个容器，一个用于QOTM服务，一个用于管理的Envoy ：
您可以 pod以获取容器名称，这还将显示许多有关如何使用init容器引导Envoy 的有趣信息：
下面突出显示了Envoy init容器中有趣的细节，它显示了在启动时生成并加载到中的Envoy配置。您可以看到正在侦听端口5000的QOTM服务的详细信息，还可以看到Envoy 将侦听Pod网络接口上的端口20000。记下这一点，因为稍后将在博客文章中使用此信息。
...cat </consul/connect-inject/service.hclservices {id = "${POD_NAME}-qotm-sidecar-proxy"name = "qotm-sidecar-proxy"kind = "connect-proxy"address = "${POD_IP}"port = 20000proxy {destination_service_name = "qotm"destination_service_id = "qotm"local_service_address = "127.0.0.1"local_service_port = 5000}
... 如果您此时不想使用完整的命令，则还可以使用一些 magic从标记为Pod的“ qotm-mtls”中获取容器名称：
$ kubectl get pods -l app=qotm-mtls -o jsonpath={.items[].spec.containers[*].name}
qotm consul-connect-envoy-sidecar我现在将附加到我的QOTM pod和Envoy 容器上：
将附加到具有多个容器的Pod时，需要指定要附加到哪个容器。由于一个Pod中的所有容器共享一个网络名称空间，容器的选择通常取决于您可以成功附加到哪个容器，例如哪个容器具有正确的权限，并且没有运行 base映像等（请在下面的“高级技术”部分了解更多信息）。
在这里，您可以看到注入的Envoy 被称为“ --envoy-”。
