Welcome to aad-pod-identity Discussions!

[chewong]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[saurabhvagrawal]

Hi Team,

We are using aadpodidentity in production clusters in our organization. Currently, we are devising its upgrade plan in our clusters. Just want to understand if we have to upgrade everytime a latest GA version is available since it is still evolving or we have to go with n-2 version which has comparatively lots of patches or fixes. What is the best practice for upgrade? Appreciate if someone can answer that.

[aramase]

For minor releases, typically it'll contain bug fixes and minor improvements. It's recommended to use the latest when available. You can view the changes in our changelog https://azure.github.io/aad-pod-identity/changelog/ to decide if the new minor version available contains any critical bug fixes that you want to avoid.

For major releases, we publish any breaking changes if available. These releases will contain new features and the recommendation is to upgrade to it for trying those out.

[saurabhvagrawal]

Thank you for this insightful comment. Much appreciated.

QQ: Is there any release cycle available for it and how can I subscribe myself and my team for notifications whenever we get any new release updates.

[dmakeienko]

Hi team,
we are using aadpodidentity in multiple clusters in production. However, we've started to use shared aks clusters where different projects separated by namespaces. Therefore, a question that bothers us, what is the best practice for this case? Can we deploy a separate pod identity per project? Or should we use one pod identity for all projects in clusters?

[chewong]

Hi, namespace is the security boundary so the best practice would be using Namespace mode (https://azure.github.io/aad-pod-identity/docs/configure/match_pods_in_namespace/) to prevent pods from other namespaces from accessing the identities.

[dmakeienko]

Thank you for your response. Let me clarify please, should only one instance of aad pod identity be deployed in a separate namespace in Namespaced mode or we can deploy multiple aad pod identities to different namespaces? (I'm talking about the nmi/mic deployment etc)

[chewong]

Only one deployment per cluster is needed

[dmakeienko]

thank you for your response!

[sasound]

Hi Team

We are running AAD pods on our AKS cluster. The current version of AAD Helm version is 2.0.1 and we are planning an upgrade.
Which is the stable version of AAD that we can upgrade to ?

Our AKS cluster was recently updated to use "Managed Identities" and we ended up with #1133 issue which critically broke our data ingestion into KUSTO db for 48 hrs.

So want to ensure we don't to get to the correct AAD version without any hassles.

Thanks
Saai

[chewong]

The latest app version is 1.8.2 and the latest helm chart version is 4.1.3 - https://github.com/Azure/aad-pod-identity/blob/master/charts/aad-pod-identity/README.md#aad-pod-identity

[sasound]

Can you recommend us the stable version to which we need to upgrade to ?

Furthermore, can we jump from 2.0.1 ==> 4.1.3 ? or is it 2.0.1 ==> 3.X ==> 4.1.3 ??

thanks

[chewong]

Upgrading from 2.0.1 to 4.1.3 should be fine as long as you address the breaking changes in https://github.com/Azure/aad-pod-identity/blob/master/charts/aad-pod-identity/README.md#upgrading-to-a-new-major-chart-version and https://azure.github.io/aad-pod-identity/changelog/#breaking-change

[gkrobo]

Hi there

Require some advice please.

We have non-helm chart install of AAD-pod-identity in our production clusters on Kubernetes v1.21 in Namespaced mode.

AAD-pod-identity nmi/mic version: 1.6.2

The CRDs installed with v1.6.2 have deprecated k8s api > apiextensions.k8s.io/v1beta1 which is not compatible with k8s v1.22 upgrade and we need to get AAD-pod-identity updated first AND using helm chart instead.

Questions:

1. What is the best method for upgrade from non-helm to helm chart version with least impact to the running production pods that are currently binding to Azure identities with the old non-helm setup?

2. Is it possible to run 2 different versions (non-helm chart and helm chart version) of aad-pod-identity (nmi/mic) in the same k8s cluster in different namespaces e.g. ns1: aad-pod-identity and ns2: aad-pod-identity-2 ?
   --- Just not sure how the CRDs would work with this as the helm chart would need to install and overwrite apiextensions.k8s.io/v1beta1 with the new apiextensions.k8s.io/v1 version

   The idea behind this idea is phase over the pods using a different aadpodidbinding label that points to the new aad-pod-identity helm chart steup.
   Instead of a big bang approach where we have hundreds of pods consuming aadpodidentities

Steps ive tried in our Test k8s cluster: (uninstall / re-install but equates to downtime during this period)

1. Prepared helm chart and values consisting of our azureIdentities and binding selector config in required format.
2. Uninstall non-helm AAD-pod-identity nmi/mic version: 1.6.2 and all associated components removed
   a. During this stage we had pods that are consuming the “aadpodidbinding” where erroring as could not consume azureIdentities (to be expected due to uninstall)
3. Installed the helm chart and required values
   a. Once deployed, the pods stopped erroring and consumed azureIdentities again

Advice welcomed on best approach with least to no downtime , if possible in this scenario?
Thank you

[gkrobo]

created a new request instead
#1289