3

I would like to create a simple architecture on Azure. My high level design is very similar to the picture below (source: https://www.import.io/post/using-amazon-lambda-and-api-gateway/)

enter image description here

I do want to access the internal services via the Azure API Management. What I can see on Microfos documentation page is that this simple and secure architecture is not mentioned as a reference:

https://learn.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough

enter image description here

I have the following issues:

  1. API Management cannot be assigned to a Virtual Network if there is at least one NIC is using the same network (why?)
  2. Even with peered Virtual Networks I cannot access 10.244.X.0/24 network (pods' network) because only 10.240.0.0/16 is owned by the k8s Virtual Network. How can I access cluster ips (10.0.0.0/16) and pod ips (10.244.0.0/16)?
csikos.balint
  • 1,107
  • 2
  • 10
  • 25

2 Answers2

1

The answer is basically YES although the setup is not trivial.

You need:

  • One extra VNet for the API Management (EDIT: an extra subnet is enough)
  • One service (kubernetes terminology)

Steps:

  1. Peer the Kubernetes VNet and the extra VNet you have created (test it)
  2. API Management -> Virtual network: change to External
  3. Choose as Virtual Network the one extra VNet (lets call it 'apimgmntvnet') and a Subnet
  4. Save it! Drink a beer because it took me 1h!
  5. Meanwhile expose your deployment internally: kubectl expose deployment app --port=<serviceport> --name=app --target-port=<containerport> --type=NodePort (NodePort is important!LoadBalancer type triggers kubernetes to dynamically configure the Azure External LB for Kubernetes install)
  6. Check node IP:PORT on kubernetes (kubectl proxy) BUI enter image description here
  7. API Management -> Publisher portal: modify your API to the IP address (AgentIP:30361)

Theoretically it should work. It is advised to start with a VM in the apimgmntvnet and try peering first from the VM and than delete it (API Management cannot be part of a VNet where at least one NIC is present (?!) ).

lborgav
  • 2,371
  • 19
  • 28
csikos.balint
  • 1,107
  • 2
  • 10
  • 25
  • 1
    Just want to inform the readers that it works this way. But is it right to point to the ip of one agent? Of course it works, but what about if you have to two agents. Where do you have to point at then? – cre8 Jul 04 '17 at 07:00
  • @mimo has a good point. It works, but you're using just the pods of ONE agent. – lborgav Jul 26 '17 at 20:31
  • instead of using NodePort, you can use an internal Load Balancer: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer – LanderV Mar 21 '18 at 12:58
1

Well, you don't need an Extra VNET, but just an extra Subnet. That Subnet could lie within your existing VNET. The Size of Subnet can be the smallest /29 which Azure supports.

The Extra Subnet requirement for API Management comes from the fact, that it is built on PAAS V1 (Classic) technology. While we can deploy into a Resource Manager VNET (V2 layer), there are consequences to that. The Classic deployment model in Azure are not tightly coupled with Resource Manager model and so if you create a resource in V2 stuff, the V1 doesn't know about it and problems can happen such as API Management trying to use an IP that is already allocated to a NIC (built on V2).

To learn more about difference of Classic and Resource Manager models in Azure refer to blog difference between Classic and ResourceManager models

Samir
  • 671
  • 4
  • 15