Differences

This shows you the differences between two versions of the page.

--- devops:kubernetes [2021/02/17 06:41] – [Настройка client в keycloak] admin
+++ devops:kubernetes [2021/04/21 12:50] – [Отмена удаления PersistentVolume] admin
@@ Line 652: / Line 652: @@
 current-context: ${USER}-${CLUSTER_NAME}
 EOF</code>
+===== Bash-скрипты в init-контейнерах при деплойменте с помощью helm =====
+В чарте в директории files я имею просто скрипт, который должне запуститься в init-контейнере. \\
+Я поменщаю этот скрипт в секрет с помощью такого манифеста:
+<code>
+apiVersion: v1
+kind: Secret
+metadata:
+  name: files
+type: Opaque
+data:
+{{ (.Files.Glob "files/*").AsSecrets | indent 2 }}
+</code>
+В деплойменте я запускаю init-контейнер, в котором монтируется секрет с этим скриптом и выполняется этот скрипт:
+<code>
+...
+      initContainers:
+      - name: copy-files
+        image: docker.rdleas.ru/busybox
+        command:
+        - "sh"
+        - "-c"
+        - "cp /tmp/files/init-script.sh /tmp/ && chmod u+x /tmp/init-script.sh && /tmp/init-script.sh"
+        volumeMounts:
+        - name: files
+          mountPath: /tmp/files/
+...
+      volumes:
+      - name: files
+        secret:
+          secretName: files
+</code>
+то есть мне надо сделать скрипт исполняемым (дать соотвествующие разрешения), но смонтирован он как read-only, поэтому я предварительно копирую его. А после того, как разрешено его исполнение - запускаю скрипт.
 ====== Обновление сертификатов ======
 https://github.com/kubernetes/kubeadm/issues/581#issuecomment-471575078 \\
@@ Line 688: / Line 721: @@
   base64 -w 0 ./new_node.crt.pem
 И затем подставляем в поле **client-certificate-data:** в файлике **/etc/kubernetes/kubelet.conf**
-===== Kubernetes LDAP Auth =====
+====== Kubernetes LDAP Auth ======
 **LDAP**-аутентификацию к кластеру **kubernetes** можно прикрутить с помощью различных средств, но все они используют один подход и схожие по назначению компоненты:
   * Служба каталога с поддрежкой протокола LDAP. Например - Active Directory
@@ Line 694: / Line 727: @@
   * Некое web-приложение, с которым взаимодействует пользователи. Оно перенапрявляет пользователя на **OpenID Connector**, получает от кластера **kubernetes** сертификат и генерирует конфиг для **kubectl**.
-==== OIDC Providers ====
+===== OIDC Providers =====
   * Dex
   * Keycloak
-==== WebApps ====
+===== WebApps =====
   * Kuberos - https://github.com/negz/kuberos (не поддерживается с 2019 года)
   * GangWay
   * Dex K8s Authenticator
-==== Keycloak + kubelogin ====
+===== Keycloak + kubelogin =====
 Мне понравился такой вариант - **Keycloak** в качестве OIDC-провайдера и **kubelogin** в качестве способа получения токена. \\
-=== Настройка client в keycloak ===
+==== Настройка client в keycloak ====
 В параметры клиента в **keycloak** в **valid redirect uris** нужно прописать **http://localhost:8000** (или *)
-=== Настройка кластера kubernetes ===
+==== Настройка кластера kubernetes ====
 На каждой мастер-ноде редактируем файл **/etc/kubernetes/manifests/kube-apiserver.yaml** и добавляем туда такие параметры:
 <code>    - --oidc-ca-file=/etc/ssl/certs/RDLeas_Root_CARDleas-SRV-DC02-CA.pem
@@ Line 731: / Line 764: @@
         oidc-username-claim: email</code>
-=== Настройка клиентской машины ===
+==== Настройка клиентской машины ====
 Устанавливаем плагин kubelogin. \\
 Скачиваем бинарник https://github.com/int128/kubelogin/releases \\
@@ Line 756: / Line 789: @@
   name: sbl-apps-dev-oidc</code>
-=== Назначение привилегий в кластере ===
+==== Назначение привилегий в кластере ====
 Название групп в манифестах должно быть точно таким же как и в токене. В моей инсталляции в начале названия группы есть слеш. \\
 Права на неймспейс (в даннос лучае - default) выдаем так:
