Админим с Буквой
5.52K subscribers
303 photos
8 videos
59 files
1.16K links
Канал о системном администрировании, DevOps и немного Инфобеза.

По всем вопросам обращаться к @bykva. Рекламу не размещаю.
Download Telegram
nginx ingress controller permanent redirect

annotation: nginx.ingress.kubernetes.io/permanent-redirect: https://company.com

В чем смысл писать это если есть дока? А смысл такой, что это не будет работать пока ты полностью не укажешь путь до бэкэнда. Промаялся с этим довольно долго((

spec:
rules:
- host: company.com
http:
paths:
- backend:
serviceName: company.ru
servicePort: http

#ingress #kubernetes
Сортировка событий в неймспейсе куба

kubectl -n namespace get events --sort-by='{.lastTimestamp}'


#kubernetes
Vsphere persistent volume provisioning in k8s

Эй, буква! - спросите вы, чем ты там занимаешься последнее время что ничего интересного почитать не даешь?

Ну, в кратце новости, я недавно сменил работу и несколько недель привыкал к новому стеку - применял привычные мне инфраструктурные решения на кластер vmware. Самое интересное в этой истории - это то как я настраивал pv через нативный cloud provider. Все шаги целиком я не буду описывать, потому как есть несколько полезных статей где это уже сделано:
тыц: https://blog.mimacom.com/ocp-persistent-storage/
и тыц: https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html

после того как вы все настроите по статье, нужно будет сделать еще несколько моментов:

1) поддержка disk.UUID для виртуальных машин с vmware:

terraform:
resource "vsphere_virtual_machine" "vm" {
enable_disk_uuid = "true"
...

или govc:
govc vm.change -json -vm.ipath="/path/to/VM" -e="disk.enableUUID=1"

Операция потребует перезагрузки после применения. Если этого не сделать, то диск будет присоединяться к виртуалке, но куб не сможет дальше примонтировать его к контейнеру.

2) если вы делали по статье выше, то нужна будет небольшая доработка, выполните пункт из документации:
https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/existing.html#on-the-kubernetes-workers

Что говоришь мальчик? почему бы сразу по ней не сделать? потому что во-первых она мне не в первую очередь попалась на глаза, во-вторых там идет какой-то ручник на мастере, вместо того чтобы сразу проинициализоровать, во-вторых и сам способ изменения systemd мне нрвится меньше чем правка /etc/default, поэтому в моем случае вместо того чтобы править systemd я добавил строчку KUBELET_EXTRA_ARGS="--cloud-provider=vsphere" в файл /etc/default/kubelet. Это логичнее и проще в автоматизации

3) выставляем корректные поля provider ID:
https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/existing.html#update-all-node-providerid-fields

и далее по статье можно шикарным способом прибить нужные контейнеры (контроллер, апи, перезапустить кублет). Если кластер не жалко проще всего сделать ребут или systemctl restart docker kubelet

4) Проверяем что все работает: https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/persistent-vols-claims.html
Здесь я привел пример со статикой, ибо с динамикой у меня с наскока сделать не получилось. Да, если у вас в организации права на кластер выдают гранулировано, то нужно попросить создать на некотором datastore папку и выдать на нее права Low level operations. Я видел статью где в миллион и одну картинку описано как настраивать все это дело (абсолютно не читабельно, поэтому пропустил, но сохранил в загашничек потому что очень информативно и вдруг пригодится). Так вот в ней на 100500 скриншотах описаны какие права надо выдать. Может вам в этой ситуации пригодится, мне повезло решить с нашими it-шниками вопрос и так.

5) если вы используете terraform

выставить при создании виртуальной машины такую директиву:
  lifecycle {
ignore_changes = [
disk,]
}

это на самом деле полуспасение. Оно решает задачу того что терраформ рвется поотсодениять все наши подключаемые тома (ведь для него это изменение инфраструктуры, которое не описано), с другой стороны игнорируя все изменения в дисках мы лишаемся возможности изменять их через terraform. Пока годного решения как и рыбку съесть и терраформом не подавиться я не нашел (но я мало искал).

#terraform #vsphere #kubernetes
terraform create dockreg secret in k8s

resource "kubernetes_secret" "company-dkr-key" {
metadata {
name = "company-dkr-key"
namespace = "${kubernetes_namespace.company.metadata.0.name}"
}

data = {
".dockerconfigjson" = "{\"auths\":{\"${var.company-dkr-url}\":{\"username\":\"${var.company-dkr-user}\",\"password\":\"${var.company-dkr-password}\",\"email\":\"email\",\"auth\":\"${base64encode(format("%s:%s", var.company-dkr-user, var.company-dkr-password))}\"}}}"

## OR u can also do this from file
# ".dockercfg" = "${file("${path.module}/docker.cfg")}"

}

type = "kubernetes.io/dockercfg"
}

#terraform #docker #kubernetes
yaml to terraform tf converter

сегодня открыл для себя прикольный репос, в котором автор написал конвертер для yaml-ресурсов куба в те же самые ресурсы, но для терраформа. Оказалось очень полезной штукой.

З.Ы. с CRD оно работать не умеет к сожалению

https://github.com/sl1pm4t/k2tf

#terraform #kubernetes
как проверить что у вас плохо настроена безопасность в k8s в gcp


curl -H 'Metadata-Flavor: Google' 169.254.169.254/computeMetadata/v1/instance/service-accounts/<SERVICE_ACCOUNT_EMAIL>/token

выполнять из любого пода внутри кластера.

#kubernetes #gcp
k8s resources capacity

kubectl get node -o json | jq -j  '.items[]|.metadata.name + ":" + "\n\tpod capacity: " + .status.capacity.pods + "\n\tcpu capacity: " + .status.capacity.cpu + "\n\tmemory capacity: " + .status.capacity.memory + "\n"'


result:

...
kubernetes-node-0:
pod capacity: 110
cpu capacity: 6
memory capacity: 12273236Ki
...


#kubernetes
как сбросить пароль на postgresql в запущенном docker контейнере без перезапуска

Рубрика "костылим с буквой"

ОСТОРОЖНО прочитанное далее может вызвать кровотечение из глаз и непреодолимое желание расшибить себе лоб рукой.

вы были предупреждены.

Раскатывал я тут хелм сентри... Дано: не работающий Job, который использует пароль из секрета, и криво написанный авторами чарт, в котором слетает пароль пользователя в postgres. Задача - установить в контенере на лету нужный пароль пользователя.



# получаем пароль который должен быть выставлен на постгре
kubectl -n sentry get secret sentry-sentry-postgresql -o yaml | awk '$1=/postgresql-password:/ {print $2}' | base64 -d; echo

# получаем ноду на которой крутится постгре и ssh-шимся на нее
kubectl -n sentry get po -o wide | awk '$1~/.*postgr.*/ {print $7}'

# получаем id контейнера и логинимся туда под рутом
docker ps | grep postgr | grep entry | awk '{print $1}'
docker exec -ti -u0 <container_id> bash

# узнаем пользователя под которым запущен постгре
grep Uid /proc/1/task/1/status

# разрешаем логиниться из-под локалхоста
sed -ibak 's/^\([^#]*\)md5/\1trust/g' /opt/bitnami/postgresql/conf/

# добавляем пользователя в систему и переходим в него
useradd postgres -u 1001
su postgres

# выставляем переменные окружения и релоадим сервис
export PGDATA=/bitnami/postgresql/data
/opt/bitnami/postgresql/bin/pg_ctl reload

# логинимся в postgres и выставляем пароль
psql -U postgres
ALTER USER postgres WITH PASSWORD 'XXX';

возвращаем назад изменения или перестартуем контейнер.


#рукиизжопы #костыли #postgresql #docker #sentry #kubernetes