Installing Dapr on a non-RBAC enabled AKS cluster results in post-install webhook failing to update dapr-webhook namespace
Extension name (the extension in question)
Dapr extension for AKS
Description of issue (in as much detail as possible)
I accidentally created an AKS cluster without Kubernetes RBAC enabled (using a Bicep template). I used the AKS Dapr extension to install the Dapr services as part of deploying the AKS cluster (again, via a Bicep template).
However, when trying to create a Dapr pub/sub subscription via YAML, I saw the following error when trying to deploy the YAML configuration files.
Error: UPGRADE FAILED: release dapr-trafficcontrol failed, and has been rolled back due to atomic being set: failed to create resource: conversion webhook for dapr.io/v1alpha1, Kind=Subscription failed: Post "https://dapr-webhook.replaceme.svc:443/convert?timeout=30s": service "dapr-webhook" not found
You will notice the dapr-webhook namespace is incorrect. It should be changed to the namespace I installed Dapr in (dapr-system).
If I describe the dapr-webhook service, you can see that the namespace did not get replaced via the post-install webhook.
kubectl describe CustomResourceDefinition subscriptions.dapr.io -n dapr-system
...
Service:
Name: dapr-webhook
Namespace: replaceme
Path: /convert
Port: 443
...
I would expect an error telling me that the AKS Dapr extension cannot be installed on an AKS cluster that does not have Kubernetes RBAC enabled when trying to install the AKS Dapr extension.
As I keep playing with this, I think it has more to do with me trying to install Dapr via Bicep. It seems to behave differently than using Azure CLI.
Here is a snippet of the Bicep file.
resource dapr 'Microsoft.KubernetesConfiguration/extensions@2022-03-01' = {
name: 'dapr'
scope: aks
properties: {
extensionType: 'microsoft.dapr'
scope: {
cluster: {
releaseNamespace: 'dapr-system'
}
}
autoUpgradeMinorVersion: true
}
}
Thank you for your feedback. This has been routed to the support team for assistance.
route to CXP team
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Azure/aks-pm.
Issue Details
Extension name (the extension in question)
Dapr extension for AKS
Description of issue (in as much detail as possible)
I accidentally created an AKS cluster without Kubernetes RBAC enabled (using a Bicep template). I used the AKS Dapr extension to install the Dapr services as part of deploying the AKS cluster (again, via a Bicep template).
However, when trying to create a Dapr pub/sub subscription via YAML, I saw the following error when trying to deploy the YAML configuration files.
Error: UPGRADE FAILED: release dapr-trafficcontrol failed, and has been rolled back due to atomic being set: failed to create resource: conversion webhook for dapr.io/v1alpha1, Kind=Subscription failed: Post "https://dapr-webhook.replaceme.svc:443/convert?timeout=30s": service "dapr-webhook" not found
You will notice the dapr-webhook namespace is incorrect. It should be changed to the namespace I installed Dapr in (dapr-system).
If I describe the dapr-webhook service, you can see that the namespace did not get replaced via the post-install webhook.
kubectl describe CustomResourceDefinition subscriptions.dapr.io -n dapr-system
...
Service:
Name: dapr-webhook
Namespace: replaceme
Path: /convert
Port: 443
...
I would expect an error telling me that the AKS Dapr extension cannot be installed on an AKS cluster that does not have Kubernetes RBAC enabled when trying to install the AKS Dapr extension.
| Author: | jordanbean-msft |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
Adding Service team to look into this.
I have exactly the same error message! I use a managed AKS with "Azure AD for authentication and Azure RBAC". Installation of the dapr extension went fine, but I get this error message if I try to create a dapr subscription via GitOps (Flux).
Any news on this ticket?
As a temporary workaround would it be enough to change the namespace in the CRD to the correct value?
Hi @jordanbean-msft and @tiehfood, checking in on this older issue. Is this still an active issue for you? If so, since it doesn't appear to be unique to the CLI, I suggest recreating the issue at https://github.com/Azure/AKS/issues.