Azure Kubernetes Service (AKS) forbidden address ranges for vnet
I installed some months ago an AKS cluster with kubenet networking without problems. In our last version upgrade something changed, because it complained that we were using for the vnet where the cluster is placed a private address range that is disallowed in the documentation: AKS clusters may not use 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16, or 192.0.2.0/24 for the Kubernetes service address range, pod address range or cluster virtual network address range The problem is that we use these "forbidden" private address ranges for our network infrastructure in azure (we have a hub & spoke architecture) and on-premises (we have an ExpressRoute connection) and it seems that we have to make a huge change in all our network to be able to upgrade or reinstall the AKS cluster with full connectivity. I tried with Azure support but they say that it is a design decision that can not be changed. If anybody has any suggestion to deal with this AKS upgrade/reinstall problem (that does not require a complete change in our IP addressing policy), that would be very helpful.Azure Container Registry - New comic
- You are a Cloud lover? - But you prefer Azure? - Learning with fun? Maybe you'll like the last Azure Container Registry comic provided by Jules&Léa: If you want to deep dive, do not hesitate to visit the official documentation on Microsoft: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-intro ++
Solution for remote development team access to private AKS managed cluster
Hi All, I am exploring options to allow my remote development team access to private AKS managed cluster in Azure with AAD and RBAC enabled . Our access options to AKS are via Bastion or VDi and each pose a unique set of challenges. I will outline each and my overall proposed solution Bastion access via kv and shared VM local credentials: problem is remote developers will require access to Azure portal then bastion into a local VM using kv shared credentials, this may work but not practical because each developers require a unique kubectl profile/config file when access aks, which is overwritten when another user logs on. Also remote access into bastion timeouts occasionally and AKS auth flow via browser into aks sometimes displays a blank page and cumbersome to logon VDI access pose similar challenges, no access to install development tools and all session settings are reset when the user logged off My proposed solution is bastion access via native rdp client access along with an AAD joined VM on the private cluster network. This solution requires no Azure portal access and provides direct RDP access into the AAD VM using AAD credentials and conditional access. Also the problem with kubectl profile no longer an issue as each logon user will have AAD credentials and user profile . Changes required to implement: Bump up Bastion sku from basic to standard to allow RDP native client, however the user (remote) session need to be initiated from a AAD registererd machine or hybrid or AAD join to establish a connection to bastion via RDP native client which then allow rdp access with AAD credentials onto the AAD joined server hosted in Azure Welcome all feedback and or corrections based on my initial solution assessment Thanks Darren
Influx in Azure Marketplace
Hi, I have subscribed to the Influx DB from Azure Marketplace, as per the documentation of the Influx, when the subscription and account creation is done, Influx cloud will use the AKS and VM's from the Azure. But I didn't see any AKS or VM's created for the Influx. Thanks, Shashi.
define name for ALB when creating kubernetes ingress in AKS
I’m creating Kubernetes nginx ingress controller using Helm https://artifacthub.io/packages/helm/ingress-nginx/ingress-nginx Since I’m provisioning a private AKS cluster, I instruct via annotations that the Azure Load Balancer that gets created has a private rather than a public IP address (service.beta.kubernetes.io/azure-load-balancer-internal and service.beta.kubernetes.io/azure-load-balancer-internal-subnet). Here's the values.yaml file that I provide when running helm install controller: replicaCount: ` image: registry: foo.azurecr.io digest: "" pullPolicy: Always ingressClassResource: # -- Name of the ingressClass name: "internal-nginx" # -- Is this ingressClass enabled or not enabled: true # -- Is this the default ingressClass for the cluster default: false # -- Controller-value of the controller that is processing this ingressClass controllerValue: "k8s.io/internal-ingress-nginx" admissionWebhooks: patch: image: registry: foo.azurecr.io digest: "" service: annotations: "service.beta.kubernetes.io/azure-load-balancer-internal": "true" "service.beta.kubernetes.io/azure-load-balancer-internal-subnet": subnet01 loadBalancerIP: "x.x.x.x" watchIngressWithoutClass: true ingressClassResource: default: true defaultBackend: enabled: true image: registry: foo.azurecr.io digest: "" Each single ingress controller creates an Azure Load Balancer namedkubernetes-internal: I've searched LoadBalancer annotations but can't find a way to control what the actual name for the ALB will be, or is it always kubernetes-internal ? Anyone has any ideas please ?How to create a new test environment for gMSA on AKS (preview)
Vinicius outlines each step and commands you will need to set up a test AKS environment to support the new (preview) Group Managed Service Accounts feature. Now you can run Active Directory dependent apps in containers! https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-creating-a-new-test-environment-for-gmsa-on-aks/ba-p/3107779?WT.mc_Id=modinfra-56270-socuff
AKS an ACI Deployment with blob mount
I have a use case wherein I need to refer to the input dataset in the ACI/AKS which is in a blob (same used for training model). I'm not able to find related resources in the Microsoft official documentation. If anyone suggests to me how to do it, that will be very helpful.AKS not responding
The entirety of my AKS cluster does not appear to be responding to any requests. The (linux based) nodes in the cluster appear to have been recently (a few hours ago) restarted for maintenance (by Azure). The az aks browse command returns with "Unable to connect to the server: net/http: TLS handshake timeout". I'm not sure when this happened as the cluster is a test one. I have tried reploying the node VMs (which seems fine) and attempting to upgrade the kubernetes version of the cluster (which failed with "Deployment failed. Correlation ID: xxxx. Operation failed with status: 200. Details: Resource state Failed"). I'm now stuck with a new set of VMs on 1.8.2 and one of the original VMs on 1.8.1 (based on VM tags). I'd rather not have to re-create the cluster.. Anyone know of anything I can try or can think of more diagnostic steps? Thanks for any help.
