Hey folks of the Azure Cloud,
I'm trying to deploy an app into my AKS Cluster with persistent Storage in "Storage Account".
I created a PVC in K8s YAML using the "azureblob-nfs-premium" storage class.
Now I want to give the newly created Storage Account a specified name. But I really don't know how to do that.
Any tips or ideas?
My (Helm) K8s PVC YAML File:
{{- if .Values.persistence.enabled }}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: {{ include "project.fullname" . }}
labels:
{{- include "project.labels" . | nindent 4 }}
spec:
accessModes:
- ReadWriteOnce
storageClassName: {{ .Values.persistence.storageClass }}
resources:
requests:
storage: {{ .Values.persistence.size }}
{{- end }}
As the storage account is dynamically provisioned you can't set a specific name for the Azure resource.
You can add tags to the resource by using annotations:
apiVersion: storage.k8s.io/v1
...
parameters:
...
tags: costcenter=3333,team=beta
If you want to have full control you can switch to static azure resources, but those work different.
Related
For AKS to use a azure disk for persistent storage, we can define a persistentVolumeClaim as follows -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: azure-managed-disk
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 5Gi
Is it possible to use an azure disk from another tenant B for use as persistentVolume for an AKS in tenant A?
I don't think that this is possible.
I guess you will have to migrate your disks into the Subscription AKS is running in. You can then use the existing disk as described here.
We have an AKS cluster set up with a multiple availability zone node pool. Using the default storage class, if a Pod needs to move to another node and the only available node is in a different region, the Pod can't start up because the storage is stuck in the original region. Do any of the other built-in storage classes support the relocation of workloads across multi-zone pools?
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: data
namespace: $NAMESPACE
labels:
service: db
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 4Gi
Yes you can use below configurations depending on your need.
Example StorageClass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile
provisioner: kubernetes.io/azure-file
parameters:
skuName: Standard_ZRS
location: eastus
storageAccount: azure_storage_account_name
allowedTopologies:
- matchLabelExpressions:
- key: failure-domain.beta.kubernetes.io/zone
values:
- eastus2-1
- eastus2-2
- eastus2-3
According to that following skuName are available in Azure —
Standard_LRS — standard locally redundant storage (LRS)
Standard_GRS — standard geo-redundant storage (GRS)
Standard_ZRS — standard zone redundant storage (ZRS)
Standard_RAGRS — standard read-access geo-redundant storage (RA-GRS)
Premium_LRS — premium locally redundant storage (LRS)
Premium_ZRS — premium zone redundant storage (GRS)
References: K8s Allowed Topologies, AKS - Availability Zones, AKS - StorageClasses
Previously I was using the standard way of setting the PV on static azure files, i.e. create storage account and fileshare, create secret using the account name and secret of the storage account, then create the PV as below:
apiVersion: v1
kind: PersistentVolume
metadata:
name: elastic-storage
labels:
usage: elastic-storage
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=1000
- gid=1000
- mfsymlinks
- nobrl
persistentVolumeReclaimPolicy: Retain
azureFile:
secretName: azure-secret
shareName: elasticsearchfile2
readOnly: false
I am now wondering whether I can use service principal instead of the azure secret using storage account name and key to access the azure files.
It's simple to understand. Azure supports the RBAC (role-based access) feature. And it can be used in the storage account. Just like two different users can read the same data in the database because they have enough permission the read. So if the service principal has enough permission for the storage account, then it also can access the storage account.
I have created one Azure Kubernetes cluster with RBAC enabled.
So my thinking is if any pod want to access any resource in cluster, it should be associated with service account and service account should have a specific role assigned to access resource.
But in my case I am able to access resource like list pod , list namespace from pod which is associated with a service account that does not have any role assigned.
Please help me know if my understanding is wrong about RBAC or I am doing something wrong here !!
Your understanding is right, i'm not exactly sure about permissions granted to default service account, but if you create your own role and assign it to the service account you can control permissions. sample:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: myserviceaccount
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: orleans-cluster
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: myserviceaccount
namespace: mynamespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: orleans-cluster
rules:
- apiGroups:
- orleans.dot.net
resources:
- clusterversions
- silos
verbs:
- '*'
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: myserviceccount
namespace: mynamespace
if you assign myserviceaccount to the pod it will only allow the pod to do whatever is defined in the role. so you need to create a role and a service account and use rolebinding (or clusterrolebinding for cluster wide permissions) to the service account.
anyone know how i can see my aks persisted volume (azurefile) data in Azure Storage Explorer or in the portal?
persisted volume is working but i can't see the raw files somehow..
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azurefile
provisioner: kubernetes.io/azure-file
parameters:
storageAccount: trstorage
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql
spec:
capacity:
storage: 1Gi
hostPath:
path: "/data/mysql"
accessModes:
- ReadWriteMany
storageClassName: azurefile
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql
spec:
accessModes:
- ReadWriteMany
storageClassName: azurefile
resources:
requests:
storage: 500Mi
p.s. i know it's a bad idea to use azurefile for a database so ignore that for now.
when i look in the storage account i don't see any files, that's what i'm not understanding..
For your issue, I understand that you did the persisted volume in Azure Storage for your mysql in Azure Kubenets.
First, if your mount path is right and the path that mysql will automatically create files itself. You will see files in Azure Storage Explorer or in the portal with File Share.
Second, you can check if Azure Storage File Share was mounted correctly to the mount point. You can use the command kubectl describe pod podName to check it. The resulting screenshot will like this.
Or check it in the browser with the command az aks browse --resource-group resourceGroupName --name AKSClusterName. And the resulting screenshot will like this.
Third, you can check the path with connecting to the AKS node. For connecting, you can follow the document SSH into Azure Kubernetes Service (AKS) cluster nodes.
I did the test and the resulting screenshots here:
See persisted Volume in the portal.
See persisted Volume in the Microsoft Azure Storage Explorer.
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=1000
- gid=1000
parameters:
skuName: Standard_LRS
storageAccount: gdkstore
note:
storageAccount: is what's missing from MS docs currently
change gdkstore to your own storage account name in the correct resource group