Hur routning fungerar med Azure dev SpacesHow routing works with Azure Dev Spaces

Viktigt

Azure Dev Spaces tas ur bruk och slutar att fungera den 31 oktober 2023.Azure Dev Spaces is being retired and will stop working on October 31, 2023. Överväg att migrera till Bridge till Kubernetes.Consider migrating to Bridge to Kubernetes.

Med Azure dev Spaces får du flera sätt att snabbt iterera och felsöka Kubernetes-program och samar beta med ditt team i ett Azure Kubernetes service-kluster (AKS).Azure Dev Spaces provides you with multiple ways to rapidly iterate and debug Kubernetes applications and collaborate with your team on an Azure Kubernetes Service (AKS) cluster. När projektet körs i ett dev-utrymme tillhandahåller Azure dev-utrymmen ytterligare funktioner för nätverk och routning för ditt projekt.Once your project is running in a dev space, Azure Dev Spaces provides additional networking and routing capabilities for your project.

Den här artikeln beskriver hur routning fungerar med dev-utrymmen.This article describes how routing works with Dev Spaces.

Så här fungerar routningHow routing works

Ett dev-utrymme bygger på AKS och använder samma nätverks koncept.A dev space is built on top of AKS and uses the same networking concepts. Azure dev Spaces har också en centraliserad ingressmanager -tjänst och distribuerar sin egen ingångs kontroll till AKS-klustret.Azure Dev Spaces also has a centralized ingressmanager service and deploys its own Ingress Controller to the AKS cluster. Ingressmanager -tjänsten övervakar AKS-kluster med dev Spaces och ökar den ingångs kontroll för Azure dev-platser i klustret med ingångs objekt för routning till program poddar.The ingressmanager service monitors AKS clusters with dev spaces and augments the Azure Dev Spaces Ingress Controller in the cluster with Ingress objects for routing to application pods. Devspaces-proxy-behållaren i varje Pod lägger till ett azds-route-as http-huvud för HTTP-trafik till ett dev-utrymme baserat på URL: en.The devspaces-proxy container in each pod adds an azds-route-as HTTP header for HTTP traffic to a dev space based on the URL. En begäran till URL: en får till exempel http://azureuser.s.default.serviceA.fedcba09...azds.io ett HTTP-huvud med azds-route-as: azureuser .For example, a request to the URL http://azureuser.s.default.serviceA.fedcba09...azds.io would get an HTTP header with azds-route-as: azureuser. Devspaces kommer inte att lägga till ett azds-route-as sidhuvud om det redan finns en.The devspaces-proxy container will not add an azds-route-as header if one is already present.

När en HTTP-begäran görs till en tjänst utanför klustret, skickas begäran till ingångs styrenheten.When an HTTP request is made to a service from outside the cluster, the request goes to the Ingress controller. Ingångs styrenheten dirigerar begäran direkt till lämplig Pod baserat på dess ingångs objekt och regler.The Ingress controller routes the request directly to the appropriate pod based on its Ingress objects and rules. Devspaces-proxy-behållaren i pod tar emot begäran, lägger till azds-route-as rubriken baserat på URL: en och skickar sedan begäran till program behållaren.The devspaces-proxy container in the pod receives the request, adds the azds-route-as header based on the URL, and then routes the request to the application container.

När en HTTP-begäran görs till en tjänst från en annan tjänst i klustret går begäran först igenom den anropande tjänstens devspaces-proxy-behållare.When an HTTP request is made to a service from another service within the cluster, the request first goes through the calling service's devspaces-proxy container. Devspaces-proxy-behållaren tittar på HTTP-begäran och kontrollerar azds-route-as rubriken.The devspaces-proxy container looks at the HTTP request and checks the azds-route-as header. Baserat på rubriken letar devspaces-proxy-behållaren upp IP-adressen för tjänsten som är associerad med huvudets värde.Based on the header, the devspaces-proxy container will look up the IP address of the service associated with the header value. Om det finns en IP-adress dirigerar devspaces-proxyn om begäran till den IP-adressen.If an IP address is found, the devspaces-proxy container reroutes the request to that IP address. Om det inte går att hitta en IP-adress dirigerar devspaces-behållaren begäran till den överordnade program behållaren.If an IP address is not found, the devspaces-proxy container routes the request to the parent application container.

Till exempel distribueras programmen service och serviceB till ett överordnat dev-utrymme som kallas default.For example, the applications serviceA and serviceB are deployed to a parent dev space called default. serva förlitar sig på serviceB och gör HTTP-anrop till den.serviceA relies on serviceB and makes HTTP calls to it. Azure User skapar ett underordnat dev-utrymme baserat på standard utrymmet som kallas azureuser.Azure User creates a child dev space based on the default space called azureuser. Azure-användare distribuerar också sin egen version av servicen till deras underordnade utrymme.Azure User also deploys their own version of serviceA to their child space. När en begäran görs till http://azureuser.s.default.serviceA.fedcba09...azds.io :When a request is made to http://azureuser.s.default.serviceA.fedcba09...azds.io:

Azure dev Spaces-routning

  1. Ingångs styrenheten söker efter IP-adressen för Pod som är associerad med URL: en, som är service. azureuser.The Ingress controller looks up the IP for the pod associated with the URL, which is serviceA.azureuser.
  2. Ingångs styrenheten hittar IP-adressen för Pod i Azure-användarens dev-utrymme och dirigerar begäran till tjänsten. azureuser pod.The Ingress controller finds the IP for the pod in Azure User's dev space and routes the request to the serviceA.azureuser pod.
  3. Devspaces-proxy-behållaren i tjänsten service-azureuser Pod tar emot begäran och lägger till azds-route-as: azureuser som ett HTTP-huvud.The devspaces-proxy container in the serviceA.azureuser pod receives the request and adds azds-route-as: azureuser as an HTTP header.
  4. Devspaces-proxy-behållaren i tjänst-. azureuser- Pod dirigerar begäran till tjänsten service- program i tjänst-azureuser- pod.The devspaces-proxy container in the serviceA.azureuser pod routes the request to the serviceA application container in the serviceA.azureuser pod.
  5. Tjänsten service- i -azureuser Pod gör ett anrop till serviceB.The serviceA application in the serviceA.azureuser pod makes a call to serviceB. Tjänsten service- app innehåller också kod för att bevara den befintliga azds-route-as rubriken, vilket i det här fallet är azds-route-as: azureuser .The serviceA application also contains code to preserve the existing azds-route-as header, which in this case is azds-route-as: azureuser.
  6. Devspaces-proxy-behållaren i tjänst-. azureuser- Pod tar emot begäran och letar upp IP-adressen för serviceB baserat på värdet i azds-route-as huvudet.The devspaces-proxy container in the serviceA.azureuser pod receives the request and looks up the IP of serviceB based on the value of the azds-route-as header.
  7. Devspaces-proxy-behållaren i tjänsten service-azureuser Pod hittar inte en IP-adress för serviceB. azureuser.The devspaces-proxy container in the serviceA.azureuser pod does not find an IP for serviceB.azureuser.
  8. Devspaces-proxy-behållaren i tjänsten service. azureuser Pod letar upp IP för serviceB i det överordnade utrymmet, som är serviceB. default.The devspaces-proxy container in the serviceA.azureuser pod looks up the IP for serviceB in the parent space, which is serviceB.default.
  9. Devspaces-proxy-behållaren i tjänsten service. azureuser Pod hittar IP för serviceB. default och dirigerar begäran till serviceB. default pod.The devspaces-proxy container in the serviceA.azureuser pod finds the IP for serviceB.default and routes the request to the serviceB.default pod.
  10. Devspaces-proxy-behållaren i serviceB. default -Pod tar emot begäran och dirigerar begäran till serviceB -programcontainern i serviceB. default pod.The devspaces-proxy container in the serviceB.default pod receives the request and routes the request to the serviceB application container in the serviceB.default pod.
  11. ServiceB -programmet i serviceB. default -Pod returnerar ett svar till tjänsten. azureuser pod.The serviceB application in the serviceB.default pod returns a response to the serviceA.azureuser pod.
  12. Devspaces-proxy-behållaren i tjänst-. azureuser- Pod tar emot svaret och dirigerar svaret till tjänsten service- program i tjänst-azureuser- pod.The devspaces-proxy container in the serviceA.azureuser pod receives the response and routes the response to the serviceA application container in the serviceA.azureuser pod.
  13. Tjänst programmet tar emot svaret och returnerar sedan sitt eget svar.The serviceA application receives the response and then returns its own response.
  14. Devspaces-proxy-behållaren i tjänst-. azureuser- Pod tar emot svaret från tjänsten service- program och dirigerar svaret till den ursprungliga anroparen utanför klustret.The devspaces-proxy container in the serviceA.azureuser pod receives the response from the serviceA application container and routes the response to the original caller outside of the cluster.

