Kubernetes — установить Cosnul

Consul — это децентрализованный отказоустойчивый discovery-сервис от компании HashiCorp (которая разрабатывает такие продукты как Vagrant, TerraForm, Otto, Atlas и другие).




Consul является децентрализованным сервисом, то есть Consul agent устанавливается на каждый хост и является полноправным участником кластера. Таким образом, сервисам не нужно знать адрес discovery в нашей сети, все запросы к discovery выполняются на локальный адрес 127.0.0.1.




В этом руководстве вы развернете центр обработки данных Consul с официальным чартом Helm.
Вам не нужно обновлять какие-либо значения в чарте Хелма для базовой установки.
Однако вы можете создать файл значений с параметрами, чтобы разрешить доступ к пользовательскому интерфейсу Consul.
Предупреждение о безопасности. Это руководство не для производственного использования. По умолчанию на диаграмме будет установлена небезопасная конфигурация Consul. Пожалуйста, обратитесь к документации Kubernetes, чтобы определить, как вы можете обеспечить безопасность Consul на Kubernetes в производстве. Кроме того, настоятельно рекомендуется использовать правильно защищенный кластер Kubernetes или убедиться, что вы понимаете и включаете рекомендуемые функции безопасности.
Для успешного выполнения этого руководства у вас должен быть существующий кластер Kubernetes и локально настроенные Helm и kubectl.




Разворачиваем Consul




Вы можете развернуть полный центр обработки данных Consul, используя официальный чарт Helm.




По умолчанию в чарте будут установлены три сервера Consul и клиент на всех узлах Kubernetes.




Вы можете просмотреть значения чарта, чтобы узнать больше о настройках по умолчанию.




Скачать Helm чарт




Во-первых, вам нужно будет клонировать официальный Helm чарт из репозитория Gashub от HashiCorp.




$ git clone https://github.com/hashicorp/consul-helm.git




Вам не нужно обновлять чарт Helm перед развертыванием Консула, т.к. он имеет разумные значения по умолчанию.




Ознакомьтесь с документацией по чартам Helm, чтобы узнать больше информации.




Установка Consul через Helm




Чтобы развернуть Consul, вы должны быть в том же каталоге, что и чарт.




$ cd consul-helm




Теперь вы можете развернуть Консул с помощью установки helm.




Это позволит развернуть три сервера и агента на всех узлах Kubernetes.




Процесс должен быть быстрым, менее 5 минут.




$ helm install .



NAME:   mollified-robin LAST DEPLOYED: Mon Feb 25 15:57:18 2019 NAMESPACE: default STATUS: DEPLOYED

NAME                             READY  STATUS             RESTARTS  AGE

mollified-robin-consul-25r6z     0/1    ContainerCreating  0         0s

mollified-robin-consul-4p6hr     0/1    ContainerCreating  0         0s

mollified-robin-consul-n82j6     0/1    ContainerCreating  0         0s

mollified-robin-consul-server-0  0/1    Pending            0         0s

mollified-robin-consul-server-1  0/1    Pending            0         0s

mollified-robin-consul-server-2  0/1    Pending            0         0s




Вывод, показщанный выше был уменьшен для удобства чтения.




Однако вы можете видеть, что в этом кластере Kubernetes с тремя узлами есть три сервера Consul и три клиента Consul.




Доступ к Consul UI




Чтобы получить доступ к пользовательскому интерфейсу, вам необходимо обновить значения пользовательского интерфейса в чарте .




В качестве альтернативы, если вы не хотите обновлять свой кластер, вы можете настроить переадресацию портов с помощью kubectl.




Создайте файл значений




Сначала создайте файл значений, который можно передать в командной строке при обновлении.




# values.yaml

global:

  datacenter: hashidc1

syncCatalog:

  enabled: true

ui:

  service:

    type: 'LoadBalancer'

server:

  affinity: |

    podAntiAffinity:

      requiredDuringSchedulingIgnoredDuringExecution:

        - labelSelector:

            matchLabels:

              app: {{ template "consul.name" . }}

              release: "{{ .Release.Name }}"

              component: server

        topologyKey: kubernetes.io/hostname




Этот файл переименовывает ваш центр обработки данных, включает синхронизацию каталога, настраивает службу балансировки нагрузки для пользовательского интерфейса и разрешает привязку, чтобы разрешить только одну поду Consul на узел Kubernetes.




Параметры синхронизации каталога позволят вам увидеть сервисы Kubernetes в пользовательском интерфейсе Consul.




Инициируйте обновление




Наконец, инициируйте обновление с помощью helm upgrade и флага -f, который передается в ваш новый файл значений.




Этот процесс также должен быть быстрым, менее минуты.




$ helm upgrade consul -f values.yaml




Теперь вы можете использовать kubectl get services для определения внешнего IP-адреса вашего пользовательского интерфейса Consul.




$ kubectl get services

NAME                            TYPE           CLUSTER-IP     EXTERNAL-IP             PORT(S)        AGE

consul                          ExternalName   <none>         consul.service.consul   <none>         11d

kubernetes                      ClusterIP      122.16.14.1    <none>                  443/TCP        137d

mollified-robin-consul-dns      ClusterIP      122.16.14.25   <none>                  53/TCP,53/UDP  13d

mollified-robin-consul-server   ClusterIP      None           <none>                  8500/TCP       13d

mollified-robin-consul-ui       LoadBalancer   122.16.31.395  36.276.67.195           8




Кроме того, вы можете использовать kubectl get pods для просмотра нового процесса синхронизации.




Процесс синхронизации каталога по умолчанию синхронизирует службы Consul и Kubernetes в обоих направлениях.




$ kubectl get pods

NAME                                                 READY   STATUS      RESTARTS   AGE

mollified-robin-consul-d8mnp                          1/1     Running     0         15d

mollified-robin-consul-p4m89                          1/1     Running     0         15d

mollified-robin-consul-qclqc                          1/1     Running     0         15d

mollified-robin-consul-server-0                       1/1     Running     0         15d

mollified-robin-consul-server-1                       1/1     Running     0         15d

mollified-robin-consul-server-2                       1/1     Running     0         15d

mollified-robin-consul-sync-catalog-f75cd5846-wjfdk   1/1     Running     0




Служба должна была добавитьcя по имени развертывания consul-ui.





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




Доступ к Consul




Помимо доступа к Consul с помощью пользовательского интерфейса, вы можете управлять Consul с помощью HTTP API или напрямую подключаясь к поду с помощью kubectl.




Kubectl




Для доступа к каталогу pod и data вы можете запустить kodectl в pod для запуска сеанса оболочки.




$ kubectl exec -it mollified-robin-consul-server-0 /bin/sh




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




Например, вы можете просмотреть Consul members.




$ consul members

Node                                   Address           Status  Type    Build  Protocol  DC        Segment

mollified-robin-consul-server-0        172.20.2.18:8301  alive   server  1.4.2  2         hashidc1  <all>

mollified-robin-consul-server-1        172.20.0.21:8301  alive   server  1.4.2  2         hashidc1  <all>

mollified-robin-consul-server-2        172.20.1.18:8301  alive   server  1.4.2  2         hashidc1  <all>

gke-tier-2-cluster-default-pool-leri5  172.20.1.17:8301  alive   client  1.4.2  2         hashidc1  <default>

gke-tier-2-cluster-default-pool-gnv4   172.20.2.17:8301  alive   client  1.4.2  2         hashidc1  <default>

gke-tier-2-cluster-default-pool-zrr0   172.20.0.20:8301  alive   client  1.4.2




Consul HTTP API




Вы можете использовать Consul HTTP API , связавшись с локальным агентом, работающим на узле Kubernetes.




Вы можете прочитать документацию, если хотите узнать больше об использовании Consul HTTP API с Kubernetes.




Источник: https://sidmid.ru/kubernetes-установить-cosnul/



2023-01-02T06:18:22
DevOps

Kubernetes — запуск kafka

kubectl create ns kafka




git clone https://github.com/confluentinc/cp-helm-charts.git




cd cp-helm-charts/
helm dependency update charts/cp-kafka/




[root@prod-vsrv-kubemaster1 cp-helm-charts]# vim charts/cp-zookeeper/values.yaml




persistence:

  enabled: true

  ## Size for Data dir, where ZooKeeper will store the in-memory database snapshots.

  dataDirSize: 5Gi

  dataDirStorageClass: "nfs-storageclass"



  ## Size for data log dir, which is a dedicated log device to be used, and helps avoid competition between logging and snaphots.

  dataLogDirSize: 5Gi

  dataLogDirStorageClass: "nfs-storageclass"





[root@prod-vsrv-kubemaster1 cp-helm-charts]# vim charts/cp-kafka/values.yaml




persistence:

  enabled: true

  size: 1Gi

  storageClass: "nfs-storageclass"




helm install confluent ./charts/cp-kafka/ —values ./charts/cp-kafka/values.yaml -n kafka




zookeeper доступ по адресу:




confluent-cp-zookeeper.kafka.svc.test.local:2181




поставим теперь kafka-manager:




helm repo add stable https://kubernetes-charts.storage.googleapis.com




helm pull stable/kafka-manager




tar -xvf kafka-manager-2.3.5.tgz




rm -rf kafka-manager-2.3.5.tgz




[root@prod-vsrv-kubemaster1 cp-helm-charts]# vim kafka-manager/values.yaml




zkHosts: "confluent-cp-zookeeper.kafka.svc.test.local:2181"





basicAuth:

  enabled: true

  username: "admin"

  ## Defaults to a random 10-character alphanumeric string if not set

  ##

  password: "admin"







ingress:

  enabled: true

  annotations: {}

    # kubernetes.io/ingress.class: nginx

    # kubernetes.io/tls-acme: "true"

  path: /

  hosts:

    - kafka.prod.test.local







[root@prod-vsrv-kubemaster1 cp-helm-charts]# helm install kafka-manager kafka-manager/ —values kafka-manager/values.yaml -n kafka




далее настраиваем в панельке кластер, в качестве адреса для zookeeper указываем:
confluent-cp-zookeeper.kafka.svc.test.local:2181













проверим работу. Для этого создадим под откуда будем подключаться:




cat test-pod.yaml




apiVersion: v1

kind: Pod

metadata:

  name: kafka-client

  namespace: kafka

spec:

  containers:

  - name: kafka-client

    image: confluentinc/cp-enterprise-kafka:6.0.1

    command:

      - sh

      - -c

      - "exec tail -f /dev/null"





Запускаем:
kubectl apply -f test-pod.yaml




Подключаемся:
kubectl exec -it kafka-client -n kafka /bin/bash




Смотрим список топиков:




[appuser@kafka-client ~]$ kafka-topics —bootstrap-server confluent-cp-kafka-headless:9092 —list
__consumer_offsets
_confluent-metrics
test-ropic




создаём producer и вкидываем через него несколько проверочных строк:




[appuser@kafka-client ~]$ kafka-console-producer —broker-list confluent-cp-kafka-0.confluent-cp-kafka-headless.kafka:9092 —topic test-ropic
>sdfsf
>sdfsf
>rtert
>hyhy




Читаем эти сообщения с помощью consumer




[appuser@kafka-client ~]$ kafka-console-consumer —bootstrap-server confluent-cp-kafka-0.confluent-cp-kafka-headless.kafka:9092 —topic test-ropic —from-beginning
sdfsf
sdfsf
rtert
hyhy




Создаём topic:
[appuser@kafka-client ~]$ kafka-topics —bootstrap-server confluent-cp-kafka-headless:9092 —topic NEW-TEST-TOPIC —create —partitions 1 —replication-factor 1 —if-not-exists
Created topic NEW-TEST-TOPIC.




проверяем:
[appuser@kafka-client ~]$ kafka-topics —bootstrap-server confluent-cp-kafka-headless:9092 —list
NEW-TEST-TOPIC
__consumer_offsets
_confluent-metrics
new-test-topic




Удаляем:
[appuser@kafka-client ~]$ kafka-topics —bootstrap-server confluent-cp-kafka-headless:9092 —topic NEW-TEST-TOPIC —delete —if-exists




Проверяем:
[appuser@kafka-client ~]$ kafka-topics —bootstrap-server confluent-cp-kafka-headless:9092 —list
__consumer_offsets
_confluent-metrics
new-test-topic




Источник: https://sidmid.ru/kubernetes-запуск-kafka/



2023-01-02T06:16:04
DevOps

Kubernetes — пример использования RBAC

Начиная с Kubernetes 1.6, политики RBAC включаются по умолчанию. Политики RBAC имеют жизненно важное значение для правильного управления вашим кластером, поскольку они позволяют вам указывать, какие типы действий разрешены для конкретного пользователя и его роли в вашей организации.




Примеры включают:




  • Защиту кластера путем разрешения привилегированные действий (например, доступ к секретам) только администраторам.



  • Включение принудительной аутентификации пользователей в вашем кластере.



  • Ограничение создания ресурсов (т.к. контейнеры, постоянные диски, развертывания) для конкретных пространств имен. Вы также можете использовать квоты, чтобы гарантировать, что использование ресурсов ограничено и находится под контролем.



  • Разрешение пользователям просматривать ресурсы только в своем авторизованном пространстве имен, что позволяет изолировать ресурсы внутри вашей организации (например, между отделами или департаментами).




В следствие того, что в последних версиях Kubernetes RBAC включен по умолчанию, вы, возможно, уже обнаружили специфические ошибки при настройке решений по сетевой виртуализации (например, flunneld) или деплое Helm в вашем кластере. Обычно такие ошибки выглядят следующим образом:




the server does not allow access to the requested resource




ща рассмотрим как правильно работать с RBAC, чтобы вы могли решать такого рода проблемы.




API объекты RBAC




Одной из основных функций Kubernetes является то, что все его ресурсы представляют собой моделируемые API объекты, которые позволяют выполнять с ними операции CRUD (Create, Read, Update, Delete). Примерами ресурсов являются:




  • Pods



  • Deployments



  • Namespaces



  • Secrets



  • Replicasets



  • PersistentVolumes



  • ConfigMaps



  • Nodes




Примеры возможных операций над этими ресурсами:




  • create



  • get



  • delete



  • list



  • update



  • edit



  • watch



  • exec




Высокоуровневые ресурсы связаны с группами API (например, Pod относится к core группе API, а Deployments относятся к группе API apps). Дополнительные сведения обо всех доступных ресурсах, операциях и группах API см. в официальном справочнике API Kubernetes.




Для управления RBAC в Kubernetes, помимо ресурсов и операций, нам нужны следующие элементы:




  • Rules. Правила представляют собой набор операций, которые могут выполняться группой ресурсов, принадлежащих различным группам API.



  • Roles и ClusterRoles. Оба состоят из правил. Разница между Role и ClusterRole – это область применимости: в Role правила применимы к одному пространству имен, тогда как ClusterRole правила распространяются на весь кластер, поэтому правила применяются к нескольким пространствам имен. ClusterRoles также могут определять правила для ресурсов уровня кластера (например, узлы). Roles и ClusterRoles мапятся на API ресурсы внутри нашего кластера.



  • Subjects. Субъекты соответствуют объектам, которые пытаются выполнить операции в кластере. Существует три типа субъектов:



  • User Accounts (учетные записи пользователей): глобальны и предназначены для людей или процессов, живущих вне кластера. В кластере Kubernetes нет связанного с этим субъектом объекта API ресурса.



  • Service Accounts (учетные записи служб). Этот вид учетной записи предназначен для внутрикластерных процессов, запущенных в Pod-ах вашего кластера, которым необходимо получить доступ к API кластера.



  • Groups (группы). Группы используется для ссылки на сразу несколько учетных записей.Некоторые группы, такие как cluster-admin (объясняется в последующих разделах), создаются по умолчанию.



  • RoleBindings (связи ролей) и ClusterRoleBindings (связи кластерных ролей): как видно из названия сущностей, они связывают субъекты с ролями (т.е. операциями, которые может выполнять конкретный пользователь). Что касается их разницы с ClusterRoles, разница заключается в области применимости: RoleBinding применяет правила внутри одного пространства имен, тогда как ClusterRoleBinding применяет их во всех пространствах имен кластера.




Вы можете найти примеры каждого элемента API в официальной документации Kubernetes.




Создание пользователя с ограничениями по пространству имен




В этом примере мы создадим следующую учетную запись пользователя:




  • Имя пользователя: user1



  • Группа: deparment1




Мы добавим необходимые политики RBAC, чтобы этот пользователь мог полностью управлять развертываниями (т.е. использовать команду kubectl run) только внутри пространства имен office. В конце мы проверим созданные политики, чтобы убедиться, что они работают так, как мы их определили.




Создание пространства имен




Выполните команду kubectl create для создания пространства имен office. Команду необходимо запустить от пользователя Kubernetes admin:




[root@kub-master-1 ~]# kubectl create namespace office




Создание пользователя




