Я бы не рекомендовал этот подход, но самым близким к выполнению того, что вы хотите, является использование набора состояний и использование имени модуля в качестве индекса.
При развертывании набора с состоянием модули будутбыть названным в честь их имени набора состояний в следующем примере:
apiVersion: v1
kind: Service
metadata:
name: kuard
labels:
app: kuard
spec:
type: NodePort
ports:
- port: 8080
name: web
selector:
app: kuard
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: kuard
spec:
serviceName: "kuard"
replicas: 3
selector:
matchLabels:
app: kuard
template:
metadata:
labels:
app: kuard
spec:
containers:
- name: kuard
image: gcr.io/kuar-demo/kuard-amd64:1
ports:
- containerPort: 8080
name: web
Модули, созданные набором состояний, будут иметь имена:
kuard-0
kuard-1
kuard-2
Таким образом, вы можете либо назвать имя состояния-установите в соответствии с классами, то есть: class-name
, и созданный модуль будет class-name-0
, и вы можете заменить _
на -
.Или просто удалите имя, чтобы получить индекс в конце.
Чтобы получить имя, просто прочитайте переменную окружения HOSTNAME
Это именование согласованно, поэтому вы всегда можете быть уверены, чтоиметь 0, 1, 2, 3 после имени.И если 2
выйдет из строя, он будет воссоздан.
Как я уже сказал, я бы не рекомендовал этот подход, потому что вы привязываете инфраструктуру к своему коду, а также не можете масштабировать (если нужно), потому чтокаждый сервис уникален, и добавление новых экземпляров получит новые идентификаторы.
Лучшим подходом будет использование одного развертывания для каждого класса и передача правильных значений в качестве переменных среды.