1

我已经安装了服务网格（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
---

有什么我可以在这里添加的吗？

谢谢

4

3 回答 3

1

是的，这是可能的，这里是 Abmassador文档中的详细指南：

让大使与 Istio 合作

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

  1. 按照默认说明在 Kubernetes 上安装 Istio （不使用边车之间的双向 TLS 身份验证）
  2. 接下来，按照 说明安装 Bookinfo 示例应用程序。
  3. 验证示例应用程序是否按预期工作。

默认情况下，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

（请注意，如果您计划将来使用双向 TLS 进行 Ambassador 和 Istio/services 之间的通信，那么您在下面部署ambassador-admin 服务和大使 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

然后，将其应用到 Kubernetes kubectl：

kubectl apply -f ambassador-service.yaml

上面的 YAML 做了几件事：

  • 它为 Ambassador 创建了一个 Kubernetes 服务，类型为 LoadBalancer. 请注意，如果您未在 LoadBalancer 受支持类型（即 MiniKube）的环境中进行部署，则需要将其更改为不同类型的服务，例如 NodePort.
  • 它创建一个测试路由，将流量从 /httpbin/ 公共 httpbin.org HTTP 请求和响应服务（它提供可用于诊断目的的有用端点）路由。在 Ambassador 中，Kubernetes 注释（如上所示）用于配置。更常见的是，您需要将路由配置为服务部署过程的一部分，如 这个更高级的示例所示。

您可以通过执行以下命令来查看两个 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用来掩饰实际值），并且所有的Ambassador Pod都在运行（Ambassador依赖Kubernetes提供高可用，所以应该有两个在集群内的每个节点上运行的小 pod）。

您可以通过使用测试路由获取发出请求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

  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 服务的 Ambassador 映射。“前缀”映射 URI 取自作为入口点的大使服务根的上下文（通过端口 80 对外公开，​​因为它是负载平衡器），例如“35.224.41.XX/productpage/”。

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

kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml)
  1. （可选） bookinfo.yaml 通过键入从清单 中删除 Ingress 控制器kubectl delete ingress gateway。
  2. 通过转到您在上面配置的 Ambassador LoadBalancer 的 IP 来测试 Ambassador，例如 35.192.109.XX/productpage/。您可以通过键入 再次查看大使的实际 IP 地址 kubectl get services ambassador。

同样根据文档，不需要注入大使吊舱。

于 2019-12-16T16:27:00.233 回答
0

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

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

于 2020-02-18T21:37:50.777 回答
0

是的，我已经配置了所有这些东西。这就是我在附图中提到它的原因。我从 kiali 仪表板中获取了这个。我分享了 bookinfo 应用程序的输出。我已经部署了自己的应用程序，它也可以正常工作。但我想把这个未知的东西缩短。我正在使用 AWS EKS 集群。

关于大使的说明： 大使不应该拥有 Istio 边车，原因有两个。首先，它不能，因为运行两个独立的 Envoy 实例会导致它们的共享内存段发生冲突。第二个是大使不应该在你的网格中。网格非常适合处理从服务到服务的流量路由，但由于 Ambassador 是您的入口点，它应该完全负责决定路由到哪个服务以及如何进行。让 Ambassador 和 Istio 都尝试设置路由规则会让人头疼，而且没有多大意义。

于 2019-12-17T07:50:09.993 回答