Как уже упоминалось ранее, в Kubernetes нет объектов API для управления учетными записями пользователей. Из доступных способов управления аутентификацией (см. официальную документацию Kubernetes) для простоты мы будем использовать сертификаты OpenSSL. Необходимые шаги:




  • Создайте закрытый ключ для своего пользователя. В этом примере мы назовем файл user1.key[root@kub-master-1 ~]# openssl genrsa -out user1.key 2048



  • Создайте запрос сертификата user1.csr, используя только что созданный вами закрытый ключ (user1.key). Убедитесь, что вы указали свое имя пользователя и группу в разделе -subj(CN для имени пользователя и O для группы). Как упоминалось ранее, мы будем использовать имя user1 и deparment1 в качестве группы:




[root@kub-master-1 ~]# openssl req -new -key user1.key -out user1.csr -subj «/CN=user1/O=deparment1»




  • Найдите свой центр сертификации кластера Kubernetes (CA). Он будет отвечать за утверждение запроса и получение необходимого сертификата для доступа к API кластера. Обычно он располагается в директории /etc/kubernetes/pki/. В случае Minikube это будет ~/.minikube/. Убедитесь, что файлы ca.crt и ca.key существуют в соответствующей директории.




[root@kub-master-1 ~]# ll /etc/kubernetes/pki/

total 156

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 admin-kub-master-1-key.pem

-rw-------. 1 kube kube-cert 1399 Mar  8 18:58 admin-kub-master-1.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 admin-kub-master-2-key.pem

-rw-------. 1 kube kube-cert 1399 Mar  8 18:58 admin-kub-master-2.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 admin-kub-master-3-key.pem

-rw-------. 1 kube kube-cert 1399 Mar  8 18:58 admin-kub-master-3.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 apiserver-key.pem

-rw-------. 1 kube kube-cert 2444 Mar  8 18:58 apiserver.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 ca-key.pem

-rw-------. 1 kube kube-cert 1090 Mar  8 18:58 ca.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 front-proxy-ca-key.pem

-rw-------. 1 kube kube-cert 1111 Mar  8 18:58 front-proxy-ca.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 front-proxy-client-key.pem

-rw-------. 1 kube kube-cert 1367 Mar  8 18:58 front-proxy-client.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-controller-manager-key.pem

-rw-------. 1 kube kube-cert 1375 Mar  8 18:58 kube-controller-manager.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 kube-proxy-kub-master-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-master-1.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-proxy-kub-master-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-master-2.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 kube-proxy-kub-master-3-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-master-3.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-proxy-kub-worker-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-worker-1.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-proxy-kub-worker-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-worker-2.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-scheduler-key.pem

-rw-------. 1 kube kube-cert 1363 Mar  8 18:58 kube-scheduler.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-master-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-master-1.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-master-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-master-2.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-master-3-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-master-3.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-worker-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-worker-1.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-worker-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-worker-2.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 service-account-key.pem





  • Создайте сертификат user1.crt, одобрив запрос на подпись сертификата, user1.csr, сделанный ранее. Убедитесь, что вы заменили CA_LOCATION в примере команды ниже на местоположение вашего актуального CA кластера. Сертификат будет действителен в течение 500 дней:




$ openssl x509 -req -in user1.csr -CA CA_LOCATION/ca.crt -CAkey CA_LOCATION/ca.key -CAcreateserial -out user1.crt -days 500




в моём случае это команда:




[root@kub-master-1 ~]# openssl x509 -req -in user1.csr -CA /etc/kubernetes/pki/ca.pem -CAkey /etc/kubernetes/pki/ca-key.pem -CAcreateserial -out user1.crt -days 500
и её вывод:




Signature ok

subject=/CN=user1/O=deparment1

Getting CA Private Key




  • Сохраните как user1.crt, так и user1.key где-нибудь в безопасном месте (например, в директории ~/.kube/certs/):
    $ mkdir ~/.kube/certs
    $ cp user1.crt ~/.kube/certs
    $ cp user1.key ~/.kube/certs



  • добавьте новый контекст с новыми учетными данными для вашего кластера Kubernetes.
    [root@kub-master-1 ~]# kubectl config set-credentials user1 —client-certificate=$HOME/.kube/certs/user1.crt —client-key=$HOME/.kube/certs/user1.keyСмотрим имя кластера:
    [root@kub-master-1 ~]# kubectl config view -o jsonpath='{«Cluster nametServern»}{range .clusters[*]}{.name}{«t»}{.cluster.server}{«n»}{end}’



  • добавьте новый контекст с новыми учетными данными для вашего кластера Kubernetes.
    [root@kub-master-1 ~]# kubectl config set-credentials user1 —client-certificate=$HOME/.kube/certs/user1.crt —client-key=$HOME/.kube/certs/user1.keyСмотрим имя кластера:
    [root@kub-master-1 ~]# kubectl config view -o jsonpath='{«Cluster nametServern»}{range .clusters[*]}{.name}{«t»}{.cluster.server}{«n»}{end}’



  • [root@kub-master-1 ~]# kubectl config set-context user1-context —cluster=cluster.local —namespace=office —user=user1




добавим теперь пользователя  под которым будем работать:




[root@kub-master-1 ~]# adduser test
[root@kub-master-1 ~]# mkdir -p /home/test/.kube/certs
[root@kub-master-1 ~]# cp /root/.kube/certs/user1.* /home/test/.kube/certs/




смотрим файл:
[root@kub-master-1 ~]# cat /root/.kube/config




нас интересует:




certificate-authority-data
и
server




и создаём файл следующего вида:




[root@kub-master-1 ~]# cat /home/test/.kube/config




apiVersion: v1

clusters:

- cluster:

    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMrVENDQWVHZ0F3SUJBZ0lKQUl0L0JPdHQrWUhVTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIydDFZbVV0WTJFd0lCY05NakV3TXpBNE1USTFPREE1V2hnUE1qRXlNVEF5TVRJeE1qVTRNRGxhTUJJeApFREFPQmdOVkJBTU1CMnQxWW1VdFkyRXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCCkFRQ2FRZk9nbzdpZ3oyV0QyWEd1dzNSd2x6VUhxcjRFT2k1d0wwaWZvVnBaWXBzZk9ORlE0ME90akVEQUVsUXYKSW5YeW1iVEdQN0w0QUFIZlNFZWRULysyUFh4NmV6VDV3WlozbGg5WWt1UmhHcWZUamtsVXN6LzVoOVpNekhzNgpwWWVyNzVJQUZyRXlxSDFtR2pwM0FjaUZmNUU1TmFvczJXQ21HWklPbmdqTmVUMElXdHFGQjNVTzNMSTkxS0JJCi9tNWRPZTh6elJjVWxBODltTTFhTzBBSTZEYWNUbXRiVllDcklwVW01cE45UHFWSjVZNGorTXQvSlpISTlnRisKMUsvUW5hb0owVm5udkl0T0dJbzhaSlZ5ellTVTlNZlltcmE0RkhvYmQzaGsrN1RBZ3lNRWJlOERLdUlpRENzKwozOVhEaXByL0FaRHVnYnZuOVJYV0M5WnhBZ01CQUFHalVEQk9NQjBHQTFVZERnUVdCQlJaUUtYWFdJTlpCSkJzCkZERTlpTTYydHJuSDhUQWZCZ05WSFNNRUdEQVdnQlJaUUtYWFdJTlpCSkJzRkRFOWlNNjJ0cm5IOFRBTUJnTlYKSFJNRUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFBQVgrakdVT3k4R1lEKzh6M244SFV6V25XeAp0RWRrdEJEakxVcjB2anovN0lVRDU0R0MrRm5FY0ZybXZMVHhkYWNNNXNEQmo2MHhscjh2dG9mbDFzekJxMjVVCnFUWTRveDZ1VzUreGlBU1hqNFhHeEZtUG8rUzVGUi9EZjA3clBJZ3QzWWdEYkZHUUw5aHh4UXdKMDdVR3JKa08KM0QyNjYzUDJ4WTBndGdyYzY0UG5EWDBuZ1VxSzJ0akxsKy9qU1c1MHdnWURvbUlYNjlyWUxyMElzOWpYZmk0OQpFK3ljb2ZURElSeUFWT2U2QTBXbmQ2MFhlMEZPdUdqUVZHcWRKeVhBeVhrOW1FK1lNRk9kS09PZjMxNmtYeW90ClppNmE3bnZtYjhFSWpXZWFpd1JwQzNGOEgrdHRFYzFmSVdvNkoralJZTlFjME5BaFhZbFRwRmp6blA0TAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==

    server: https://192.168.1.201:6443

  name: cluster.local

contexts:

- context:

    cluster: cluster.local

    namespace: office

    user: user1

  name: user1-context

kind: Config

preferences: {}

users:

- name: user1

  user:

    client-certificate: certs/user1.crt

    client-key: certs/user1.key




не забываем указать certificate-authority-data и server




Теперь при попытке использовать kubectl с этим конфигурационным файлом мы будем получать отказ в доступе. Это ожидаемое поведение, поскольку мы не определили никаких разрешенных операций для только что созданного пользователя. Убедитесь в этом сами:




[test@kub-master-1 ~]$ kubectl get pod -n my-site
The connection to the server localhost:8080 was refused — did you specify the right host or port?
данная ошибка логична потому что мы не указали context




[test@kub-master-1 ~]$ kubectl —context=user1-context get pods -n my-site
Error from server (Forbidden): pods is forbidden: User «user1» cannot list resource «pods» in API group «» in the namespace «my-site»




а вот эта как рас та ошибка что и должна прилетать Forbidden




Создание роли для управления развертываниями




Создайте файл role-deployment-manager.yaml с приведенным ниже содержимым. В этом yaml-файле мы создаем правило, которое позволяет пользователю выполнять несколько операций с Deployments, Pods и ReplicaSets (необходимых для создания Deployment), которые принадлежат к core (выделены “” в yaml-файле) extensions группам API:




[root@kub-master-1 ~]# cat role-deployment-manager.yaml




apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  namespace: office

  name: deployment-manager

rules:

- apiGroups: ["", "extensions", "apps"]

  resources: ["deployments", "replicasets", "pods"]

  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # вы таже можете использовать ["*"] вместо списка




[root@kub-master-1 ~]# kubectl create -f role-deployment-manager.yaml




Установление связи пользователь-роль




Создайте файл rolebinding-deployment-manager.yaml так, как показано ниже. В этом файле мы привязываем Role deployment-manager к субъекту User Account user1 внутри пространства имен office:




[root@kub-master-1 ~]# cat rolebinding-deployment-manager.yaml




apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: deployment-manager-binding

  namespace: office

subjects:

- kind: User

  name: user1

  apiGroup: ""

roleRef:

  kind: Role

  name: deployment-manager

  apiGroup: ""




[root@kub-master-1 ~]# kubectl create -f rolebinding-deployment-manager.yaml




Тестирование политик RBAC




Теперь вы можете выполнять следующие команды без каких-либо проблем:




[test@kub-master-1 ~]$ kubectl —context=user1-context get pods -n office
No resources found in office namespace.




запустим тестовое приложение и проверим что нам доступно из под нашего пользователя:




[test@kub-master-1 ~]$ kubectl —context=user1-context get all -n office




NAME                                        READY   STATUS    RESTARTS   AGE

pod/my-deployment-apache-859486bd8c-8ccxd   1/1     Running   0          96s



NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/my-deployment-apache   1/1     1            1           96s



NAME                                              DESIRED   CURRENT   READY   AGE

replicaset.apps/my-deployment-apache-859486bd8c   1         1         1       96s

Error from server (Forbidden): replicationcontrollers is forbidden: User "user1" cannot list resource "replicationcontrollers" in API group "" in the namespace "office"

Error from server (Forbidden): services is forbidden: User "user1" cannot list resource "services" in API group "" in the namespace "office"

Error from server (Forbidden): daemonsets.apps is forbidden: User "user1" cannot list resource "daemonsets" in API group "apps" in the namespace "office"

Error from server (Forbidden): statefulsets.apps is forbidden: User "user1" cannot list resource "statefulsets" in API group "apps" in the namespace "office"

Error from server (Forbidden): horizontalpodautoscalers.autoscaling is forbidden: User "user1" cannot list resource "horizontalpodautoscalers" in API group "autoscaling" in the namespace "office"

Error from server (Forbidden): jobs.batch is forbidden: User "user1" cannot list resource "jobs" in API group "batch" in the namespace "office"

Error from server (Forbidden): cronjobs.batch is forbidden: User "user1" cannot list resource "cronjobs" in API group "batch" in the namespace "office"





как видим нам доступны только следующие сущности:
deployments  replicasets   pods




как рас их мы и перечислили в конфиге  role-deployment-manager.yaml  для нашего namespace office




проверим удаление:




YAML




[test@kub-master-1 ~]$ kubectl --context=user1-context delete pod my-deployment-apache-859486bd8c-8ccxd -n office

pod "my-deployment-apache-859486bd8c-8ccxd" deleted




как видим всё ок.




Источник: https://sidmid.ru/kubernetes-пример-использования-rbac/



2023-01-02T06:12:18
DevOps

Использование PostStart хука при запуске пода в Kubernetes-кластере

Хуки дают возможность получать информацию о жизненном цикле управления контейнерами и выполнять код, реализованный в обработчике (handler), при срабатывании определенного хука.




Для каждого контейнера в поде хуки определяются отдельно. Существуют два типа хуков — PostStart и PreStop. Первый является асинхронным и выполняется сразу же при создании контейнера, однако нет никакой гарантии, что данный хук будет выполнен до запуска инструкции ENTRYPOINT контейнера. Стоит отметить, что если выполнение PostStart хука занимает очень много времени (или зависает), то контейнер не может перейти в состояние Running.




Хук PreStop, как видно из его названия, выполняется перед тем как контейнер будет остановлен (terminated) — будь то API-запрос или другое событие (например, неудачная liveness probe, “выдавливание” пода с узла кластера, перебор используемых ресурсов). Этот вызов синхронный, а это значит, что он обязательно должен быть завершен до того, как будет отправлен сигнал остановки контейнера.




Для хуков в жизненном цикле контейнеров предусмотрено два варианта обработчиков (handlers):




  • Exec — выполняет определенную команду (скрипт) в пространстве имен контейнера. Ресурсы, которые используются данной командой также учитываются в используемых ресурсах контейнера (важно при определении памяти и CPU);



  • HTTP — выполняет HTTP-запрос на определенный эндпоинт контейнера.




Если какой-то из хуков PostStart или PreStop завершается с ошибкой, то контейнер также будет остановлен. Логи хуков недоступны при выполнении команды kubectl logs <pod_name>, но если по какой-то причине они выполнились неудачно, то происходит событие FailedPostStartHook или FailedPreStopHook соответственно. Эти события можно увидеть выполнив команду kubectl describe pod <pod_name>.




Итак, мы вполне можем использовать PostStart хук для вставки данных в Redis при старте контейнера.




Идея состоит в следующем: с помощью ConfigMap мы добавим файл(ы) внутрь контейнера, причем названием ключа в редисе будет имя, а значением — содержимое этого файла. Далее, используя PostStart хук, мы “обработаем” каждый из файлов и вставим соответствующие данные в БД Redis.




Манифест, содержащий в себе все необходимые объекты Kubernetes, будет выглядеть так:




apiVersion: v1

kind: Service

metadata:

  name: ads-redis-test

  namespace: default

spec:

  selector:

    app: ads-redis-test

  ports:

  - name: redis

    port: 6379

  clusterIP: None

---

apiVersion: v1

kind: ConfigMap

metadata:

  name: ads-redis-test

  namespace: default

data:

  flow-rules-key: |

    [{

      "resource": "loopme.grpc.ssp.v0.AdsTxtRecordService/GetAdsTxtRelationships",

      "count": 100.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.grpc.ssp.v0.PublisherAccountService/GetPublisherById",

      "count": 5.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.grpc.ssp.v1.PublisherAccountService/GetPublisherById",

      "count": 5.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.grpc.ssp.v0.BundleLegacyService/GetBundleByKey",

      "count": 20.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.lsm.ssp.v0.BundleService/GetBundleById",

      "count": 20.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.lsm.ssp.v0.BundleService/QueryBundle",

      "count": 20.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.grpc.ssp.v0.AppLegacyService/GetAppById",

      "count": 10.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.grpc.ssp.v0.AppLegacyService/GetAppIdByKey",

      "count": 10.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.grpc.ssp.v0.AppLegacyService/GetAppIdByContainerKey",

      "count": 16.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "loopme.grpc.ssp.v0.AppLegacyService/GetAppByContainerKey",

      "count": 10.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "ExchangeThrottleRateService/GetThrottleRatesByKeys",

      "count": 20.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "dsp-fetcher",

      "count": 25.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "exchange-fetcher",

      "count": 300.0,

      "grade": "THREAD",

      "limit-app": "default"

    },{

      "resource": "kafka_dmp_ads_requests_info",

      "count": 500.0,

      "grade": "QPS",

      "limit-app": "default"

    }]    

  degrade-rules-key: |

    [{

      "resource": "analytics.AnalyticsApiService/AnalyzeCall",

      "count": 10.0,

      "grade": "EXCEPTION_COUNT",

      "time-window": 10,

      "min-request-amount": 100,

      "stat-interval-ms": 20000,

      "slow-ratio-threshold": 0.6

    },{

      "resource": "analytics.AnalyticsApiService/AnalyzeCall",

      "count": 10.0,

      "grade": "EXCEPTION_RATIO",

      "time-window": 10,

      "min-request-amount": 100,

      "stat-interval-ms": 20000,

      "slow-ratio-threshold": 0.6

    }]    

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ads-redis-test

  namespace: default

spec:

  replicas: 1

  selector:

    matchLabels:

      app: ads-redis-test

  template:

    metadata:

      labels:

        app: ads-redis-test

    spec:

      containers:

      - name: redis

        image: redis:6.0.9

        ports:

        - name: redis

          containerPort: 6379

        resources:

          limits:

            cpu: "0.5"

            memory: 1Gi

          requests:

            cpu: "0.5"

            memory: 1Gi

        lifecycle:

          postStart:

            exec:

              command: ["/bin/bash", "-c", "cd /script/ && for FILE in *key; do cat ${FILE} | redis-cli -n 2 -x set ${FILE}; done"]

        livenessProbe:

          exec:

            command:

            - sh

            - -c

            - redis-cli -h $(hostname) ping

          initialDelaySeconds: 5

          periodSeconds: 3

        readinessProbe:

          exec:

            command:

            - sh

            - -c

            - redis-cli -h $(hostname) ping

          initialDelaySeconds: 5

          timeoutSeconds: 3

        volumeMounts:

        - mountPath: /script

          name: script

      volumes:

      - name: script

        configMap:

          name: ads-redis-test




Вся “магия” заключается в команде, которая определена в postStart хуке:




command: ["/bin/bash", "-c", "cd /script/ && for FILE in *key; do cat ${FILE} | redis-cli -n 2 -x set ${FILE}; done"]




Здесь для каждого файла в каталоге /script, который заканчивается на key выполняется следующее:




  • с помощью команды cat выводится содержимое файла в STDOUT;



  • через конвейер | передаются следующей команде — консольной утилите redis-cli (здесь в STDIN попадает содержимое STDOUT из предыдущего шага);



  • redis-cli выполняет вставку данных во вторую БД (ключ -n 2) с помощью команды SET.




Примечание Именем ключа будет значение переменной ${FILE} (имя файла), а значением — данные из STDIN (об этом заботится ключ -x).




Источник: https://sidmid.ru/использование-poststart-хука-при-запуске-пода/



2023-01-02T06:04:30
DevOps

Kubernetes. Gitlab (ci/cd) (HTTP Basic: Access denied)

У меня имелся следующий проект, в котором собираются 4 контейнера а дальше деплоятся в кластер kubernetes
вот пример helm чарта:




