k
Ещё PV между разными csi мигрировал, это тоже весёлое занятие
Size: a a a
2020 March 11
ЕО
Ещё PV между разными csi мигрировал, это тоже весёлое занятие
Между какими?
k
Между какими?
С linstor flexvolume на linstor csi
AY
Всем привет!
Кто работал с GKE, подскажите, пожалуйста. Не хочет автоматически скейлиться пул нод при нехватке CPU или оперативки. На каждый под установлены requests ресурсы.
Судя по этой фразе из документашки "If your Pods have requested too few resources (or haven't changed the defaults, which might be insufficient) and your nodes are experiencing shortages, cluster autoscaler does not correct the situation. You can help ensure cluster autoscaler works as accurately as possible by making explicit resource requests for all of your workloads.", пул нод масштабируется именно в зависимости от requests ресурсов.
Request ресурсы выставил практически впритык работы каждого пода. Но когда HPA масштабирует поды при нагрузке, то некоторые поды просто пишет о недостаточном количестве CPU, но пул нод остаётся прежним.
Для примера, запрашиваю 25m из одного ядра (у которого лимит 940m и у которого занято уже 925m) и поды просто остаются в pending. Разве scheduler не должен скейлить пул нод кластера?
Кто работал с GKE, подскажите, пожалуйста. Не хочет автоматически скейлиться пул нод при нехватке CPU или оперативки. На каждый под установлены requests ресурсы.
Судя по этой фразе из документашки "If your Pods have requested too few resources (or haven't changed the defaults, which might be insufficient) and your nodes are experiencing shortages, cluster autoscaler does not correct the situation. You can help ensure cluster autoscaler works as accurately as possible by making explicit resource requests for all of your workloads.", пул нод масштабируется именно в зависимости от requests ресурсов.
Request ресурсы выставил практически впритык работы каждого пода. Но когда HPA масштабирует поды при нагрузке, то некоторые поды просто пишет о недостаточном количестве CPU, но пул нод остаётся прежним.
Для примера, запрашиваю 25m из одного ядра (у которого лимит 940m и у которого занято уже 925m) и поды просто остаются в pending. Разве scheduler не должен скейлить пул нод кластера?
k
Immutable поля мутировал)
ЕО
Всем привет!
Кто работал с GKE, подскажите, пожалуйста. Не хочет автоматически скейлиться пул нод при нехватке CPU или оперативки. На каждый под установлены requests ресурсы.
Судя по этой фразе из документашки "If your Pods have requested too few resources (or haven't changed the defaults, which might be insufficient) and your nodes are experiencing shortages, cluster autoscaler does not correct the situation. You can help ensure cluster autoscaler works as accurately as possible by making explicit resource requests for all of your workloads.", пул нод масштабируется именно в зависимости от requests ресурсов.
Request ресурсы выставил практически впритык работы каждого пода. Но когда HPA масштабирует поды при нагрузке, то некоторые поды просто пишет о недостаточном количестве CPU, но пул нод остаётся прежним.
Для примера, запрашиваю 25m из одного ядра (у которого лимит 940m и у которого занято уже 925m) и поды просто остаются в pending. Разве scheduler не должен скейлить пул нод кластера?
Кто работал с GKE, подскажите, пожалуйста. Не хочет автоматически скейлиться пул нод при нехватке CPU или оперативки. На каждый под установлены requests ресурсы.
Судя по этой фразе из документашки "If your Pods have requested too few resources (or haven't changed the defaults, which might be insufficient) and your nodes are experiencing shortages, cluster autoscaler does not correct the situation. You can help ensure cluster autoscaler works as accurately as possible by making explicit resource requests for all of your workloads.", пул нод масштабируется именно в зависимости от requests ресурсов.
Request ресурсы выставил практически впритык работы каждого пода. Но когда HPA масштабирует поды при нагрузке, то некоторые поды просто пишет о недостаточном количестве CPU, но пул нод остаётся прежним.
Для примера, запрашиваю 25m из одного ядра (у которого лимит 940m и у которого занято уже 925m) и поды просто остаются в pending. Разве scheduler не должен скейлить пул нод кластера?
А вы создавали кластер с автоскейлингом? Не уперлись в max?
AY
А вы создавали кластер с автоскейлингом? Не уперлись в max?
Конечно. Пул указал от 2 до 5 нод. Сейчас работают впритык ресурсов только две ноды
AY
HPA масштабирует поды, а кластер не масштабирует пул нод. Все условия я, вроде как, для GKE выполнил
DS
Всем привет!
Кто работал с GKE, подскажите, пожалуйста. Не хочет автоматически скейлиться пул нод при нехватке CPU или оперативки. На каждый под установлены requests ресурсы.
Судя по этой фразе из документашки "If your Pods have requested too few resources (or haven't changed the defaults, which might be insufficient) and your nodes are experiencing shortages, cluster autoscaler does not correct the situation. You can help ensure cluster autoscaler works as accurately as possible by making explicit resource requests for all of your workloads.", пул нод масштабируется именно в зависимости от requests ресурсов.
Request ресурсы выставил практически впритык работы каждого пода. Но когда HPA масштабирует поды при нагрузке, то некоторые поды просто пишет о недостаточном количестве CPU, но пул нод остаётся прежним.
Для примера, запрашиваю 25m из одного ядра (у которого лимит 940m и у которого занято уже 925m) и поды просто остаются в pending. Разве scheduler не должен скейлить пул нод кластера?
Кто работал с GKE, подскажите, пожалуйста. Не хочет автоматически скейлиться пул нод при нехватке CPU или оперативки. На каждый под установлены requests ресурсы.
Судя по этой фразе из документашки "If your Pods have requested too few resources (or haven't changed the defaults, which might be insufficient) and your nodes are experiencing shortages, cluster autoscaler does not correct the situation. You can help ensure cluster autoscaler works as accurately as possible by making explicit resource requests for all of your workloads.", пул нод масштабируется именно в зависимости от requests ресурсов.
Request ресурсы выставил практически впритык работы каждого пода. Но когда HPA масштабирует поды при нагрузке, то некоторые поды просто пишет о недостаточном количестве CPU, но пул нод остаётся прежним.
Для примера, запрашиваю 25m из одного ядра (у которого лимит 940m и у которого занято уже 925m) и поды просто остаются в pending. Разве scheduler не должен скейлить пул нод кластера?
а че пишет в евентах этих подов (которые в Pending). Обычно autoscaler туда сообщения пишет.
Напирмер он может решить, что после скейла вверх, на эту ноду под не сможет заехать из-за афинити или selector.
Если логи автоскейлера есть, то их тоже можно глянуть
Напирмер он может решить, что после скейла вверх, на эту ноду под не сможет заехать из-за афинити или selector.
Если логи автоскейлера есть, то их тоже можно глянуть
AY
а че пишет в евентах этих подов (которые в Pending). Обычно autoscaler туда сообщения пишет.
Напирмер он может решить, что после скейла вверх, на эту ноду под не сможет заехать из-за афинити или selector.
Если логи автоскейлера есть, то их тоже можно глянуть
Напирмер он может решить, что после скейла вверх, на эту ноду под не сможет заехать из-за афинити или selector.
Если логи автоскейлера есть, то их тоже можно глянуть
Смотрел только логи подов. Логи автоскейлера из GKE не знаю как вытянуть...
AY
Не сказал бы, что это информативно
DS
у тебя точно что-то мешает. affinity точно нет? Дай kubectl get pod pod_name -o yaml этого пода
AY
у тебя точно что-то мешает. affinity точно нет? Дай kubectl get pod pod_name -o yaml этого пода
Точно. Сейчас, минутку
AY
у тебя точно что-то мешает. affinity точно нет? Дай kubectl get pod pod_name -o yaml этого пода
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-03-11T16:41:03Z"
generateName: api-gateway-576cb4b448-
labels:
app.kubernetes.io/instance: api-gateway
app.kubernetes.io/name: api-gateway
pod-template-hash: 576cb4b448
name: api-gateway-576cb4b448-45cc7
namespace: develop
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: api-gateway-576cb4b448
uid: af3db694-4222-4861-9eb5-61987f97b6a1
resourceVersion: "13624805"
selfLink: /api/v1/namespaces/develop/pods/api-gateway-576cb4b448-45cc7
uid: 30fc729c-c2f9-419d-b269-35c8c842d5c2
spec:
containers:
- image: myImageRepo
imagePullPolicy: IfNotPresent
name: api-gateway
resources:
requests:
cpu: 25m
memory: 150Mi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-thpjl
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
volumes:
- name: default-token-thpjl
secret:
defaultMode: 420
secretName: default-token-thpjl
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2020-03-11T16:41:04Z"
message: '0/2 nodes are available: 1 Insufficient cpu, 1 Insufficient memory.'
reason: Unschedulable
status: "False"
type: PodScheduled
phase: Pending
qosClass: Burstable
DS
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-03-11T16:41:03Z"
generateName: api-gateway-576cb4b448-
labels:
app.kubernetes.io/instance: api-gateway
app.kubernetes.io/name: api-gateway
pod-template-hash: 576cb4b448
name: api-gateway-576cb4b448-45cc7
namespace: develop
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: api-gateway-576cb4b448
uid: af3db694-4222-4861-9eb5-61987f97b6a1
resourceVersion: "13624805"
selfLink: /api/v1/namespaces/develop/pods/api-gateway-576cb4b448-45cc7
uid: 30fc729c-c2f9-419d-b269-35c8c842d5c2
spec:
containers:
- image: myImageRepo
imagePullPolicy: IfNotPresent
name: api-gateway
resources:
requests:
cpu: 25m
memory: 150Mi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-thpjl
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
volumes:
- name: default-token-thpjl
secret:
defaultMode: 420
secretName: default-token-thpjl
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2020-03-11T16:41:04Z"
message: '0/2 nodes are available: 1 Insufficient cpu, 1 Insufficient memory.'
reason: Unschedulable
status: "False"
type: PodScheduled
phase: Pending
qosClass: Burstable
любопытно
AY
любопытно
Мне тоже)
Вот только непонятно ничего
Вот только непонятно ничего
DS
Мне тоже)
Вот только непонятно ничего
Вот только непонятно ничего
в группе точно не максимальное количество нод?
AY
в группе точно не максимальное количество нод?
AY
в группе точно не максимальное количество нод?
Однозначно
DS
Однозначно
gke давно не щупал, там сам cluster autoscaler есть как отдельное приложение, логи которого можно посмотреть? Или там он совсем огорожен, как весь остальной control plane?