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

Deploy the same version service in multiple clusters #13327

Closed
yuchen9459 opened this issue Apr 15, 2019 · 4 comments
Closed

Deploy the same version service in multiple clusters #13327

yuchen9459 opened this issue Apr 15, 2019 · 4 comments
Assignees
Labels
area/networking 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
Milestone

Comments

@yuchen9459
Copy link

Describe the feature request
Deploy the same version service in multiple clusters using gateway connected feature and make sure they can be accessed

Describe alternatives you've considered
In the Version Routing in a Multicluster Service Mesh tutorial , it deploys two version of review services in the second cluster. I created three Kubernetes clusters and deploy review-v1 in cluster1, review-v2 and review-v3 in cluster2 and cluster 3.
autodraw 4_15_2019

I wonder how can I deploy the same version service like review-v2 in two clusters and make sure both of them can be accessed.
Currently, I have tried to add some lines to the deployment files:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: reviews-default
spec:
  hosts:
  - reviews.default.global
  location: MESH_INTERNAL
  ports:
  - name: http1
    number: 9080
    protocol: http
  resolution: DNS
  addresses:
  - 127.255.0.3
  endpoints:
  - address: 172.17.0.3
    labels:
      cluster: cluster2
    ports:
      http1: 30417  # Do not change this port value
  - address: 172.17.0.4
    labels:
      cluster: cluster3
    ports:
      http1: 31940
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-global
spec:
  host: reviews.default.global
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v2
    labels:
      cluster: cluster3
      cluster: cluster2
   - name: v3
    labels:
      cluster: cluster2
      cluster: cluster3

As you can see from the yaml file, I added two endpoints for the ServiceEntry review-default. Since one subsets cannot have two labels, the second label in the configuration file will overwrite the first one. After deployment, v2 subset's corresponding label is cluster2, and v3 subset's corresponding label is cluster3. Therefore, after the deployment, all requests for a certain service will be directed to a cluster instead of two-clusters in a certain order (such as round-robin).

@hzxuzhonghu
Copy link
Member

I have investigated the gateway-connected multi-cluster model, and I think you can not create two same service in two different clusters.

@yuchen9459
Copy link
Author

I have investigated the gateway-connected multi-cluster model, and I think you can not create two same service in two different clusters.

Thanks! If it does not work in the gateway-connected multi-cluster model, is there any other way to implement this?

@andraxylia andraxylia added this to the 1.3 milestone Jun 27, 2019
@rlenglet rlenglet modified the milestones: 1.4, 1.3 Jul 9, 2019
@tapaskapadia
Copy link

I am also very curious how the same service with the same version that is deployed in different clusters can be both requested for depending on locality or performance using the gateway-connected multi-cluster model. I have not had any luck with similar efforts.

@istio-policy-bot istio-policy-bot added the lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. label Nov 6, 2019
@nmittler nmittler reopened this Nov 6, 2019
@nmittler nmittler reopened this Nov 7, 2019
@sdake sdake reopened this Apr 7, 2020
@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 Jul 6, 2020
@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 2020-04-07. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking 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

10 participants