kiali通过大使发送显示未知流量

Question

我已经安装了服务网格(Istio)，并与大使一起将流量路由到我们的应用程序。每当我通过Istio Ingress发送流量时，它工作得很好，并与大使合作，但通过大使发送时，它显示未知，你可以在附件图像上看到，可能与大使不使用Istio侧车的事实有关。

​

​

使用代码部署大使服务：

apiVersion: v1
kind: Service
metadata:
  name: ambassador
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: ambassador-http
      port: 80
      targetPort: 8080
  selector:
    service: ambassador
---

有没有什么我可以在这里添加的东西来使它成为可能？

谢谢

Answer 1

是的，这是可能的，这里有来自Abmassador documentation的详细指南。

让大使与Istio合作

让大使与Istio合作很简单。在本例中，我们将使用来自Istio的bookinfo示例应用程序。

1. 在Kubernetes上安装Istio，遵循the default instructions (不在Bookinfo之间使用相互TLS身份验证)安装Bookinfo示例应用程序，遵循确保该示例应用程序按预期工作的instructions.
2. Verify。

默认情况下，Bookinfo应用程序使用Istio入口。要使用大使，我们需要：

1. 安装大使。

首先，您需要将大使大使管理服务部署到您的集群：

使用我们在线提供的YAML文件是最简单的(当然，如果您愿意，也可以将它们下载并在本地使用！)。

首先，您需要检查Kubernetes是否启用了RBAC：

kubectl cluster-info dump --namespace kube-system | grep authorization-mode

如果您在输出中看到类似于--authorization-mode=Node,RBAC的内容，则表示启用了RBAC。

如果启用了RBAC，则需要使用：

kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-rbac.yaml

没有RBAC，您可以使用：

kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-no-rbac.yaml

(请注意，如果您计划将来在大使和Istio/服务之间使用相互TLS进行通信，则可能需要交换下面部署大使管理服务和大使LoadBalancer服务的顺序)

接下来，您将部署一个大使服务，该服务充当通过LoadBalancer类型进入集群的入口点。创建以下YAML并将其放入名为ambassador-service.yaml的文件中。

---
apiVersion: getambassador.io/v1
kind: Mapping
metadata: 
  name: httpbin
spec:     
  prefix: /httpbin/
  service: httpbin.org
  host_rewrite: httpbin.org

然后，使用kubectl将其应用于Kubernetes

kubectl apply -f ambassador-service.yaml

上面的YAML做了几件事：

• 它为LoadBalancer类型的大使创建了一个Kubernetes服务。请注意，如果您不是在支持LoadBalancer类型(即MiniKube)的环境中部署，则需要将其更改为不同类型的服务，例如，NodePort.
• It创建了一个测试路由，该测试路由将从/httpbin/到公共httpbin.org HTTP请求和响应服务(它提供了可用于诊断目的的有用端点)的流量。在大使中，Kubernetes注释(如上所示)用于配置。更常见的情况是，您需要在服务部署过程中配置路由，如this more advanced example.

中所示

您可以通过执行以下命令来查看两个大使服务是否正常运行(并在几分钟后分配LoadBalancer IP地址时获取该地址)：

$ kubectl get services
NAME               TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)          AGE
ambassador         LoadBalancer   10.63.247.1     35.224.41.XX     8080:32171/TCP     11m
ambassador-admin   NodePort       10.63.250.17    <none>           8877:32107/TCP   12m
details            ClusterIP      10.63.241.224   <none>           9080/TCP         16m
kubernetes         ClusterIP      10.63.240.1     <none>           443/TCP          24m
productpage        ClusterIP      10.63.248.184   <none>           9080/TCP         16m
ratings            ClusterIP      10.63.255.72    <none>           9080/TCP         16m
reviews            ClusterIP      10.63.252.192   <none>           9080/TCP         16m

$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
ambassador-2680035017-092rk      2/2       Running   0          13m
ambassador-2680035017-9mr97      2/2       Running   0          13m
ambassador-2680035017-thcpr      2/2       Running   0          13m
details-v1-3842766915-3bjwx      2/2       Running   0          17m
productpage-v1-449428215-dwf44   2/2       Running   0          16m
ratings-v1-555398331-80zts       2/2       Running   0          17m
reviews-v1-217127373-s3d91       2/2       Running   0          17m
reviews-v2-2104781143-2nxqf      2/2       Running   0          16m
reviews-v3-3240307257-xl1l6      2/2       Running   0          16m

上面我们看到分配给LoadBalancer的外部IP是35.224.41.XX (XX用于掩码实际值)，并且所有大使pod都在运行(大使依赖Kubernetes提供高可用性，因此应该有两个小pod在集群内的每个节点上运行)。

您可以使用指向httpbin.org的测试路由获取发出请求的外部集群Origin IP，从而测试cluster是否已正确安装：

$ curl 35.224.41.XX/httpbin/ip
{
  "origin": "35.192.109.XX"
}

如果您看到类似的响应，那么一切都很好！

(额外的好处:如果您想使用一点awk的魔力将LoadBalancer IP导出到一个变量AMBASSADOR_IP，那么您可以输入export AMBASSADOR_IP=$(kubectl get services ambassador | tail -1 | awk '{ print $4 }')并使用curl $AMBASSADOR_IP/httpbin/ip

1. 现在您将修改bookinfo演示bookinfo.yaml清单，以包含必要的大使注释。见下文。

---
apiVersion: getambassador.io/v1
kind: Mapping
metadata: 
  name: productpage
spec:     
  prefix: /productpage/
  rewrite: /productpage
  service: productpage:9080
---
apiVersion: v1
kind: Service
metadata:
  name: productpage
  labels:
    app: productpage
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: productpage

上面的注释实现了一个从'/ productpage /‘URI到运行在端口9080 ('productpage:9080')上的Kubernetes productpage服务的大使映射。'prefix‘映射URI取自您的大使服务的根目录的上下文，该服务充当入口点(通过端口80向外部公开，因为它是一个产品页面)，例如’35.224.41.XX/LoadBalancer/‘。

现在，您可以从本地文件系统上的Istio GitHub存储库的根目录应用此清单(注意使用istioctl kube-inject包装应用)：

kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml)

通过键入kubectl delete ingress gateway.

• Test

1. 从bookinfo.yaml清单中删除入口控制器，方法是转到您在上面配置的大使LoadBalancer的IP，例如35.192.109.XX/productpage/。您可以通过键入kubectl get services ambassador.

再次查看大使的实际IP地址

此外，根据documentation的说法，不需要注射大使豆荚。

Answer 2

是的，我已经配置了所有这些东西。这就是为什么我在附图中提到它的原因。这是我从kiali仪表板上拿来的。我分享的bookinfo应用程序的输出。我已经部署了我自己的应用程序，它也工作得很好。但是我想简写这个未知的的东西。我正在使用AWS EKS集群。

关于大使的说明：大使不应该有Istio侧车，原因有两个。首先，它不能，因为运行两个单独的特使实例将导致它们共享内存段的冲突。第二，大使无论如何都不应该出现在你的网络中。网格对于处理从一个服务到另一个服务的流量路由是很好的，但由于大使是您的入口点，它应该单独负责决定路由到哪个服务以及如何路由。让大使和Istio都尝试设置路由规则将是一个令人头疼的问题，而且没有多大意义。

Answer 3

来自不属于服务网格一部分的源的所有流量都将显示为unknown。

看看kiali对未知的看法：https://kiali.io/faq/graph/#many-unknown