Adding example for cert-manager letsencrypt for Istio-based service mesh

[deveshdama]

Adding example for cert-manager letsencrypt for ASM.

[biefy]

LGTM

[zioproto]

I tested the example and it works without any problems. I left some comments that are suggestions, like using sed to avoid modifying template files, or using nip.io to avoid giving the customer the trouble of registering a DNS name. If you would like you can accept my suggestions, but feel free to ignore them and keep your style of doing things. :)

Have you patched the controller.go to have the Istio Ingress work in a namespace different than istio-system ? This was not working back in January. Can you confirm ?

[zioproto]

One more idea. I understand nip.io is a nice tool, but it could go away anytime. As an alternative solution to remove the complexity of setting up a DNS name, it would be great of the External Istio Ingress Gateway could set a public-facing DNS label to the service using theservice.beta.kubernetes.io/azure-dns-label-name service annotation.

In open source Istio you can do it when installing the helm chart:

helm install istio-ingressgateway istio/gateway \
  --set service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"=my-istio-ingress \
  -n istio-system --wait

It would be great to have a way to set this annotation also with the add-on. Thanks !

[nshankar13]

@zioproto we're opening up a list of annotations for our users to customize on the ingress gateway. I was considering azure-dns-label-name but decided against it because you could effectively achieve the same thing by just using azure-load-balancer-ipv4 and setting the DNS name for the Azure public ip address. Is there any advantage to using the dns-name label instead of the ipv4 address - is it just easier to set up the DNS name?

[zioproto]

@zioproto we're opening up a list of annotations for our users to customize on the ingress gateway. I was considering azure-dns-label-name but decided against it because you could effectively achieve the same thing by just using azure-load-balancer-ipv4 and setting the DNS name for the Azure public ip address. Is there any advantage to using the dns-name label instead of the ipv4 address - is it just easier to set up the DNS name?

Could you just offer both annotations and let the customer decide what works best for them ? We have many customers and some will like better to lock to a specific IP, while others will prefer the DNS name.

With the OSS Helm chart you can just pass whatever annotation to the Kubernetes service, there you have a lot of flexibility.

Please let me know if this makes sense, or I can add more context. Thanks

[nshankar13]

@zioproto we're opening up a list of annotations for our users to customize on the ingress gateway. I was considering azure-dns-label-name but decided against it because you could effectively achieve the same thing by just using azure-load-balancer-ipv4 and setting the DNS name for the Azure public ip address. Is there any advantage to using the dns-name label instead of the ipv4 address - is it just easier to set up the DNS name?

Could you just offer both annotations and let the customer decide what works best for them ? We have many customers and some will like better to lock to a specific IP, while others will prefer the DNS name.

With the OSS Helm chart you can just pass whatever annotation to the Kubernetes service, there you have a lot of flexibility.

Please let me know if this makes sense, or I can add more context. Thanks

Thanks for that context - the main asks we've seen (GH issues, email threads) for the add-on have been for the ipv4 and ipv6 annotations specifically (ipv6 will likely come later but we need to test dual-stack prior). We haven't seen any specifically for the dns label name but if there have been asks and use-cases then I think it would make sense to consider. It sounds like in both cases though, you would still need to create an Azure Public IP beforehand - then either set the annotation to the IP address or the DNS name?

@deveshdama @biefy wondering if in the context of Let's Encrypt and Cert Manager this DNS annotation would be useful over ipv4 annotation but it seems to be the same in terms of configuration steps.

[deveshdama]

I tested the example and it works without any problems. I left some comments that are suggestions, like using sed to avoid modifying template files, or using nip.io to avoid giving the customer the trouble of registering a DNS name. If you would like you can accept my suggestions, but feel free to ignore them and keep your style of doing things. :)

Have you patched the controller.go to have the Istio Ingress work in a namespace different than istio-system ? This was not working back in January. Can you confirm ?

cool, thanks for the review. I've incorporated most of them except recommending nip.io. I feel like we've provided enough information for the users to make the decision.

we've made a fix on the azure servicemesh codebase to allow for ingress to be configured via shared configmap.

[deveshdama]

@zioproto can you please update the blog post when you get some time - blog

[zioproto]

@zioproto can you please update the blog post when you get some time - blog

@deveshdama I confirm I updated the blog post with a reference to this PR. Thanks