[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/templates/deployment.yaml




---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: {{ .Values.deployment_name }}

  namespace: {{ .Values.namespace }}

  labels:

    app: {{ .Values.app_name }}



spec:

  replicas: {{ .Values.replica_number }}

  selector:

    matchLabels:

      app: {{ .Values.app_name }} # по вот этому лейблу репликасет цепляет под

# тут описывается каким мокаром следует обновлять поды

  strategy:

    rollingUpdate:

      maxSurge: 1  # указывает на какое количество реплик можно увеличить

      maxUnavailable: 1 # указывает на какое количество реплик можно уменьшить

#т.е. в одно время при обновлении, будет увеличено на один (новый под) и уменьшено на один (старый под)

    type: RollingUpdate

## тут начинается описание контейнера

  template:

    metadata:

      labels:

        app: {{ .Values.app_name }}  # по вот этому лейблу репликасет цепляет под

#       name_elk: elk-log-{{ .Values.namespace }} #это имя будет записываться в EFK

    spec:

      containers:

        - image: "{{ .Values.image_app.repository }}:{{ .Values.image_app.tag }}"

          imagePullPolicy: Always

          name: {{ .Values.app_name }}

          ports:

            - containerPort: {{ .Values.deployment_port }}

# тут начинаются проверки по доступности

#          readinessProbe: # проверка готово ли приложение

#            failureThreshold: 3 #указывает количество провалов при проверке

#            httpGet:  # по сути дёргает курлом на 8080 порт

#              path: /monitoring

#              port: 8080

#            periodSeconds: 20 #как часто должна проходить проверка (в секундах)

#            successThreshold: 1 #сбрасывает счётчик неудач, т.е. при 3х проверках если 1 раз успешно прошло, то счётчик сбрасывается и всё ок

#            timeoutSeconds: 1 #таймаут на выполнение пробы 1 секунда

#            initialDelaySeconds: 120

#          livenessProbe: #проверка на жизнь приложения, живо ли оно

#            failureThreshold: 3

#            tcpSocket:

#              port: 8888

#            httpGet:

#              path: /monitoring

#              port: 8080

#            periodSeconds: 20

#            successThreshold: 1

#            timeoutSeconds: 1

#            initialDelaySeconds: 10 #означает что первую проверку надо сделать только после 10 секунд



# тут начинается описание лимитов для пода

          resources:

            requests: #количество ресурсов которые резервируются для pod на ноде

              cpu: {{ .Values.requests_cpu_app }}

              memory: {{ .Values.requests_memory_app }}

            limits: #количество ресурсов которые pod может использовать(верхняя граница)

              cpu: {{ .Values.limits_cpu_app }}

              memory: {{ .Values.limits_memory_app }}

      imagePullSecrets:

      - name: {{ .Values.secret_name_gitlab_login }}





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/templates/service.yaml




---

kind: Service

apiVersion: v1

metadata:

  name: {{ .Values.service_name }}

  namespace: {{ .Values.namespace }}

spec:

  selector:

    app: {{ .Values.app_name }}

  ports:

    - protocol: TCP

      port: {{ .Values.service_port }}

      targetPort: {{ .Values.deployment_port }}





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/templates/ingress.yaml




---

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: {{ .Values.ingress_name }}

  namespace: {{ .Values.namespace }}

spec:

  rules:

  - host: {{ .Values.domain }}  #тут указывается наш домен

    http:

      paths:

     # - path: "/ui/test"

     #   backend:

     #     serviceName: {{ .Values.service_name }}

     #     servicePort: 8083

      - path: "/"

        backend:

          serviceName: {{ .Values.service_name }}

          servicePort: {{ .Values.service_port }}





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/Chart.yaml




apiVersion: v2

name: cache-builder

description: A Helm chart for Kubernetes

type: application

version: 1.0.0

appVersion: 1.0.0





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-mrunner.yaml




#неймспейс в котором запускаемся

namespace: test-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-mrunner



deployment_port: 8888

service_port: 8888



#имя сервиса

service_name: service-cache-builder-mrunner



#имя ingress

ingress_name: ingress-cache-builder-mrunner



#указываем наш домен по которому будет слушать ingress

domain: cb-mrunner.prod.test.local



#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-mrunner



#имя образа для сервиса

image_app:

  repository: gitnexus.test.local:4567/cache-builder/cache-builder/mrunner

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 100m

requests_memory_app: 500Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 1000Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder




[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-node.yaml




#неймспейс в котором запускаемся

namespace: test-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-node



deployment_port: 7777

service_port: 7777



#имя сервиса

service_name: service-cache-builder-node



#имя ingress

ingress_name: ingress-cache-builder-node



#указываем наш домен по которому будет слушать ingress

domain: cbapi.prod.test.local



#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-node



#имя образа для сервиса

image_app:

  repository: gitnexus.test.local:4567/cache-builder/cache-builder/node

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 100m

requests_memory_app: 500Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 1000Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-scheduler.yaml




#неймспейс в котором запускаемся

namespace: test-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-scheduler



deployment_port: 7777

service_port: 7777



#имя сервиса

service_name: service-cache-builder-scheduler



#имя ingress

ingress_name: ingress-cache-builder-scheduler





#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-scheduler



#имя образа для сервиса

image_app:

  repository: gitnexus.test.local:4567/cache-builder/cache-builder/scheduler

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 100m

requests_memory_app: 500Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 1000Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-web.yaml




#неймспейс в котором запускаемся

namespace: test-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-web



deployment_port: 8080

service_port: 8080



#имя сервиса

service_name: service-cache-builder-web



#имя ingress

ingress_name: ingress-cache-builder-web



#указываем наш домен по которому будет слушать ingress

domain: cb.prod.test.local



#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-web



#имя образа для сервиса

image_app:

  repository: gitnexus.test.local:4567/cache-builder/cache-builder/web

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 100m

requests_memory_app: 500Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 1000Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder





далее показываю .gitlab-ci.yml при котором у меня возникли ошибки:




variables:

  NAMESPACE: test-cache-builder

  kubeconfig_url: /home/gitlab-runner/.kube/config 

  PWD: $(pwd)





stages:

  - deploy_to_kuber



.autorizate_to_gitlab: &autorizate_to_gitlab |

    docker logout $CI_REGISTRY

    docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

.git_tag_variable: &git_tag_variable |

    git fetch --tags

    export TAG=$(git describe --tags --abbrev=0)

    echo $TAG





deploy_to_kuber:

  stage: deploy_to_kuber

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - *autorizate_to_gitlab

    - *git_tag_variable

    - mkdir -p `echo $kubeconfig_url | awk -F '/' 'sub(FS $NF,x)'`

    - echo $kubeconfig | base64 -d > $kubeconfig_url

    - kubectl create namespace $NAMESPACE --kubeconfig=$kubeconfig_url || echo "all OK - namespace =  $NAMESPACE alredy exist"

    - kubectl --kubeconfig=$kubeconfig_url delete secret docker-login-$CI_PROJECT_NAME -n $NAMESPACE || echo "error secret not exist"

    - kubectl --kubeconfig=$kubeconfig_url create secret docker-registry docker-login-$CI_PROJECT_NAME --docker-server=$CI_REGISTRY --docker-username=$CI_REGISTRY_USER --docker-password=$CI_REGISTRY_PASSWORD --docker-email=$GITLAB_USER_EMAIL -n $NAMESPACE

  script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-web  helm/

      --values helm/values-web.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME



    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-mrunner  helm/

      --values helm/values-mrunner.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME



    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-node  helm/

      --values helm/values-node.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME



    - helm  upgrade --install --atomic --timeout 3m 

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-scheduler  helm/

      --values helm/values-scheduler.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME



  after_script:

    - *git_tag_variable

    - kubectl --kubeconfig=$kubeconfig_url get pod -n $NAMESPACE

    - kubectl --kubeconfig=$kubeconfig_url get service -n $NAMESPACE

    - kubectl --kubeconfig=$kubeconfig_url get ingress -n $NAMESPACE

    - rm -rf $kubeconfig_url




переменная kubeconfig является токеном кубернетеса добавленным в переменные  проекта:





при создании секрета
kubectl —kubeconfig=$kubeconfig_url create secret docker-registry docker-login-$CI_PROJECT_NAME —docker-server=$CI_REGISTRY —docker-username=$CI_REGISTRY_USER —docker-password=$CI_REGISTRY_PASSWORD —docker-email=$GITLAB_USER_EMAIL -n $NAMESPACE




под которым дальше будет выкачиваться образ из registry я использовал встроенные переменные:
CI_REGISTRY_USER
CI_REGISTRY_PASSWORD
при их использовании не выкачивается один из образов, вот вывод describe этого pod




Events:

  Type     Reason     Age               From                           Message

  ----     ------     ----              ----                           -------

  Normal   Scheduled  <unknown>         default-scheduler              Successfully assigned test-cache-builder/deployment-cache-builder-node-6f5c998487-gvhbc to prod-srv-kubeworker1

  Normal   BackOff    13s               kubelet, prod-srv-kubeworker1  Back-off pulling image "gitnexus.test.local:4567/cache-builder/cache-builder/node:v14"

  Warning  Failed     13s               kubelet, prod-srv-kubeworker1  Error: ImagePullBackOff

  Normal   Pulling    1s (x2 over 14s)  kubelet, prod-srv-kubeworker1  Pulling image "gitnexus.test.local:4567/cache-builder/cache-builder/node:v14"

  Warning  Failed     1s (x2 over 14s)  kubelet, prod-srv-kubeworker1  Failed to pull image "gitnexus.test.local:4567/cache-builder/cache-builder/node:v14": rpc error: code = Unknown desc = Error response from daemon: Get http://gitnexus.test.local:4567/v2/cache-builder/cache-builder/node/manifests/v14: unauthorized: HTTP Basic: Access denied

  Warning  Failed     1s (x2 over 14s)  kubelet, prod-srv-kubeworker1  Error: ErrImagePull





вылетает ошибка:
unauthorized: HTTP Basic: Access denied
хотя под этими учётными данными login проходит нормально.




нашёл следующие решения:




1.Костыльное — это добавить sleep между helm




variables:

  NAMESPACE: megacom-cache-builder

  kubeconfig_url: /home/gitlab-runner/.kube/config

  PWD: $(pwd)





stages:

  - deploy_to_kuber



.autorizate_to_gitlab: &autorizate_to_gitlab |

    docker logout $CI_REGISTRY

    docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

.git_tag_variable: &git_tag_variable |

    git fetch --tags

    export TAG=$(git describe --tags --abbrev=0)

    echo $TAG





deploy_to_kuber:

  stage: deploy_to_kuber

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - *autorizate_to_gitlab

    - *git_tag_variable

    - mkdir -p `echo $kubeconfig_url | awk -F '/' 'sub(FS $NF,x)'`

    - echo $kubeconfig | base64 -d > $kubeconfig_url

    - kubectl create namespace $NAMESPACE --kubeconfig=$kubeconfig_url || echo "all OK - namespace =  $NAMESPACE alredy exist"

    - kubectl --kubeconfig=$kubeconfig_url delete secret docker-login-$CI_PROJECT_NAME -n $NAMESPACE || echo "error secret not exist"

    - echo "CI_PROJECT_NAME = $CI_PROJECT_NAME"

    - echo "CI_REGISTRY = $CI_REGISTRY"

    - echo "CI_REGISTRY_USER = $CI_REGISTRY_USER"

    - echo "CI_REGISTRY_PASSWORD = $CI_REGISTRY_PASSWORD"

    - echo "GITLAB_USER_EMAIL = $GITLAB_USER_EMAIL"

    - echo "gitlab-ci-token = $gitlab-ci-token"

    - kubectl --kubeconfig=$kubeconfig_url create secret docker-registry docker-login-$CI_PROJECT_NAME --docker-server=$CI_REGISTRY --docker-username=$CI_REGISTRY_USER --docker-password=$CI_REGISTRY_PASSWORD --docker-email=$GITLAB_USER_EMAIL -n $NAMESPACE

    - sleep 5

  script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-web  helm/

      --values helm/values-web.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

    - sleep 15



    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-mrunner  helm/

      --values helm/values-mrunner.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

    - sleep 20



    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-node  helm/

      --values helm/values-node.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

    - sleep 25



    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-scheduler  helm/

      --values helm/values-scheduler.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

    - sleep 30



  after_script:

    - *git_tag_variable

    - kubectl --kubeconfig=$kubeconfig_url get pod -n $NAMESPACE

    - kubectl --kubeconfig=$kubeconfig_url get service -n $NAMESPACE

    - kubectl --kubeconfig=$kubeconfig_url get ingress -n $NAMESPACE

    - rm -rf $kubeconfig_url





2.Создать деплой токен — думаю оно правильнее:




Создаю Deploy Tokens






меняем немного .gitlab-ci.yml




variables:

  NAMESPACE: test-cache-builder

  kubeconfig_url: /home/gitlab-runner/.kube/config 

  PWD: $(pwd)

 

stages:

  - deploy_to_kuber

  - helm_install

  - delete_kubeconfig

 

.autorizate_to_gitlab: &autorizate_to_gitlab |

    docker logout $CI_REGISTRY

    docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

.git_tag_variable: &git_tag_variable |

    git fetch --tags

    export TAG=$(git describe --tags --abbrev=0)

    echo $TAG

.info: &info |

    kubectl --kubeconfig=$kubeconfig_url get pod -n $NAMESPACE

    kubectl --kubeconfig=$kubeconfig_url get service -n $NAMESPACE

    kubectl --kubeconfig=$kubeconfig_url get ingress -n $NAMESPACE

 

deploy_to_kuber:

  stage: deploy_to_kuber

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - *autorizate_to_gitlab

    - *git_tag_variable

    - mkdir -p `echo $kubeconfig_url | awk -F '/' 'sub(FS $NF,x)'`

    - echo $kubeconfig | base64 -d > $kubeconfig_url

    - kubectl create namespace $NAMESPACE --kubeconfig=$kubeconfig_url || echo "all OK - namespace =  $NAMESPACE alredy exist"

    - kubectl --kubeconfig=$kubeconfig_url delete secret docker-login-$CI_PROJECT_NAME -n $NAMESPACE || echo "error secret not exist"

    - kubectl --kubeconfig=$kubeconfig_url create secret docker-registry docker-login-$CI_PROJECT_NAME --docker-server="$CI_REGISTRY" --docker-username="$CI_DEPLOY_USER" --docker-password="$CI_DEPLOY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" -n $NAMESPACE

  script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

 

helm_install-node:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *autorizate_to_gitlab

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-node  helm/

      --values helm/values-node.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *git_tag_variable

    - *info





helm_install-scheduler:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *autorizate_to_gitlab

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-scheduler  helm/

      --values helm/values-scheduler.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *git_tag_variable

    - *info





helm_install-mrunner:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *autorizate_to_gitlab

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-mrunner  helm/

      --values helm/values-mrunner.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *git_tag_variable

    - *info





helm_install-web:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *autorizate_to_gitlab

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE test-$CI_PROJECT_NAME-web  helm/

      --values helm/values-web.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *git_tag_variable

    - *info



delete_kubeconfig:

  stage: delete_kubeconfig

  tags:

    - runer-gitnexus-shell

  only:

    - master

  script:

    - rm -rf $kubeconfig_url





этим самым мы получаем pipeline в следующем виде:





рассмотрим что поменяли, старый вариант:




kubectl —kubeconfig=$kubeconfig_url create secret docker-registry docker-login-$CI_PROJECT_NAME —docker-server=$CI_REGISTRY —docker-username=$CI_REGISTRY_USER —docker-password=$CI_REGISTRY_PASSWORD —docker-email=$GITLAB_USER_EMAIL -n $NAMESPACE




новый вариант:




kubectl —kubeconfig=$kubeconfig_url create secret docker-registry docker-login-$CI_PROJECT_NAME —docker-server=»$CI_REGISTRY» —docker-username=»$CI_DEPLOY_USER» —docker-password=»$CI_DEPLOY_PASSWORD» —docker-email=»$GITLAB_USER_EMAIL» -n $NAMESPACE




как видим мы изменили CI_REGISTRY_USER  на CI_DEPLOY_USER    и CI_REGISTRY_PASSWORD  на CI_DEPLOY_PASSWORD




в таком варианте стало нормально выкачиваться.




3.Использование условий




Теперь поправим шаблоны, чтобы для некоторых проектов например не ставился ingress, а для других использовались различные  livenessProbe и readinessProbe




правим шаблоны, приводя их к следующему виду:




[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/templates/deployment.yaml




---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: {{ .Values.deployment_name }}

  namespace: {{ .Values.namespace }}

  labels:

    app: {{ .Values.app_name }}



spec:

  replicas: {{ .Values.replica_number }}

  selector:

    matchLabels:

      app: {{ .Values.app_name }} # по вот этому лейблу репликасет цепляет под

# тут описывается каким мокаром следует обновлять поды

  strategy:

    rollingUpdate:

      maxSurge: 1  # указывает на какое количество реплик можно увеличить

      maxUnavailable: 1 # указывает на какое количество реплик можно уменьшить

#т.е. в одно время при обновлении, будет увеличено на один (новый под) и уменьшено на один (старый под)

    type: RollingUpdate

## тут начинается описание контейнера

  template:

    metadata:

      labels:

        app: {{ .Values.app_name }}  # по вот этому лейблу репликасет цепляет под

#       name_elk: elk-log-{{ .Values.namespace }} #это имя будет записываться в ELK

    spec:

      containers:

        - image: "{{ .Values.image_app.repository }}:{{ .Values.image_app.tag }}"

          imagePullPolicy: Always

          name: {{ .Values.app_name }}

          ports:

            - containerPort: {{ .Values.deployment_port }}

# тут начинаются проверки по доступности

          {{- if .Values.readinessProbe.enabled }}

          readinessProbe: # проверка готово ли приложение

            failureThreshold: {{ .Values.readinessProbe.failureThreshold }} #указывает количество провалов при проверке

            httpGet:  # по сути дёргает курлом на 8080 порт

              path: {{ .Values.readinessProbe.path }}

              port: {{ .Values.readinessProbe.port }}

            periodSeconds: {{ .Values.readinessProbe.periodSeconds }}  #как часто должна проходить проверка (в секундах)

            successThreshold: {{ .Values.readinessProbe.successThreshold }}  #сбрасывает счётчик неудач, т.е. при 3х проверках если 1 раз успешно прошло, то счётчик сбрасывается и всё ок

            timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}  #таймаут на выполнение пробы 1 секунда

            initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }}

          {{- end}}

          {{- if .Values.livenessProbe.enabled }}

          livenessProbe: #проверка на жизнь приложения, живо ли оно

            failureThreshold: {{ .Values.livenessProbe.failureThreshold }}

            httpGet:

              path: {{ .Values.livenessProbe.path }}

              port: {{ .Values.livenessProbe.port }}

            periodSeconds: {{ .Values.livenessProbe.periodSeconds }}

            successThreshold: {{ .Values.livenessProbe.successThreshold }}

            timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}

            initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}  #означает что первую проверку надо сделать только после 10 секунд

          {{- end}}

