https://pulumi.com logo
Powered by
Title
a

ancient-megabyte-79588

05/13/2020, 8:56 PM
This fragment of Pulumi-code that uses the nginx Ingress Controller Helm chart is working but it does not use my k8sDnsLabel in the PublicIP that is created in Azure by the IngressController. I'm wondering if any of you have any insights. 
const env = pulumi.getStack(); // reference to this stack
const stackId = `dave/aks/${env}`;
const aksStack = new pulumi.StackReference(stackId);
const k8sDnsName = aksStack.getOutput("k8sDnsName"); // <-- This is "identity-auth-dev"

// Deploy ingress-controller using helm to AKS Cluster
const options = {
    chart: "nginx-ingress-controller",
    namespace: "kube-system",
    repo: "bitnami",
    values: {
        annotations: {
            "<http://service.beta.kubernetes.io/azure-dns-label-name|service.beta.kubernetes.io/azure-dns-label-name>": "identity-auth-dev"
        },
        resources: { requests : {memory: "150Mi", cpu: "100m"}},
        serviceType: "LoadBalancer",
        nodeCount: 1,
    }
};
const nginxIngress = new k8s.helm.v3.Chart("nginx", options, {provider: k8sProvider });
b

billowy-army-68599

05/13/2020, 9:01 PM
hey there! can you elaborate a little more more on the k8sDnsLabel? I don't see it in this code, although I could be missing it!
a

ancient-megabyte-79588

05/13/2020, 9:04 PM
Yes, I've updated the example. I spoke of k8sDnsLabel but removed it and just put the string in the annotation.
Sorry
I'm thinking the annotation doesn't work, or I'm using it wrong.
I did have a similar annotation in there that made the LB internal and that did work.
I tried this direct helm chart install and it also did not work. 
helm install nginx-ingress bitnami/nginx-ingress-controller \
--namespace ingress \
--set controller.replicaCount=1 \
--set controller.service.annotations."service\.beta\.kubernetes\.io\/azure-dns-label-name"=identity-auth-dev \
b

billowy-army-68599

05/13/2020, 10:04 PM
i'll try repro this when I get a sec, i believe I've got this working somewhere
a

ancient-megabyte-79588

05/13/2020, 11:06 PM
That would be great @billowy-army-68599!
I've been standing up and tearing down LBs for an hour, using different combinations of stuff. I've found no way to make it work yet.
r

rhythmic-finland-36256

05/16/2020, 12:18 PM
If I remember correctly, you also need to specify the resource group where your public ip is located. Remember that the cluster nodes are put into a separate resource group than the one where you create the „parent“ Kubernetes cluster resource. By default, the vms, nics, and so on are created in a resource group named MC_... and this is also where azure tries to find the public ip...
See https://docs.microsoft.com/en-us/azure/aks/static-ip#create-a-service-using-the-static-ip-address
a

ancient-megabyte-79588

05/19/2020, 3:10 PM
Thanks @rhythmic-finland-36256. I'll try that. I had the resouceGroup annotation in there at some point, but removed it when trying to simplify. I'll put it back into this simple example and see what happens.
k

kind-mechanic-53546

05/24/2020, 12:07 PM
@ancient-megabyte-79588, did adding the resource group annotation fix this?
I have to do the same thing, tomorrow
a

ancient-megabyte-79588

05/24/2020, 4:37 PM
I'll 
pulumi destroy
and 
pulumi up
today and I'll let you knw.
@kind-mechanic-53546
k

kind-mechanic-53546

05/24/2020, 10:23 PM
Thanks 🙂
a

ancient-megabyte-79588

05/25/2020, 4:20 PM
@kind-mechanic-53546 This does not work 
// from the start of the app
const k8sDnsName = aksStack.getOutput("k8sDnsName");
const clusterResourceGroup = aksStack.getOutput("nodeResourceGroup");

