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

是的，有可能，这里是documentation大使馆的详细指南：

让大使与Istio合作

让大使与Istio合作非常简单。在此示例中，我们将使用Istio的bookinfo示例应用程序。

遵循the default instructions（在侧车之间不使用双向TLS身份验证）在Kubernetes上安装Istio
接下来，按照instructions安装Bookinfo示例应用程序。
验证示例应用程序是否按预期运行。

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

安装大使。

首先，您需要将Ambassador ambassador-admin服务部署到您的集群：

为此，最简单的方法是使用我们在线提供的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

（请注意，如果您打算将来使用双向TLS进行大使和Istio /服务之间的通信，则可能需要交换下面部署大使管理服务和大使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。
它将创建一条测试路由，该路由会将流量从/httpbin/路由到公共httpbin.org HTTP请求和响应服务（该服务提供了可用于诊断目的的有用端点）。在大使中，Kubernetes批注（如上所示）用于配置。更常见的是，您将希望在服务部署过程中配置路由，如this more advanced example所示。

通过执行以下命令，可以查看两个Ambassador服务是否运行正常（并在几分钟后获得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掩盖了实际值），并且所有大使吊舱都在运行（大使吊舱依靠Kubernetes来提供高可用性，因此应该是集群中每个节点上运行的两个小容器。

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

$ 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

现在，您将修改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产品页面服务的大使映射。 ``前缀''映射URI取自充当入口点的Ambassador服务根目录的上下文（因为它是LoadBalancer，因此通过端口80在外部公开），例如'35 .224.41.XX / productpage/'。

您现在可以从本地文件系统上的Istio GitHub存储库的根目录应用此清单（请小心使用istioctl kube-inject包装应用）：

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

（可选）通过键入bookinfo.yaml从kubectl delete ingress gateway清单中删除Ingress控制器。
测试大使。 35.192.109.XX/productpage/。您可以通过输入kubectl get services ambassador再次查看大使的实际IP地址。

根据documentation，也不需要注入大使吊舱。

Answer 2

是的，我已经配置了所有这些东西。这就是为什么我在所附的图片中提到了它。我是从kiali仪表盘上获取的。我已经分享了bookinfo应用程序的输出。我已经部署了自己的应用程序，并且运行正常。但是我想把这件事未知。我正在使用AWS EKS集群。

发表关于大使的说明： 出于两个原因，大使不应该拥有Istio挎包。首先，它不能运行，因为运行两个单独的Envoy实例将导致它们的共享内存段发生冲突。第二个问题是大使无论如何都不应该进入您的网格。网格非常适合处理从服务到服务的流量路由，但是由于大使是您的入口点，因此它应该完全负责确定路由到哪个服务以及如何进行路由。让大使和Istio都尝试设置路由规则将是一件令人头疼的事，并且没有多大意义。

Answer 3

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

看看kiali对未知事物的评价： https://kiali.io/faq/graph/#many-unknown

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

3 个答案:

让大使与Istio合作