Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Multicluster]the istioctl debug tool in Primary-Remote model behavior improperly #29900

Closed
Tracked by #38
morvencao opened this issue Jan 7, 2021 · 5 comments
Closed
Tracked by #38
Assignees
Labels
area/user experience feature/Multi-cluster issues related with multi-cluster support lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while

Comments

@morvencao
Copy link
Member

Bug description

Install istio in Primary-Remote mode, and follow the verify steps to deploy helloworld and sleep applications, then I try to use the istioctl proxy-status and proxy-config commands to debug the Envoy and Istiod configurations, I found that:

  1. In the primary cluster, the istioctl proxy-status also shows sidecars from remote cluster:
# ./bin/istioctl --context="${CTX_CLUSTER1}" proxy-status
NAME                                                   CDS        LDS        EDS        RDS          ISTIOD                      VERSION
helloworld-v1-776f57d5f6-8lztd.sample                  SYNCED     SYNCED     SYNCED     SYNCED       istiod-5d46c5c495-n8lsv     1.8.1
helloworld-v2-54df5f84b-mc8f4.sample                   SYNCED     SYNCED     SYNCED     SYNCED       istiod-5d46c5c495-n8lsv     1.8.1
istio-eastwestgateway-dcdcbcb5d-g7bkb.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-5d46c5c495-n8lsv     1.8.1
istio-ingressgateway-5f89d44d4f-bxnrh.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-5d46c5c495-n8lsv     1.8.1
istio-ingressgateway-d99655c7b-rbxvv.istio-system      SYNCED     SYNCED     SYNCED     NOT SENT     istiod-5d46c5c495-n8lsv     1.8.1
sleep-854565cb79-dgmgc.sample                          SYNCED     SYNCED     SYNCED     SYNCED       istiod-5d46c5c495-n8lsv     1.8.1
sleep-854565cb79-h94bv.sample                          SYNCED     SYNCED     SYNCED     SYNCED       istiod-5d46c5c495-n8lsv     1.8.1
  1. But when I use proxy-config to check the XDS configuration on primary cluster from the sidecar in the remote cluster, I get pod not found error.
# ./bin/istioctl --context="${CTX_CLUSTER1}" proxy-config cluster sleep-854565cb79-h94bv.sample
Error: failed to execute command on sleep-854565cb79-h94bv.sample sidecar: failed retrieving pod: pods "sleep-854565cb79-h94bv" not found
  1. If I use the istioctl proxy-status to check all the sidecars on the remote cluster, there will no items:
# ./bin/istioctl --context="${CTX_CLUSTER2}" proxy-status
NAME     CDS     LDS     EDS     RDS     ISTIOD     VERSION

This is not really a bug, but an UX issue, the istioctl current can only retrieve information for sidecars from current cluster(primary cluster), we may need some get sidecars from remote cluster through apiserver, because the apiserver is available from primary cluster.