// Deploy ingress-controller using helm to AKS Cluster
const nginxIngress = new k8s.helm.v3.Chart("nginx", {
    chart: "nginx-ingress-controller",
    namespace: "kube-system",
    repo: "bitnami",
    values: {
        annotations: {
            "<http://service.beta.kubernetes.io/azure-dns-label-name|service.beta.kubernetes.io/azure-dns-label-name>": k8sDnsName,
            "<http://service.beta.kubernetes.io/azure-load-balancer-resource-group|service.beta.kubernetes.io/azure-load-balancer-resource-group>": clusterResourceGroup,

        },
        resources: { requests : {memory: "150Mi", cpu: "100m"}},
        serviceType: "LoadBalancer",
        nodeCount: 1,
    }
}, {provider: k8sProvider });
I use this script to do the work manually 
# get the PublicIP object for our load balancer
$pip = az network public-ip list --query "[?tags.service=='kube-system/nginx-nginx-ingress-controller']" | ConvertFrom-Json
# update the --dns-name and refresh our object in PowerShell
$pip = az network public-ip update -n $pip.name -g $pip.resourceGroup  --dns-name "identity-auth-dev" | ConvertFrom-Json
# set the clusterFQDN in Pulumi
pulumi config set clusterFQDN $pip.dnsSettings.fqdn
# verify that we can resolve our DNS entry
nslookup $pip.dnsSettings.fqdn
r

rhythmic-finland-36256

05/25/2020, 4:59 PM
You also need to hand in the public IP address that should be used into the ingress-controller service of type loadBalancer. That’s how we do it. Seems a bit redundant but in the end you also need to do some dns setup for this specific ip to match the domain names used for the ingresses, so with pulumi, that’s pretty okay to pass in the 
azure-load-balancer-resource-group
and the 
loadBalancerIP
as both are probably created from the same pulumi stack.
a

ancient-megabyte-79588

05/25/2020, 5:03 PM
I've found that you only need to pass in the PublicIp address if you are using an existing IP address, which I am not. when I started this, I was using a pre-created static IP address but I found a limitation that I can't remember at the moment. So, I let the IngressController create the LB and the PublicIp address and use the DNS Name Label to create a consistent Azure-provided DNS entry which I have as a CNAME entry on my DNS provider.
r

rhythmic-finland-36256

05/25/2020, 5:04 PM
see https://github.com/helm/charts/blob/be1d8ab9d3fe33766639275259e635f9336a0985/stable/nginx-ingress/templates/controller-service.yaml#L32
a

ancient-megabyte-79588

05/25/2020, 5:06 PM
So in this case, my DNS name label of 
identity-auth-dev
would turn into identity-auth-dev.westus.cloudapp.azure.com which I put in my DNS provider (GoDaddy) as a CNAME entry of 
<http://auth.codingwithdave.xyz|auth.codingwithdave.xyz>
pointing to identity-auth-dev.westus.cloudapps.azure.com
r

rhythmic-finland-36256

05/25/2020, 5:07 PM
All right, cool. So you can know that beforehand as you define the dns name when creating the ingress controller.
a

ancient-megabyte-79588

05/25/2020, 5:07 PM
You don't need to do that if you are not providing the PublicIp address.
I don't have a PublicIp resource when creating the helm chart
the IngressController, in Azure, does all of that for me.
I was using that exact 
controller.service.LoadBalancerIP
at the start.
r

rhythmic-finland-36256

05/25/2020, 5:08 PM
I understand. It’s just a matter of which action causes which result. The CNAME way is also a good idea.
👍 1
But then you also hand in the responsibility to create a unique name for the dns label to the ingress controller deployment, right?
a

ancient-megabyte-79588

05/25/2020, 5:09 PM
I think something is broken or changed in the nginx IngressController or in Azure that the 
annotations: {
            "<http://service.beta.kubernetes.io/azure-dns-label-name|service.beta.kubernetes.io/azure-dns-label-name>": k8sDnsName,
            "<http://service.beta.kubernetes.io/azure-load-balancer-resource-group|service.beta.kubernetes.io/azure-load-balancer-resource-group>": clusterResourceGroup,
},
annotation doesn't work anymore.
r

rhythmic-finland-36256

05/25/2020, 5:09 PM
So deploying the same stack twice requires you to provide different dns labels so that everything works.
For us that still works…
a

ancient-megabyte-79588

05/25/2020, 5:10 PM
What is the scenario that you'd deploy the same stack twice to two different places?
r

rhythmic-finland-36256

05/25/2020, 5:11 PM
OKAY, I didn’t redeploy the ingress controller in the last week 🙂
Not the same pulumi stack, but the same set of resources once for test and once for prod
in the same region
So that’s one more place where you need to make sure to create unique (and also still available) names in azure.
a

ancient-megabyte-79588

05/25/2020, 5:12 PM
My stacks are dev/test/stage/prod and I would use those names to help with the uniqueness constraint of the DNS Name label
r

rhythmic-finland-36256

05/25/2020, 5:12 PM
But yeah, that’s the same like with public facing storage accounts…
a

ancient-megabyte-79588

05/25/2020, 5:12 PM
It isn't that way in my example..
I could have the same stack in different regions and they'd get different URLs since the region is backed into the *.cloudapp.azure.com part of the Url
r

rhythmic-finland-36256

05/25/2020, 5:13 PM
Hopefully nobody created ``${yourprefix}-prod`` before you first deploy to prod.
a

ancient-megabyte-79588

05/25/2020, 5:14 PM
My prefix could be a guid.. I haven't done that for simplicity sake..
👍 1
r

rhythmic-finland-36256

05/25/2020, 5:14 PM
I try to avoid such cases if possible.
All right. So: problem solved.
a

ancient-megabyte-79588

05/25/2020, 5:16 PM
Well, not exactly. The DNS name label doesn't work during the 
pulumi up
so I have to do it with PS script against the azure-cli after the deployment.
r

rhythmic-finland-36256

05/25/2020, 5:16 PM
Oh, sorry. I thought that worked…
a

ancient-megabyte-79588

05/25/2020, 5:16 PM
Something is wrong with the way Azure or nginx IngressController are handling that annotation
I haven't to do this after the 
pulumi up
# get the PublicIP object for our load balancer
$pip = az network public-ip list --query "[?tags.service=='kube-system/nginx-nginx-ingress-controller']" | ConvertFrom-Json
# update the --dns-name and refresh our object in PowerShell
$pip = az network public-ip update -n $pip.name -g $pip.resourceGroup  --dns-name "identity-auth-dev" | ConvertFrom-Json
# set the clusterFQDN in Pulumi
pulumi config set clusterFQDN $pip.dnsSettings.fqdn
# verify that we can resolve our DNS entry
nslookup $pip.dnsSettings.fqdn
r

rhythmic-finland-36256

05/25/2020, 5:18 PM
Ah, so the dns-name-label isn’t set automatically when Azure creates the public IP. That was the empty text box…
a

ancient-megabyte-79588

05/25/2020, 5:18 PM
Yeah
I've got a question in this Github issue
https://github.com/MicrosoftDocs/azure-docs/issues/18204
Here is a blog post detailing my current approach https://westerndevs.com/kubernetes/kubernetes-my-journey-part-8/
r

rhythmic-finland-36256

05/25/2020, 5:24 PM
Nice setup. We do the same with traefik.
a

ancient-megabyte-79588

05/25/2020, 5:25 PM
I had 
traefik
in there for a bit, but found examples harder to find. I'm really interested in continuing that exploration.
r

rhythmic-finland-36256

05/25/2020, 5:25 PM
If you want to solve it and your azure service principal has the permissions to create public ips, you still have the option to create it (even in the cluster resource group), add the dns-name label there and hand it into the helm deployment.
a

ancient-megabyte-79588

