DS
Ну когда я читаю отказ - понимаю отказ железки.
железки падают, виртуалки тоже падают и не только по причине падения гипервизора. Разное бывает 🤷♂
Size: a a a
2020 July 04
GG
железки падают, виртуалки тоже падают и не только по причине падения гипервизора. Разное бывает 🤷♂
Поэтому давайте строить своего облачного провайдера поверх хетцнера ?
DS
Поэтому давайте строить своего облачного провайдера поверх хетцнера ?
DS
Поэтому давайте строить своего облачного провайдера поверх хетцнера ?
я просто согласился с человеком, что переналивать железки в hetzner это к сожалению боль(ручное действие )
GG
я просто согласился с человеком, что переналивать железки в hetzner это к сожалению боль(ручное действие )
Не так часто это нужно ) иначе тебе не хетцнер нужен, а maas какой-то
NG
Вот я к тому и вёл, что это разовое дело. А если упадёт то жопа и так и так)
DS
Вот я к тому и вёл, что это разовое дело. А если упадёт то жопа и так и так)
+, согласен
DS
Хорошо, пока-что попробую на баре метале посидеть
вобщем тебе никто не советует переизобретать openstack и натягивать на hetzner. Натягивать opennebula, openstack, proxmox, ovirt (и т. д.) на железки hetzner я бы тоже не советовал (IMHO) .
Нужны виртуалки - возьми hetzner cloud.
Нужны виртуалки - возьми hetzner cloud.
N
Подскажите. Вы какие PodSecurityPolicy используете на прод ?
NG
Nikolay
Подскажите. Вы какие PodSecurityPolicy используете на прод ?
Какие подходят.
NG
Дефолтных без привилегий иногда недостаточно.
NG
Надо делать под себя, разрешать то, что действительно нужно. И вперёд.
NG
Например вот:
---
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
spec:
allowPrivilegeEscalation: false
fsGroup:
ranges:
- max: 65535
min: 1
rule: MustRunAs
forbiddenSysctls:
- '*'
hostNetwork: false
hostIPC: false
hostPID: false
privileged: false
readOnlyRootFilesystem: false
requiredDropCapabilities:
- ALL
runAsUser:
rule: MustRunAsNonRoot
seLinux:
rule: RunAsAny
supplementalGroups:
ranges:
- max: 65535
min: 1
rule: MustRunAs
volumes:
- configMap
- emptyDir
- projected
- secret
- downwardAPI
- persistentVolumeClaimGG
Например вот:
---
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
spec:
allowPrivilegeEscalation: false
fsGroup:
ranges:
- max: 65535
min: 1
rule: MustRunAs
forbiddenSysctls:
- '*'
hostNetwork: false
hostIPC: false
hostPID: false
privileged: false
readOnlyRootFilesystem: false
requiredDropCapabilities:
- ALL
runAsUser:
rule: MustRunAsNonRoot
seLinux:
rule: RunAsAny
supplementalGroups:
ranges:
- max: 65535
min: 1
rule: MustRunAs
volumes:
- configMap
- emptyDir
- projected
- secret
- downwardAPI
- persistentVolumeClaim👍
AC
У меня на ваниле 200
А можно ли увеличить количество уже на существующем кластере?
NG
А можно ли увеличить количество уже на существующем кластере?
Конечно
NG
—max-pods кубелета
АП
А можно ли увеличить количество уже на существующем кластере?
Да, но надо быть осторожным, если у вас, например, flannel
GG
Осторожность в любом случае не помешает 🤷♂
VP
Так kvm в любом случае будет в подсети. Тут дело не в типе виртуализации, а в построении сети так, чтоб ноды на серых и белых адресах спокойно себе дружили
если хетзнер - там есть proxmox, ноды легко связать в сеть через vswitch ихний и подымать виртуалки с чем угодно (в том числе с кубером), главное помнить про MTU 1492 ( можно по dhcp отдавать)