[ X ] User Experience
[ X ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane

@morvencao morvencao added feature/Multi-cluster issues related with multi-cluster support area/user experience labels Jan 7, 2021
@shamsher31
Copy link
Member

shamsher31 commented Jan 11, 2021

I tried it today and I can see that it only shows pod from primary cluster.

$ istioctl --context="${CTX_CLUSTER1}" proxy-status
NAME                                                    CDS        LDS        EDS        RDS          ISTIOD                      VERSION
helloworld-v1-776f57d5f6-ksrn4.sample                   SYNCED     SYNCED     SYNCED     SYNCED       istiod-679748f6d8-rlvpf     1.8.1
istio-eastwestgateway-854d659967-dlhhn.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-679748f6d8-rlvpf     1.8.1
istio-ingressgateway-7f6859b88-5snbt.istio-system       SYNCED     SYNCED     SYNCED     NOT SENT     istiod-679748f6d8-rlvpf     1.8.1
sleep-557747455f-fgvr7.sample                           SYNCED     SYNCED     SYNCED     SYNCED       istiod-679748f6d8-rlvpf     1.8.1

Also it's able to read proxy config from sleep pod.

$ istioctl --context="${CTX_CLUSTER1}" proxy-config cluster sleep-557747455f-fgvr7.sample
SERVICE FQDN                                             PORT      SUBSET     DIRECTION     TYPE             DESTINATION RULE
                                                         80        -          inbound       STATIC           
BlackHoleCluster                                         -         -          -             STATIC           
InboundPassthroughClusterIpv4                            -         -          -             ORIGINAL_DST     
PassthroughCluster                                       -         -          -             ORIGINAL_DST     
agent                                                    -         -          -             STATIC           
helloworld.sample.svc.cluster.local                      5000      -          outbound      EDS              
istio-eastwestgateway.istio-system.svc.cluster.local     15012     -          outbound      EDS                   
istio-ingressgateway.istio-system.svc.cluster.local      80        -          outbound      EDS

But as you mentioned it's not able to read proxy-status from remote cluster.

$ istioctl --context="${CTX_CLUSTER2}" proxy-status
NAME     CDS     LDS     EDS     RDS     ISTIOD     VERSION

@jeremybramwell
Copy link

I have been working on a POC based on the "Primary-Remote on the same network" example using istio 1.9.0 on two GKE clusters. I noticed the same awkward behavior described in this issue. I also found that trying to diff the config of an envoy proxy in the remote cluster against the istiod config doesn't work.

As described above calling istioctl proxy-status on the primary cluster returns all the proxies in the mesh:

$ istioctl proxy-status --context $PRIMARY_CLUSTER_CTX
NAME                                                   CDS        LDS        EDS        RDS          ISTIOD                      VERSION
api-worker-5b5d9f6d4f-crvzv.tenant-a                   SYNCED     SYNCED     SYNCED     SYNCED       istiod-79dfb4f5bd-bdlm2     1.9.0
api-worker-66ffd6599d-7jndf.tenant-b                   SYNCED     SYNCED     SYNCED     SYNCED       istiod-79dfb4f5bd-bdlm2     1.9.0
api-worker-685d4c6954-q5qxb.global                     SYNCED     SYNCED     SYNCED     SYNCED       istiod-79dfb4f5bd-bdlm2     1.9.0
istio-eastwestgateway-8fbfc8998-vsdk9.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-79dfb4f5bd-bdlm2     1.9.0
istio-ingressgateway-659fbbd8bd-96w6h.istio-system     SYNCED     SYNCED     SYNCED     SYNCED       istiod-79dfb4f5bd-bdlm2     1.9.0 

the first two pods, api-worker-....tenant-a and api-worker-....tenant-b, are in the remote cluster. If I try to diff the remote pod's config with istiod it fails with different errors depending on which cluster context I use.

Primary cluster ctx:

$ istioctl proxy-status api-worker-5b5d9f6d4f-crvzv.tenant-a --context ${PRIMARY_CLUSTER_CTX}
Error: failed retrieving pod: pods "api-worker-5b5d9f6d4f-crvzv" not found

Remote cluster ctx:

$ istioctl proxy-status api-worker-5b5d9f6d4f-crvzv.tenant-a --context ${REMOTE_CLUSTER_CTX}
Error: unable to find config dump in Istiod responses

It makes sense that this would be an issue since the remote pod and istiod are in different clusters. I just wanted to point out this additional issue, since it makes the diffing tool unusable in a situation where the potential for syncing issues is pretty high.

Let me know if this would be better entered as a separate issue.

@istio-policy-bot istio-policy-bot added the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Apr 12, 2021
@istio-policy-bot istio-policy-bot added the lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. label Apr 27, 2021
@stevenctl
Copy link
Contributor

not stale

@stevenctl stevenctl reopened this Jun 28, 2021
@istio-policy-bot istio-policy-bot removed the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Jun 28, 2021
@stevenctl stevenctl self-assigned this Jun 28, 2021
@istio-policy-bot istio-policy-bot added the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Sep 27, 2021
@istio-policy-bot
Copy link

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2021-06-28. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.

@hanxiaop
Copy link
Member

not stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/user experience feature/Multi-cluster issues related with multi-cluster support lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while
Projects
None yet
Development

No branches or pull requests

6 participants