New app deployment creates two replicas

[Expecho]

This issue is a: (mark with an x)

• [x] bug report -> please search issues before submitting
• [ ] documentation issue or request
• [ ] regression (a behavior that used to work and stopped in a new release)

Issue description

When a new revision is created the app consistently does not scale according to the scale settings. There are always 2 replicas running which causes problemens in my specific context since I want to have a mysql container running but it needs to be just 1.

Steps to reproduce

1. Pull an image from Docker Hub
2. Deploy an app with scale settings that define a minimum of 0 replicas and a maximum of 1

Expected behavior [What you expected to happen.]

With scale settings that define a minimum of 0 replicas and a maximum of 1, upon deployment there should be one replica running.

Actual behavior [What actually happened.]

With scale settings that define a minimum of 0 replicas and a maximum of 1, upon deployment there are alway 2 replicas started.

Screenshots

Additional context

I've tried setting the min/max replica count to 1/1 instead of 0/1 but the result is the same. It happens on multiple apps in the same environment.

[Berveglieri]

facing the same issue

[torosent]

There is a bug that will cause a revision to scale to two and after it's healthy it will scale it back to one. We are working on a fix for it. @Expecho , in your case, the revision is not getting into a healthy state because MySQL will not work with SMB file share and that will always keep the replica count as 2 as expected from Kubernetes.

[maskati]

@torosent experiencing the same. This is causing us issues since we are depending on there being only a single active instance of each named replica. Duplicate replicas (CONTAINER_APP_REPLICA_NAME) are performing concurrent name based registrations and conflicting with each other.

[maskati]

@torosent is there any way to differentiate replica instances from within the running container? Currently it seems you can differentiate these by different containerId values of ReplicaContainer (the container id is prefixed by containerd://) or by different ContainerId_s in ContainerAppConsoleLogs logs. Would it be possible to add an additional environment variable CONTAINER_APP_CONTAINER_ID or similar that would correspond to the replica container identifier?

[maskati]

We are working on a fix for it.

@torosent do you have an ETA? I am still seeing this in West Europe.

[viktorz]

I am experience same issue - getting 2 replicas even though I am deploying using:

az containerapp update -g $rgName -n $appName `
 --image "$($image):$tag" `
 --cpu $cpu --memory $mem --min-replicas 1 --max-replicas 1 `
 --revision-suffix "$newRevName"

In my case the second replica will never start as I am explicitly assigning ALL the CPU and Memory resources of the Container App Environment as I want exactly 1 instance running there and utilizing all the resources. As result the revision is marked as Degraded, all while my requested 1 replica is running fine. Doubling the Container App Environment resources is not cost-effective work-around so I can get the second unwanted replica to run for a few seconds, If anyone knows a way to kill a specific replica via AZ CLI or some other way I will appreciate sharing it.

[frasermclean]

This is causing issues for me too. Running more than a single instance of a container is causing issues and unnecessary costs. Any update on this?

[johschmidt42]

Came across this issue as well. Does setting up probes help?