-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot set a different default storage class #118
Comments
Of course, two default storageclasses causes a problem, in case that wasn't already obvious:
|
I've attempted to correct this a few times, but it appears that I cannot unset wut. |
what's the result of
it does not work? |
If you check the storage class after a minute or two, you should observe that it has returned to it's default state:
|
I just observed the exact same behavior. |
I just realized that the built-in storage class are all in |
We observe the same issue. Workaround is to change the file above. |
Let me just link the 2 issues (they are similar): kubernetes/kubernetes#53428 |
Closing due inactivity. Feel free to re-open if still an issue. |
Why is this closed? The proposed fix requires me to change config on the master, but with AKS my master is managed (away), so how could this work? I really like to specify my own default storage class, so I have a little more control. Currently I cannot. |
Hello, has anyone been able to get around this issue yet? I just attempted to change my default storage class also. Is there a way to dynamically assign storage using the default class? |
Hello, I'm also running into the same issue. Has anyone been able to change the default storage class from AKS? |
@andyzhangx and @jnoller , do we have any updates on this to change default storageclass from AKS? |
I also need a fix for this @andyzhangx pretty plz <3 |
is there any fix for this yet? I don't want azure-disk to be default in my cluster |
@andyzhangx @jnoller can you follow up on this? @palma21 FYI |
Just adding my thoughts here -- for plenty of use cases, including KubeFlow, it would be preferable to change the default storage class. For example in KubeFlow I would prefer using Azure Files (which I can mount as Read Write Many) instead of Azure Disks that can only be attached to a single node. |
This looks like a duplicate of #1075, but the good news is it's been added to the roadmap :) https://github.com/Azure/AKS/projects/1#card-34416796 |
Here is the way how to change the default storage class on AKS:
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.beta.kubernetes.io/is-default-class: "true"
labels:
addonmanager.kubernetes.io/mode: EnsureExists
kubernetes.io/cluster-service: "true"
name: default
parameters:
cachingmode: ReadOnly
kind: Managed
storageaccounttype: Premium_LRS
provisioner: kubernetes.io/azure-disk
reclaimPolicy: Delete
volumeBindingMode: Immediate
kubectl delete sc default && kubectl apply -f default.yaml
kubectl get sc default -o yaml By this way, you could change other built-in storage classes too. |
@andyzhangx I'm pretty sure this is exactly what I tried multiple times but it didn't work. If I do |
@berndverst what's your aks version? I tried on AKS 1.16 and 1.17 clusters, it works as expected. The key point is run following two command immediately:
|
@andyzhangx we are using v1.16.9 and it still does revert to initial state. Now I have two defaults. |
pls make sure you have prepared kubectl delete sc default && kubectl apply -f default.yaml And if you run |
Having tested it with 1.16, 1.17 and 1.18, I can confirm that any changes I make to the default sc get reverted within a minute. This is true for all storage classes provided by AKS. e.g. azurefile.
Note how in a matter of 1 minute, all my MountOptions customisations get reverted back. I encounter the exact same behaviour trying to modify the default sc, so have to end up creating a new sc and patching all my resources accordingly. |
I have the same issue. Changing the default storage class only lasts for a minute or so, reverting back to using the default storage class ending in two storage classes marked as default |
I finally solved this by switching to a nonterrible provider in GKE. Since
the switch we have opened 0 issue tickets compared to the weekly ones we
opened for AKS.
…On Mon, 14 Sep 2020, 06:48 danishsamad, ***@***.***> wrote:
I have the same issue. Changing the default storage class only lasts for a
minute or so, reverting back to using the default storage class ending in
two storage classes marked as default
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#118 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG6KEUJ4MWKTHKHPZAGLVJDSFWOCPANCNFSM4ELNFEOA>
.
|
Update: original storage class is set as |
With the fix roll out, here is the way how to change the default storage class on AKS:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.beta.kubernetes.io/is-default-class: "true"
labels:
addonmanager.kubernetes.io/mode: EnsureExists
kubernetes.io/cluster-service: "true"
name: default
parameters:
storageaccounttype: Premium_LRS
provisioner: disk.csi.azure.com
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
kubectl delete sc default && kubectl apply -f default.yaml
kubectl get sc default -o yaml You could also use same way to to change other built-in storage classes, make sure
# k get sc default -o yaml | grep addonmanager
addonmanager.kubernetes.io/mode: EnsureExists |
#48 was resolved, and believe the upgrade I performed a week or two ago from Kubernetes 1.8.1 to 1.8.2 caused the "fix" to come into effect.
Unfortunately I had already set
managed-premium
as theIsDefaultClass
, and now AKS has two default storage classes set:I don't know if this is a transitory issue when upgrading from 1.8.1 to 1.8.2, but any change which adjusts the storage clases should check that a default storage class has not already been set.
The text was updated successfully, but these errors were encountered: