The name of the SA removed is doi-servicealarm-hazelcast-cluster in the doi-servicealarm.deployment.yml manifest.
Anyone knows why the service alarm deployment needs a special service account?
Also… When it comes to SAs, since each namespace can have an SA with the same name as another sa in another namespace… (such as, there’s a default SA in every namespace), when referencing ‘provisioning’ in the manifests, how does it know which provisioning SA to use? i.e.… the installer creates a provisioning SA in the dxi (aiops for capOne) namespace… but CapOne already makes use of a ‘provisioning’ SA in their cluster… so I’m assuming they have two of them, Correct?
As for the ‘provisioning’ SA that the installer makes, it’s only used in two deployment ymls… The acc-deployment.cs.yml yaml and the acc-deployment.repository.yml yaml.
Release : 20.2
Component : CA DOI AO PLATFORM COMPONENTS
The service alarm is internally using the embedded Hazelcast. To support the horizontal scale, it needs to provide the automatic Hazelcast member discovery in the Kubernetes/OSE environment so that embedded Hazelcast members discover each other automatically when the new instance of service alarm gets to scale. Hazelcast Kubernetes Discovery requires creating a service to PODs where Hazelcast is running and that is the reason doi-servicealarm-hazelcast-cluster service getting create to make rest API's call to Kubernetes Master in order to discover IPs of PODs (with Hazelcast members).
Hazelcast internal API’s require setting up RoleBinding (to allow access to Kubernetes API) and that is reason it requires the Service account with the ClusterRole.