All annan TCP-trafik som inte är HTTP passerar genom ingångs styrenheten och devspaces.All other TCP traffic that is not HTTP passes through the Ingress controller and devspaces-proxy containers unmodified.

Dela ett dev-utrymmeSharing a dev space

När du arbetar med ett team kan du dela ett dev-utrymme i ett helt team och skapa härledda dev Spaces.When working with a team, you can share a dev space across an entire team and create derived dev spaces. Ett dev-utrymme kan användas av alla med deltagar åtkomst till dev-rummets resurs grupp.A dev space can be used by anyone with contributor access to the dev space's resource group.

Du kan också skapa ett nytt dev-utrymme som härleds från ett annat dev-utrymme.You can also create a new dev space that is derived from another dev space. När du skapar ett härlett dev-utrymme läggs etiketten azds.io/Parent-Space=Parent-Space-Name till i namn området för den härledda dev-ytan.When you create a derived dev space, the azds.io/parent-space=PARENT-SPACE-NAME label is added to the derived dev space's namespace. Dessutom delas alla program från det överordnade dev-utrymmet med det härledda dev-utrymmet.Also, all applications from the parent dev space are shared with the derived dev space. Om du distribuerar en uppdaterad version av ett program till det härledda dev-utrymmet finns det bara i det härledda dev-utrymmet och det överordnade dev-utrymmet förblir opåverkat.If you deploy an updated version of an application to the derived dev space, it will only exist in the derived dev space and the parent dev space will remain unaffected. Du kan ha högst tre nivåer av härledda dev Spaces och föräldrars utrymmen.You can have a maximum of three levels of derived dev spaces or grandparent spaces.

Det härledda dev-utrymmet kommer också att dirigera begär Anden mellan sina egna program och de program som delas från dess överordnade.The derived dev space will also intelligently route requests between its own applications and the applications shared from its parent. Routningen fungerar genom att försöka skicka begäran till ett program i det härledda dev-utrymmet och återgå till det delade programmet från det överordnade dev-utrymmet.The routing works by attempting to route request to an application in the derived dev space and falling back to the shared application from the parent dev space. Routningen kommer att återgå till det delade programmet på det föräldrarade utrymmet om programmet inte finns i det överordnade utrymmet.The routing will fall back to the shared application in the grandparent space if the application is not in the parent space.

Exempel:For example:

  • Standard för dev-utrymme har program service och serviceB.The dev space default has applications serviceA and serviceB.
  • Azureuser för dev-ytan härleds från standard.The dev space azureuser is derived from default.
  • En uppdaterad version av servicen har distribuerats till azureuser.An updated version of serviceA is deployed to azureuser.

När du använder azureuser kommer alla begär Anden att serva att dirigeras till den uppdaterade versionen i azureuser.When using azureuser, all requests to serviceA will be routed to the updated version in azureuser. En begäran till serviceB kommer först att försöka dirigeras till azureuser -versionen av serviceB.A request to serviceB will first try to be routed to the azureuser version of serviceB. Eftersom den inte finns kommer den att dirigeras till standard versionen av serviceB.Since it does not exist, it will be routed to the default version of serviceB. Om azureuser -versionen av servicen tas bort, kommer alla begär Anden att serva att återgå till att använda standard versionen av tjänsten.If the azureuser version of serviceA is removed, all requests to serviceA will fall back to using the default version of serviceA.

Nästa stegNext steps

Om du vill se ett exempel på hur Azure dev Spaces använder routning för att ge snabb iteration och utveckling, se hur fjärrfelsökning av din kod med Azure dev Spaces fungerar.To see an example of how Azure Dev Spaces uses routing to provide rapid iteration and development, see How remote debugging your code with Azure Dev Spaces works.