05/25/2020, 5:26 PM
That is certainly a path that I'll explore. I'd like the current annotations to do the right thing, or find documentation about what I"m doing wrong because some people seem to be able to get it to work.
r

rhythmic-finland-36256

05/25/2020, 5:30 PM
Digging deeper… https://github.com/Azure/AKS/issues/1376
https://github.com/MicrosoftDocs/azure-docs/issues/45878
That sounds like better not relying on this magic to work with the next upgrade of AKS. I’ll stick with pre-created IPs and hand them into the service.
Still, setting the dns-name label might be a nice way to decouple the real dns entries from the concrete ips used…
a

ancient-megabyte-79588

05/25/2020, 5:43 PM
There was a reason I switched from a pre-created PIp .. I can't recall now. And the CNAME entry is really easy to manage.
I'm trying upgrading the version of k8s in AKS to 1.18.2 (preview) ... see if that makes a difference. After reading that bug/issue in the AKS github repo
r

rhythmic-finland-36256

05/25/2020, 5:57 PM
All right. Creating the IP manually (from pulumi) and assigning a dns-name would still work for the CNAME way of dealing with the real dns names. So it’s basically just about if you want to create a public IP resource from the stack where you have your helm charts.
I was in that situation too using too many stacks for base infra, base kubernetes deployments and app so that eventually I merged them back into one because there were too many interconnections.
E.g. we deployed one application that doesn’t work over http, so it needs its own loadbalancer (and the public IP). That was in my 
kubernetes apps
stack, but creating a public IP from there didn’t feel right.
And creating that IP in some base stack and exporting it would have worked technically but then the base stack would make assumptions about the apps to be deployed.
k

kind-mechanic-53546

05/26/2020, 12:11 PM
Thanks for the update @ancient-megabyte-79588 🙂
👍 1
@ancient-megabyte-79588, @rhythmic-finland-36256, I've confirmed this works, either with pre-supplying an IP or letting it auto-create Took me a while destroying and recreating to get the annotations right AKS K8s 1.16.9 
// Deploy NGINX ingress controller using the Helm chart.
const nginx = new k8s.helm.v2.Chart(
  "nginx-ingress-helm-chart",
  {
    namespace: conf.k8sClusterConfig.ingressNsName,
    chart: "nginx-ingress",
    version: nginx_helm_chart_version,
    fetchOpts: { repo: "<https://kubernetes-charts.storage.googleapis.com/>" },
    values: {
      controller: {
        publishService: { enabled: true },
        service: {
          //loadBalancerIP: lbPublicIp.ipAddress.apply((v) => v),
          annotations: {
            "<http://service.beta.kubernetes.io/azure-dns-label-name|service.beta.kubernetes.io/azure-dns-label-name>":
              "asdfluahsdfasdf",
          },
        },
      },
    },
    transformations: [
      (obj: any) => {
        // Do transformations on the YAML to set the namespace
        if (obj.metadata) {
          obj.metadata.namespace = conf.k8sClusterConfig.ingressNsName;
        }
      },
    ],
  },
  { provider: provider }
);
Oh, and I'm using a different repo from you @ancient-megabyte-79588 (default in the crosswalk guides IIRC)
a

ancient-megabyte-79588

05/26/2020, 10:10 PM
Do you have a link to the repo?
k

kind-mechanic-53546

05/26/2020, 10:10 PM
https://kubernetes-charts.storage.googleapis.com/
this one?
a

ancient-megabyte-79588

05/26/2020, 10:11 PM
Oh.. for the helm chart.. ok .. gotcha
What did you determine that 
publishService: { enabled: true },
does?
I think I"m using Helm v3 as well 
const nginxIngress = new k8s.helm.v3.Chart("nginx", {
k

kind-mechanic-53546

05/26/2020, 10:13 PM
umm
ah, yes, there is that too
a

ancient-megabyte-79588

05/26/2020, 10:15 PM
I don't think the v2 vs. v3 is important
Just a point of interest
k

kind-mechanic-53546

05/26/2020, 10:18 PM
Re: publishService
Only the LoadBalancer Service knows the IP address of the automatically created Load Balancer. Some apps (such as ExternalDNS) need to know its IP address, but can only read the configuration of an Ingress. The Controller can be configured to publish the IP address on each Ingress by setting the 
controller.publishService.enabled
 parameter to 
true
 during 
helm install
. It is recommended to enable this setting to support applications that may depend on the IP address of the Load Balancer.
Probably not relevant, think it was just copied over
I forked the crosswalk stacks originally so most code is Pulumi's great work
a

ancient-megabyte-79588

05/26/2020, 10:23 PM
awesome! Thanks a ton for finding this. I'm tearing down and standing up my cluster again right now.
I don't think think we need the publishService parameter for Azure, but I've put it in for the moment.
k

kind-mechanic-53546

05/26/2020, 10:24 PM
NP, thanks for doing the initial work 🙂
a

ancient-megabyte-79588

05/26/2020, 10:27 PM
Well, this is a bit frustrating
No DNS Label
k

kind-mechanic-53546

05/26/2020, 10:28 PM
gah
a

ancient-megabyte-79588

05/26/2020, 10:28 PM
// Deploy ingress-controller using helm to AKS Cluster
const nginxIngress = new k8s.helm.v3.Chart("nginx", {
    chart: "nginx-ingress-controller",
    namespace: "kube-system",
    repo: "bitnami",
    values: {
        controller: {
            publishService: { enabled: true },
            service: {
              annotations: {
                "<http://service.beta.kubernetes.io/azure-dns-label-name|service.beta.kubernetes.io/azure-dns-label-name>": "k8sDnsName",
                "<http://service.beta.kubernetes.io/azure-load-balancer-resource-group|service.beta.kubernetes.io/azure-load-balancer-resource-group>": clusterResourceGroup,
                }
            },
        },
        resources: { requests : {memory: "150Mi", cpu: "100m"}},
        serviceType: "LoadBalancer",
        nodeCount: 1,
    }
}, {provider: k8sProvider });
I'll try removing the cluster resource group annotation
I also tried upgrading my whole cluster to 1.18.2
prior to this.. and that didn't help...
k

kind-mechanic-53546

05/26/2020, 10:33 PM
just pulling down and adding your exact code
a

ancient-megabyte-79588

05/26/2020, 10:33 PM
I was going to do that with your code next too! 😄
k

kind-mechanic-53546

05/26/2020, 10:34 PM
Odd, your SKU is Basic, Mine is Standard...
a

ancient-megabyte-79588

05/26/2020, 10:38 PM
Interesting..
I don't know what controls that
Your chart is different
chart: "nginx-ingress",
is yours 
chart: "nginx-ingress-controller",
is mine
k

kind-mechanic-53546

05/26/2020, 10:45 PM
yep
do you know the diff off the top of your head? I don't
there's so much I just don't know at this stage 😞
a

ancient-megabyte-79588

05/26/2020, 10:51 PM
I don't know the difference either.. I imagine you can find the chart definitions in github
I'll go look eventually
Ok.. hold on...
This may be a PEBKAC error
I am editing the wrong index.ts
(╯°□°)╯︵ ┻━┻
k

kind-mechanic-53546

05/26/2020, 10:53 PM
haha
I've done that before...
a

ancient-megabyte-79588

05/26/2020, 11:00 PM
ok.. I'm trying on what should be the real index.ts now!
@kind-mechanic-53546 in case you didn't see this in another thread, I have blogged about a ton of the work I've been doing. You can check it out here. https://westerndevs.com/kubernetes/kubernetes-my-journey/
All of the pulumi stuff starts at part 7
k

kind-mechanic-53546

05/26/2020, 11:01 PM
yep, legendary 🙂
out of curiosity, why did you go with IDSRV4 vs AAD B2C or AAD?
a

ancient-megabyte-79588

05/26/2020, 11:05 PM
That has turned out to be a great question... the decision to do ID4 was in Dec... A bunch of work had gone into eval of ID4 and we didn't really have exposure to AAD B2C and the newly announced features of AAD External Identities announced at build really throws a loop into things
k

kind-mechanic-53546

05/26/2020, 11:07 PM
no idea which is the right one, I've used idsrv4 in the past for an on-prem system and it was great
a

ancient-megabyte-79588

05/26/2020, 11:07 PM
We have apps and devices that will need to be managed.. I don't have an answer for that with AAD B2C yet.. for us .. it isn't just people.
ID4 looks to be a good fit, and while I want to investigate B2C and External Identities, I don't know that I need to put the project on hold while we re-do it to use the Azure services.
k

kind-mechanic-53546

05/26/2020, 11:08 PM
AAD B2C is a bit of a struggle to get working, and no good option for MFA
SMS only, 🤮
yep, ID4 is fine
a

ancient-megabyte-79588

05/26/2020, 11:09 PM
ID4 has MFA built in .. not as nice as the app with push notifications, but authenticator with rolling codes is a good start.
k

kind-mechanic-53546

05/26/2020, 11:09 PM
my app is B2C only ATM
a

ancient-megabyte-79588

05/26/2020, 11:10 PM
So... my IngressController didn't even get provisioned! 😄
k

kind-mechanic-53546

05/26/2020, 11:10 PM
well
a

ancient-megabyte-79588

05/26/2020, 11:10 PM
No LB either in Azure
I'm going to change the chart
Interesting.. bitnami doesn't know about the 
nginx-ingress
chart
k

kind-mechanic-53546

05/26/2020, 11:22 PM
I cannot get it to work with the bitnami controller chart
a

ancient-megabyte-79588

05/26/2020, 11:29 PM
If this has been a bitnami chart problem, I'll be mad
I'm standing up the stable repo nginx-ingress now
k

kind-mechanic-53546

05/26/2020, 11:32 PM
pretty sure it is a bitnami problem
why bitnami?
a

ancient-megabyte-79588

05/26/2020, 11:33 PM
I don't know.. it was one of the first repos I saw with many examples ..
And... IT WORKED!
I'm going to write a strongly worded letter.
😛
JohnB, thank you so much for all of your help on this!
🙇
🙏
I can go fix the article with an addendum!
FYI, here is the Bitnami link to this chart https://bitnami.com/stack/nginx-ingress-controller/helm
This chart may have a different values.yml ...
k

kind-mechanic-53546

05/26/2020, 11:42 PM
🎉
is your LB now Standard, instead of Basic?
(and I guess the IP's)
r

rhythmic-finland-36256

05/27/2020, 9:08 AM
Nice you figured that out. Now as you wrote I remember that I also stumbled upon strange differences on Azure side because of Basic instead of Standard SKU. Especally with Standard not being the default…
I once had to tear down a whole cluster because I wanted load balancer monitoring which requires a public IP with Standard SKU. But changing the type of the public IP SKU cannot be done without fully recreating the whole cluster…
I guess if you want your infra to be future proof and enable a feature later that you didn’t think of today, booking a basic sku for anything is a bad idea…
a

ancient-megabyte-79588

05/27/2020, 1:43 PM
@kind-mechanic-53546 no.. my PublicIP address is basic.. which I don't think was impacting this working.
I'm tearing this down this morning, and trying to stand up the bitnami chart again, with a tweak on the 
values: {}
object
@kind-mechanic-53546 This also works! 
// Deploy ingress-controller using helm to AKS Cluster
const nginxIngress = new k8s.helm.v3.Chart("nginx", {
    chart: "nginx-ingress-controller",
    namespace: "kube-system",
    repo: "bitnami",
    values: {
        service :{
            annotations: {
                "<http://service.beta.kubernetes.io/azure-dns-label-name|service.beta.kubernetes.io/azure-dns-label-name>": k8sDnsName,
                "<http://service.beta.kubernetes.io/azure-load-balancer-resource-group|service.beta.kubernetes.io/azure-load-balancer-resource-group>": clusterResourceGroup,
            },
        },
        resources: { requests : {memory: "150Mi", cpu: "100m"}},
        serviceType: "LoadBalancer",
        nodeCount: 1,
    }
}, {provider: k8sProvider });
so in the stable chart, you need to do 
controller : { services: { annotations :{} } }
and in the bitnami chart, you leave out the 
controller: { }
parent object
This is certainly blog-learning worthy, because until know, I sort of assumed all charts were the same if they were "sort of" the same name.
And I saw lots of examples with the stable/nginx-ingress but I was always assuming that the only difference with the bitnami one was the name, so when I tweaked my 
values: {}
object, I'd wouldn't pay enough attention to which repo/chart I was using and look at that specific charts github values.yml example.
k

kind-mechanic-53546

05/27/2020, 9:50 PM
Absolutely, re blog worthy, a rewarding learning exercise 🙂
Do either of you gents know what controls the Basic vs Standard SKU?
I'd prefer to use Basic in dev/test but haven't figured out as yet how to switch
a

ancient-megabyte-79588

05/27/2020, 10:07 PM
I haven't figured that out either. I don't think it is the AKS cluster.. I don't recall picking a SKU for that. I don't indicate what SKU of LB I want in the Helm chart, and the Helm chart/LB provision the publicIp as well.
k

kind-mechanic-53546

05/27/2020, 10:07 PM
Yep, odd
a

ancient-megabyte-79588

05/27/2020, 10:08 PM
One thing I thought is that perhaps in your Azure zone (Australia East) or Subscription that a basic IP or basic LB ins't available.
k

kind-mechanic-53546

05/27/2020, 10:08 PM
basic IP def is
not sure about LB
having said that, I'd probably prefer it to be a standard sku for prod
a

ancient-megabyte-79588

05/27/2020, 10:09 PM
Other than availability zones (which we don't use), I don't know enough of what the difference would be to make a choice.
k

kind-mechanic-53546

05/27/2020, 10:10 PM
Both are available for my subscription
I don't know either, but at the cost of a full teardown / setup in prod...
a bit of future proofing
a

ancient-megabyte-79588

05/27/2020, 10:11 PM
You only have to tear out the Ingress-Controller to get rid of the LB and pIp
k

kind-mechanic-53546

05/27/2020, 10:12 PM
ah, yes
a

ancient-megabyte-79588

05/27/2020, 10:12 PM
Obviously, you'd take an outage doing that though
k

kind-mechanic-53546

05/27/2020, 10:12 PM
derp
a

ancient-megabyte-79588

05/27/2020, 10:13 PM
In theory, it could be no-outage...
You could stand-up a new LB with out the DNS Name label, get it configured properly, then use the azure-cli to flip the DNS name labels, then tear out the old LB.
If you are using the CNAME technique
k

kind-mechanic-53546

05/27/2020, 10:15 PM
true
re the CNAME technique, so you have a CNAME pointing to your dns name label?
e.g. api.site.com => xxx.cloudapp.azure.com
👍 1
is that right?
then I guess just have to ensure you never lose control of xxx.cloudapp.azure.com
Regarding Basic v Standard LB SKU's, Basic only supports 1 node pool
https://docs.microsoft.com/en-us/azure/aks/use-multiple-node-pools
which I'm eventually planning on having multiple
1 best effort with low priority VMSS (or whatever they renamed it), and then 1 SLA
a

ancient-megabyte-79588

05/28/2020, 12:31 AM
That's some good investigation @kind-mechanic-53546. I don't know at the moment if I'll have multiple node pools or multiple clusters, each with a single node pool. But I can investigate how to get a Standard IP. I didn't have a preference. I just took the default.
4 Views
#kubernetesJoin Slack
Powered by