# тут начинается описание лимитов для пода

          resources:

            requests: #количество ресурсов которые резервируются для pod на ноде

              cpu: {{ .Values.requests_cpu_app }}

              memory: {{ .Values.requests_memory_app }}

            limits: #количество ресурсов которые pod может использовать(верхняя граница)

              cpu: {{ .Values.limits_cpu_app }}

              memory: {{ .Values.limits_memory_app }}

      imagePullSecrets:

      - name: {{ .Values.secret_name_gitlab_login }}





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/templates/ingress.yaml




---

{{- if .Values.ingress.enabled }}

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: {{ .Values.ingress.ingress_name }}

  namespace: {{ .Values.ingress.namespace }}

spec:

  rules:

  - host: {{ .Values.ingress.domain }}  #тут указывается наш домен

    http:

      paths:

     # - path: "/ui/test"

     #   backend:

     #     serviceName: {{ .Values.service_name }}

     #     servicePort: 8083

      - path: "/"

        backend:

          serviceName: {{ .Values.service_name }}

          servicePort: {{ .Values.service_port }}

{{- end}}





сервис я оставил без изменений:




[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/templates/service.yaml




---

kind: Service

apiVersion: v1

metadata:

  name: {{ .Values.service_name }}

  namespace: {{ .Values.namespace }}

spec:

  selector:

    app: {{ .Values.app_name }}

  ports:

    - protocol: TCP

      port: {{ .Values.service_port }}

      targetPort: {{ .Values.deployment_port }}





ну и правим наши values
[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-mrunner.yaml




#неймспейс в котором запускаемся

namespace: megacom-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-mrunner



deployment_port: 8888

service_port: 8888



#имя сервиса

service_name: service-cache-builder-mrunner





ingress:

  enabled: true

  #имя ingress

  ingress_name: ingress-cache-builder-mrunner

  #указываем наш домен по которому будет слушать ingress

  domain: cb-mrunner.prod.megacom.local



#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-mrunner



#имя образа для сервиса

image_app:

  repository: gitnexus.megacom.local:4567/cache-builder/cache-builder/mrunner

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 50m

requests_memory_app: 60Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 500Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder



#включаем или выключаем livenessProbe readinessProbe

readinessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 20



livenessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 10




[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-node.yaml




#неймспейс в котором запускаемся

namespace: megacom-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-node



deployment_port: 7777

service_port: 7777



#имя сервиса

service_name: service-cache-builder-node





ingress:

  enabled: true

  #имя ingress

  ingress_name: ingress-cache-builder-node

  #указываем наш домен по которому будет слушать ingress

  domain: cbapi.prod.megacom.local



#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-node



#имя образа для сервиса

image_app:

  repository: gitnexus.megacom.local:4567/cache-builder/cache-builder/node

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 50m

requests_memory_app: 60Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 500Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder



#включаем или выключаем livenessProbe readinessProbe

readinessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 20



livenessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 10





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-scheduler.yaml




#неймспейс в котором запускаемся

namespace: megacom-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-scheduler



deployment_port: 7777

service_port: 7777



#имя сервиса

service_name: service-cache-builder-scheduler





ingress:

  enabled: false

  #имя ingress

  ingress_name:

  #указываем наш домен по которому будет слушать ingress

  domain:





#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-scheduler



#имя образа для сервиса

image_app:

  repository: gitnexus.megacom.local:4567/cache-builder/cache-builder/scheduler

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 50m

requests_memory_app: 60Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 500Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder



#включаем или выключаем livenessProbe readinessProbe

readinessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 20



livenessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 10





[root@prod-vsrv-kubemaster1 cache-builder]# cat helm/values-web.yaml




#неймспейс в котором запускаемся

namespace: megacom-cache-builder



#имя деплоймента

deployment_name: deployment-cache-builder-web



deployment_port: 8080

service_port: 8080



#имя сервиса

service_name: service-cache-builder-web





ingress:

  enabled: true

  #имя ingress

  ingress_name: ingress-cache-builder-web

  #указываем наш домен по которому будет слушать ingress

  domain: cb.prod.megacom.local



#количество реплик деплоймента минимальное количество

replica_number: 1



#имя лейбла сервиса

app_name: cache-builder-web



#имя образа для сервиса

image_app:

  repository: gitnexus.megacom.local:4567/cache-builder/cache-builder/web

  tag: "v5"



#количество ресурсов которые резервируются для pod на ноде проц и оперативка

requests_cpu_app: 50m

requests_memory_app: 60Mi

#количество ресурсов которые pod может использовать(верхняя граница)

limits_cpu_app: 400m

limits_memory_app: 500Mi



#имя секрета под которым воркер ноды будут выкачивать образа из gitlab

secret_name_gitlab_login: docker-login-cache-builder



#включаем или выключаем livenessProbe readinessProbe

readinessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 20



livenessProbe:

  enabled: false

  failureThreshold: 3

  path: /monitoring

  port: 8080

  periodSeconds: 20

  successThreshold: 1

  timeoutSeconds: 1

  initialDelaySeconds: 10





[root@prod-vsrv-kubemaster1 cache-builder]# cat .gitlab-ci.yml




остаётся без изменений:




variables:

  NAMESPACE: megacom-cache-builder

  kubeconfig_url: /home/gitlab-runner/.kube/config

  PWD: $(pwd)



stages:

  - deploy_to_kuber

  - helm_install

  - delete_kubeconfig





.autorizate_to_gitlab: &autorizate_to_gitlab |

    docker logout $CI_REGISTRY

    docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

.git_tag_variable: &git_tag_variable |

    git fetch --tags

    export TAG=$(git describe --tags --abbrev=0)

    echo $TAG

.info: &info |

    kubectl --kubeconfig=$kubeconfig_url get pod -n $NAMESPACE

    kubectl --kubeconfig=$kubeconfig_url get service -n $NAMESPACE

    kubectl --kubeconfig=$kubeconfig_url get ingress -n $NAMESPACE



deploy_to_kuber:

  stage: deploy_to_kuber

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - mkdir -p `echo $kubeconfig_url | awk -F '/' 'sub(FS $NF,x)'`

    - echo $kubeconfig | base64 -d > $kubeconfig_url

    - kubectl create namespace $NAMESPACE --kubeconfig=$kubeconfig_url || echo "all OK - namespace =  $NAMESPACE alredy exist"

    - kubectl --kubeconfig=$kubeconfig_url delete secret docker-login-$CI_PROJECT_NAME -n $NAMESPACE || echo "error secret not exist"

    - kubectl --kubeconfig=$kubeconfig_url create secret docker-registry docker-login-$CI_PROJECT_NAME --docker-server="$CI_REGISTRY" --docker-username="$CI_DEPLOY_USER" --docker-password="$CI_DEPLOY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" -n $NAMESPACE

  script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE



helm_install-node:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-node  helm/

      --values helm/values-node.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *info





helm_install-scheduler:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-scheduler  helm/

      --values helm/values-scheduler.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *info





helm_install-mrunner:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-mrunner  helm/

      --values helm/values-mrunner.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *info





helm_install-web:

  stage: helm_install

  tags:

    - runer-gitnexus-shell

  only:

    - master

  before_script:

    - kubectl --kubeconfig=$kubeconfig_url get secret -n $NAMESPACE

  script:

    - *git_tag_variable

    - helm  upgrade --install --atomic --timeout 3m

      --kubeconfig=$kubeconfig_url -n $NAMESPACE megacom-$CI_PROJECT_NAME-web  helm/

      --values helm/values-web.yaml

      --set-string image_app.tag=$TAG

      --set-string namespace=$NAMESPACE

      --set-string secret_name_gitlab_login=docker-login-$CI_PROJECT_NAME

  after_script:

    - *info



delete_kubeconfig:

  stage: delete_kubeconfig

  tags:

    - runer-gitnexus-shell

  only:

    - master

  script:

    - rm -rf $kubeconfig_url

    - *info




Источник: https://sidmid.ru/kubernetes-gitlab-ci-cd-http-basic-access-denied/



Kubernetes — создать политику безопасности — RBAC

Политика безопасности пода Kubernetes – это ресурс, который контролирует безопасность спецификации этого пода.




Используя определение объекта PodSecurityPolicy, вы можете управлять такими вещами, как:




  • Возможность запуска привилегированных контейнеров



  • Повышение привилегий



  • Доступ к типам томов



  • Доступ к файловым системам хоста



  • Использование хост-сети




Как создать политику безопасности пода Kubernetes
Давайте создадим политику безопасности пода Kubernetes, которая предотвращает создание привилегированных модулей и контролирует доступ к томам.
Во-первых, мы должны создать файл YAML.
В терминале введите команду:
nano psp.yaml
В этот файл вставьте следующее:




apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

  name: psp

spec:

  privileged: false

  seLinux:

    rule: RunAsAny

  supplementalGroups:

    rule: RunAsAny

  runAsUser:

    rule: RunAsAny

  fsGroup:

    rule: RunAsAny

  volumes:

  - '*'




В этом файле мы запрещаем создание привилегированных модулей с помощью строки:




privileged: false




Мы также разрешаем следующее (через правило RunAsAny):




  • SeLinux – позволяет любому пользователю управлять SELinux в модулях.



  • Linux groups – дополнительные группы



  • runAsUser – позволяет пользователям запускать точки входа в контейнер с другим именем пользователя



  • fsGroup – тома, которые поддерживают управление собственностью




Сохраните и закройте файл.




Теперь мы должны применить политику.




Это делается с помощью команды:




kubectl apply -f psp.yaml




Вывод:




podsecurity.policy/psp created




В любой момент вы можете изменить файл YAML и выполнить ту же команду, чтобы переконфигурировать политику.




Убедитесь, что ваша политика доступна, введя команду:




kubectl get psp




В выводе будут перечислены детали:




Created with GIMP




Как назначить политику безопасности Kubernetes поду




Теперь, когда вы создали свою политику, возникает законный вопрос как ее назначить?




Это делается с помощью управления доступом на основе ролей (RBAC).




Создайте конфигурацию RBAC для политики с помощью команды:




nano rbac-psp.yaml




В этот файл вставьте следующее:




kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: psp:psp

rules:

- apiGroups:

  - extensions

  resources:

  - podsecuritypolicies

  resourceNames:

  - psp

  verbs:

  - use

---



kind: ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: psp:psp

subjects:

- kind: Group

  name: system:authenticated

  apiGroup: rbac.authorization.k8s.io

roleRef:

  kind: ClusterRole

  name: psp:psp

  apiGroup: rbac.authorization.k8s.io




Приведенный выше файл создаст роль кластера с именем psp, которая может использовать нашу новую политику, которую мы назвали psp.




Это также создаст привязку роли на уровне кластера, которая предоставляет доступ к роли psp: psp каждому аутентифицированному пользователю.




Сохраните и закройте файл.




Создайте эту политику с помощью команды:




kubectl apply -f rbac-psp.yaml




Теперь мы создали политику и контроль RBAC.




Давайте выясним, сможем ли мы теперь использовать эту новую политику.




Введите команду:




kubectl auth can-i use psp/psp




Выход должен сказать «yes».




Конечно, система должна сказать «yes», так как я пользователь с правами администратора.




Но что, если мы проверим это с другим пользователем?




Сделайте это с помощью команды:




kubectl auth can-i use psp/psp




Теперь вы должны увидеть «no» в ответе.




Вы только что создали политику безопасности пода Kubernetes, присвоили ей RBAC и протестировали ее, чтобы убедиться, что политика действительно работает.




Источник: https://sidmid.ru/kubernetes-создать-политику-безопасности-rbac/



2023-01-02T05:56:31
DevOps