@@ Line 808: / Line 841: @@
 </code>
-=== Разрешение проблем ===
+==== Разрешение проблем ====
 Поглядеть текущий токен можно так:
   kubelogin get-token --oidc-issuer-url=https://sso.rdleas.ru/auth/realms/rdleas --oidc-client-id=kubernetes
 Расшифровать его (и увидеть список групп в нем) можно тут: https://jwt.io/ \\
-== invalid bearer token, oidc: email not verified ==
+=== invalid bearer token, oidc: email not verified ===
 В логе **kube-apiserver** ошибка
   Unable to authenticate the request due to an error: [invalid bearer token, oidc: email not verified]
@@ Line 825: / Line 858: @@
   kubectl --token=$token --server=https://192.168.1.2:6443 --insecure-skip-tls-verify get po --v=10
-==== Dex + Dex K8s authenticator ====
+===== Dex + Dex K8s authenticator =====
 https://uni.dtln.ru/digest/autentifikaciya-v-kubernetes-s-pomoshchyu-dex-prikruchivaem-ldap \\
 https://habr.com/ru/post/436238/ \\
@@ Line 831: / Line 864: @@
 https://github.com/mintel/dex-k8s-authenticator \\
-==== Keycloak + Gangway ====
+===== Keycloak + Gangway =====
 https://github.com/heptiolabs/gangway \\
-==== Dex + GangWay ====
+===== Dex + GangWay =====
 https://github.com/alexbrand/gangway-dex-tutorial
@@ Line 842: / Line 875: @@
 https://www.digitalocean.com/community/tutorials/how-to-create-a-kubernetes-cluster-using-kubeadm-on-ubuntu-18-04
-====== DevOps ======
+====== Отмена удаления PersistentVolume ======
-Мониторинг веб-приложения - graphana \\
+Если так случайно вышло, что вы удалили **PersistentVolume**, то не отчаивайтесь! Он будет находитьтся в состоянии **Terminating** до тех пор, пока существуют **pod**, куда он смонтирован и **PersistentVolumeClaim**, которая породила этот PV и удаление можно отменить. \\
+На помощь приходит специальная утилитка: https://github.com/jianz/k8s-reset-terminating-pv
+  git clone https://github.com/jianz/k8s-reset-terminating-pv.git
+  cd k8s-reset-terminating-pv
+  go build -o resetpv
+Собранный бинарник: {{ :devops:resetpv.tar.gz |}} \\
+Заходим на мастер-ноду, архивируем сертификаты и смотрим какой сертификат за что отвечает:
+  ssh user@master-node
+  sudo -H tar -cvzf ~/etcd-pki.tar.gz /etc/kubernetes/pki/etcd
+  sudo docker  ps --no-trunc | grep etcd
+  exit
+В выводе среди всего прочего будет такое:
+<code>--advertise-client-urls=https://10.77.68.1:2379
+--cert-file=/etc/kubernetes/pki/etcd/server.crt
+--key-file=/etc/kubernetes/pki/etcd/server.key
+--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt</code>
+В вашей инсталляции имена, пути и порты могут быть иными. \\
+И забираем с мастер-ноды кластера архив с сертификатами, которые необходимы для подключения к **etcd** кластера:
+  scp user@master-node:/home/user/etcd-pki.tar.gz ./
+  tar -xvf ./etcd-pki.tar.gя
+  mv ./etc/kubernetes/pki/etcd/* ./
+И дальше применяем утилиту:
+  ./resetpv --etcd-ca ./ca.crt --etcd-cert ./server.crt --etcd-key ./server.key --etcd-host 10.77.68.1 --etcd-port 2379 pv-name
+Если вдруг так вышло, что вы удалили все PV в кластере (как я - хотел удалить **pvc** в неймспейсе но просто опечатался и вместо **pvc** ввел **pv**):
+  kubectl delete -n namespace pv --all
+то чтобы отменить удаление всех PV делаем так:
+  PVs=`kubectl get pv | grep Terminating | awk '{print $1}' | grep -v NAME`
+  for pv in $PVs; do ./resetpv --etcd-ca ./ca.crt --etcd-cert ./server.crt --etcd-key ./server.key --etcd-host 10.77.68.1 --etcd-port 2379 $pv; done