Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Kubectl

KubeHelper -упростите множество повседневных задач с Kubernetes через веб-интерфейс

15.02.2021 18:22:10 | Автор: admin

KubeHelper - это продукт который упрощает решение многих ежедневных задач связанных с управлением Kubernetes через веб интерфейс. Поиск, анализ, запуск команд, cron jobs, репорты, фильтры, git синхронизация и многое другое.

KubeHelper это не ещё одна попытка отобразить Kubernetes API в графическом интерфейсе. Не попытка заменить Lens, официальный Dashboard или другие продукты. Это мой скромный вклад в Kubernetes Open Source сообщество. Проект не имеет какого-то узко специализированного направления и содержит довольно много различных функций которые будут полезны в ежедневной работе с Kubernetes.

Итак, го к описанию и возможностям.

Некоторые термины тяжело переводить, поэтому я вместо непонятного/корявого перевода буду писать английское слово.

Мотивация

Считаю Kubernetes замечательным и революционным продуктом. Много лет изучаю и пользуюсь, но очень часто возникала надобность иметь под рукой много различных функций и команд. Каждый раз набирать в командной строке длинные команды, искать в истории, прописывать aliases и так д. конечно же, можно, но очень часто нет возможности залогинится в консоль, или не сохранилась история, или новый хост. Или много других причин.

На некоторых фирмах жёсткие правила и очень часто чтоб залогинится в консоль нужно пробрасывать несколько ssh тоннелей. Или вообще очень ограниченный доступ к консоли.

Многие десктопные клиенты требуют сертификата для коннекта к серверу. И держать сертификат от кластера на локальной машине, не 100% безопасно.

А что если нет возможности проинсталлировать клиент на локальной машине, снова же надо создавать aliasesили копировать команды из сниппетов. Очень часто вижу, что люди ищут те или иные команды, выходят статьи с несколькими различными командами, но их сотни, а вариаций тысячи. Конечно же все эти задачи можно автоматизировать и наверняка каждый пользователь/администратор кластера уже тем или иным образом решил для себя эти задачи, но я уверен что есть и такие которе ещё этого сделалась не успели.

Та же история и с поиском, иногда нужно знать где нужно искать, а если ресурсов много, то не так просто найти то что нужно. Писать огромную команду не хочется, поэтому и решил сделать поиск по многим часто используемым ресурсам. Как итог появился KubeHelper с идеями которые приходили во время разработки.

Также постарался на ресурсы посмотреть с другой стороны. Многие готовые решения показывают ресурсы по namespace, ещё несколько полезных функций и на этом гибкость веб интерфейсов заканчивается и чтоб сделать что-то отличное чем просто показать список ресурсов в namespace, снова же приходится обращаться к консоли. Например group labels, find selector, view RBACs и так д

Тут у меня и возникла идея помочь сообществу организовать много команд в едином интерфейсе, установить kubectl, плагины, утилиты и сделать для пользования командной строкой графический web интерфейс. Внедрить другие функции которые будут полезны в ежедневной работе с Kubernetes кластером. Внести свой скромный вклад в Open Source сообщество. Ну и конечно же чтоб еще лучше познать и узнать Kubernetes. Вот что из этого получилось.

Общие принципы и понятия

На данный момент я подготовил 3 возможности инсталляции: kubectl, Helm, Terraform. Посмотреть инсталляции и настроить их можно здесь. Позже добавлю в публичный Helm Chart Repository и в Terraform Registry.

KubeHelper может быть очень мощным помощником в ежедневной работе с кластером, всё зависит от того сколько прав вы ему предоставите.

По умолчанию KubeHelper устанавливается с правами на чтение и просмотр. (get, list). Поэтому с уверенностью можно сказать, что вы ничего не поломаете используя его у себя в кластере. Но при инсталляции вы можете изменить ClusterRole под свои нужды, аж до статуса cluster-admin. Подробная настройка в Wiki.

Конфигурация и команды хранятся в формате TOML. Как по мне, этот формат очень удобен для такого рода задач. Снова же, подробное описание и как всё работает, вы можете почитать в Wiki.

Возможности и интерфейс

Dashboard

Здесь собрана общая информация о кластере. Общее количество процессорного времени, хостов(нод), памяти и так д. Отображена общая техническая информация о хосте(ноде), количество, имена и размеры docker images.

Search

Часто приходится искать что-то в кластере для этого нужно знать где искать и часто писать не тривиальные скрипты или команды. Поиск по всему кластеру или в определённой namespace по ключевому слову и выбранным ресурсам решает эту задачу.

Принцип довольно прост и интуитивен. Выбираем namespace(all = all namespaces) в котором мы хотим найти ресурсы по ключевому слову. Выбираем ресурсы нажимаем поиск, применяем фильтры.Также при нажатии на кнопку в столбце "Raws" можно посмотреть ресурс в различных форматахJava POJO, YAML или JSON.

Подробное описание всех функций и принцип работы вы можете почитать в Wiki.

Ips and Ports

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

Security

Этот раздел состоит из 6 секций. Каждая секция имеет одни и те же кнопки для выбора namespace и поиска соответственных ресурсов в ней.

Также при нажатии на кнопку в столбце "Raws" можно посмотреть ресурс в различных форматахJava POJO, YAML или JSON.

Секция "Roles": Поиск ролей в отдельном namespace или во всех namespaces. Просмотр subjects и role rules для каждого verb.Фильтр и группировка результатов.

Секция"RBAC: Построение матрицы доступа к ресурсам на основании ролей и правил.Фильтр и группировка результатов.

Секция"Pod Security Contexts: ПоказатьPodSecurityContext объекты в отдельной namespace или во всех namespaces.

Секция"Container Security Contexts": Показать ContainerSecurityContext объекты в отдельной namespace или во всех namespaces.

Секция"Service Accounts": Показать"Service Accounts" в отдельном namespace или во всех namespaces.

Секция"Pod Security Policies": Показать"Pod Security Policies" в отдельном namespace или во всех namespaces.

Labels Annotations Selectors

Поискlabels, selectors и annotations по выделенным ресурсам. Фильтр и группирование результатов.

Вкладка Grouped: На основании поиска labels, selectors и annotations будут сагрегированы и сгруппированы

Commands

Идея секции Commands сделатьKubeHelper гибко настраиваемый для каждого пользователя. Каждый пользователь может исполнять свои kubectl и shell команды с различных консолей. Просматривать результаты исполнения. Экспортировать свои подборки команд с git репозитория и многое другое. KubeHelper уже имеет много готовых к использованию команд.

Секция "Commands": Окно разделено на 3 части, команды которые можно фильтровать и искать. Окно редактирования выделенной команды и окно вывода результатов исполнения.

Секция "Management": В этой секции вы имеете возможность редактировать и создавать свои команды, а также просматривать уже имеющиеся команды.

СекцияHistory: В этой секции вы можете посмотреть все исполненные команды и результат их исполнения. Для удобности, история сохраняется по дням. Присутствует несколько удобных фильтров.

Cron Jobs

Идея секции Cron Jobs: сделать исполнение регулярных задач, проверки безопасности, построение и просмотр репортов исполнения команд - более простым и тривиальным заданием.

Секция "Jobs": Окно разделено на 3 части, команды которые можно фильтровать и искать. Окно редактирования выделенной команды и поля для создания новой cron job. Таблица со списком активных и остановленных cron jobs, кнопки управления.

Секция"Reports": Для каждой "cron job создаётся папка в которую по дням будут сохраняться выполненияcron jobs.Присутствует несколько удобных фильтров.

Configurations

Идея секции Configurations дать возможность пользователю синхронизировать свой конфигурационный файл с git также быстрее определить или изменить нужные cron jobs. Здесь же находятся функции для управление пользовательским репозиторием. Подробное описане можно почитать в Wiki.

Versions

ВKubeHelper уже предустановлен kubectl, огромное количество плагинов, утилит, командных оболочек и так д.. Эта вкладка отображает весь список предустановленных программ, их версии и другую информацию.

Вопрос к дочитавшим:

Какие новые функции вы бы добавили в первую очередь? Какая новая функция сделает вашу ежедневную работу легче?

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

Достаточно оставить комментарий с приоритетом в виде номеров или своё предложение.

Для предложения новой функции есть соответствующий Issue.

P.S.1 Буду рад репосту, звёздочке на GitHub. Пользуйтесь, делитесь информацией с коллегами, друзьями, знакомыми.

P.S.2 Буду рад желающим помогать развивать проект. На начальных стадиях особенно людям которые помогут сделать дизайн красивее. В первую очередь я работал над функциональностью.

Всем спасибо!

Подробнее..
Категории: It-инфраструктура , Kubernetes , Open source , Devops , Terraform , Серверная оптимизация , Helm , Kubectl , Tool

Перевод Минимально жизнеспособный Kubernetes

31.07.2020 20:21:00 | Автор: admin
Перевод статьи подготовлен в преддверии старта курса DevOps практики и инструменты.




Если вы это читаете, вероятно, вы что-то слышали о Kubernetes (а если нет, то как вы здесь оказались?) Но что же на самом деле представляет собой Kubernetes? Это Оркестрация контейнеров промышленного уровня? Или Cloud-Native Operating System? Что вообще это значит?

Честно говоря, я не уверен на 100%. Но думаю интересно покопаться во внутренностях и посмотреть, что на самом деле происходит в Kubernetes под его многими слоями абстракций. Так что ради интереса, давайте посмотрим, как на самом деле выглядит минимальный кластер Kubernetes. (Это будет намного проще, чем Kubernetes The Hard Way.)

Я полагаю, что у вас есть базовые знания Kubernetes, Linux и контейнеров. Все, о чем мы здесь будем говорить предназначено только для исследования/изучения, не запускайте ничего из этого в продакшене!

Обзор


Kubernetes содержит много компонент. Согласно википедии, архитектура выглядит следующим образом:



Здесь показано, по крайней мере, восемь компонент, но большинство из них мы проигнорируем. Я хочу заявить, что минимальная вещь, которую можно обоснованно назвать Kubernetes, состоит из трех основных компонент:

  • kubelet
  • kube-apiserver (который зависит от etcd его базы данных)
  • среда выполнения контейнера (в данном случае Docker)


Давайте посмотрим, что о каждом из них говорится в документации (рус., англ.). Сначала kubelet:

Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.

Звучит достаточно просто. Что насчет среды выполнения контейнеров (container runtime)?

Среда выполнения контейнера это программа, предназначенная для выполнения контейнеров.

Очень информативно. Но если вы знакомы с Docker, то у вас должно быть общее представление о том, что он делает. (Детали разделения ответственностей между средой выполнения контейнеров и kubelet на самом деле довольно тонкие и здесь я не буду в них углубляться.)

И API-сервер?

Сервер API компонент Kubernetes панели управления, который представляет API Kubernetes. API-сервер это клиентская часть панели управления Kubernetes

Любому, кто когда-либо что-либо делал с Kubernetes, приходилось взаимодействовать с API либо напрямую, либо через kubectl. Это сердце того, что делает Kubernetes Kubernetesом мозг, превращающий горы YAML, который мы все знаем и любим (?), в работающую инфраструктуру. Кажется очевидным, что API должен присутствовать в нашей минимальной конфигурации.

Предварительные условия


  • Виртуальная или физическая машина Linux с root-доступом (я использую Ubuntu 18.04 на виртуальной машине).
  • И это все!


Скучная установка


На машину, которую мы будем использовать необходимо установить Docker. (Я не собираюсь подробно рассказывать как работает Docker и контейнеры; если вам интересно, есть замечательные статьи). Давайте просто установим его с помощью apt:

$ sudo apt install docker.io$ sudo systemctl start docker


После этого нам нужно получить бинарники Kubernetes. На самом деле для начального запуска нашего кластера нам нужен только kubelet, так как для запуска других серверных компонент мы сможем использовать kubelet. Для взаимодействия с нашим кластером после того как он заработает, мы также будем использовать kubectl.

$ curl -L https://dl.k8s.io/v1.18.5/kubernetes-server-linux-amd64.tar.gz > server.tar.gz$ tar xzvf server.tar.gz$ cp kubernetes/server/bin/kubelet .$ cp kubernetes/server/bin/kubectl .$ ./kubelet --versionKubernetes v1.18.5


Что произойдет, если мы просто запустим kubelet?

$ ./kubeletF0609 04:03:29.105194    4583 server.go:254] mkdir /var/lib/kubelet: permission denied


kubelet должен работать от root. Достаточно логично, так как ему надо управлять всем узлом. Давайте посмотрим на его параметры:

$ ./kubelet -h<слишком много строк, чтобы разместить здесь>$ ./kubelet -h | wc -l284


Ого, как много опций! К счастью, нам понадобится только пара из них. Вот один из параметров, который нам интересен:

--pod-manifest-path string


Путь к каталогу, содержащему файлы для статических подов, или путь к файлу с описанием статических подов. Файлы, начинающиеся с точек, игнорируются. (УСТАРЕЛО: этот параметр следует устанавливать в конфигурационном файле, передаваемом в Kubelet через опцию --config. Для дополнительной информации см. kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

Этот параметр позволяет нам запускать статические поды поды, которые не управляются через Kubernetes API. Статические поды используются редко, но они очень удобны для быстрого поднятия кластера, а это именно то, что нам нужно. Мы проигнорируем это громкое предупреждение (опять же, не запускайте это в проде!) и посмотрим, сможем ли мы запустить под.

Сначала мы создадим каталог для статических подов и запустим kubelet:

$ mkdir pods$ sudo ./kubelet --pod-manifest-path=pods


Затем в другом терминале/окне tmux/еще где-то, мы создадим манифест пода:

$ cat <<EOF > pods/hello.yamlapiVersion: v1kind: Podmetadata:  name: hellospec:  containers:  - image: busybox    name: hello    command: ["echo", "hello world!"]EOF


kubelet начинает писать какие-то предупреждения и кажется, что ничего не происходит. Но это не так! Давайте посмотрим на Docker:

$ sudo docker ps -aCONTAINER ID        IMAGE                  COMMAND                 CREATED             STATUS                      PORTS               NAMES8c8a35e26663        busybox                "echo 'hello world!'"   36 seconds ago      Exited (0) 36 seconds ago                       k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_468f670c3c85f        k8s.gcr.io/pause:3.2   "/pause"                2 minutes ago       Up 2 minutes                                    k8s_POD_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_0$ sudo docker logs k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4hello world!


kubelet прочитал манифест пода и дал Dockerу команду запустить пару контейнеров в соответствии с нашей спецификацией. (Если вам интересно узнать про контейнер pause, то это хакерство Kubernetes подробности смотрите в этом блоге.) Kubelet запустит наш контейнер busybox с указанной командой и будет перезапускать его бесконечно, пока статический под не будет удален.

Поздравьте себя. Мы только что придумали один из самых запутанных способов вывода текста в терминал!

Запускаем etcd


Нашей конечной целью является запуск Kubernetes API, но для этого нам сначала нужно запустить etcd. Давайте запустим минимальный кластер etcd, поместив его настройки в каталог pods (например, pods/etcd.yaml):

apiVersion: v1kind: Podmetadata:  name: etcd  namespace: kube-systemspec:  containers:  - name: etcd    command:    - etcd    - --data-dir=/var/lib/etcd    image: k8s.gcr.io/etcd:3.4.3-0    volumeMounts:    - mountPath: /var/lib/etcd      name: etcd-data  hostNetwork: true  volumes:  - hostPath:      path: /var/lib/etcd      type: DirectoryOrCreate    name: etcd-data


Если вы когда-либо работали с Kubernetes, то подобные YAML-файлы должны быть вам знакомы. Здесь стоит отметить только два момента:

Мы смонтировали папку хоста /var/lib/etcd в под, чтобы данные etcd сохранялись после перезапуска (если этого не сделать, то состояние кластера будет стираться при каждом перезапуске пода, что будет нехорошо даже для минимальной установки Kubernetes).
Мы установили hostNetwork: true. Этот параметр, что неудивительно, настраивает etcd для использования сети хоста вместо внутренней сети пода (это облегчит API-серверу поиск кластера etcd).

Простая проверка показывает, что etcd действительно запущен на localhost и сохраняет данные на диск:

$ curl localhost:2379/version{"etcdserver":"3.4.3","etcdcluster":"3.4.0"}$ sudo tree /var/lib/etcd//var/lib/etcd/ member     snap        db     wal         0.tmp         0000000000000000-0000000000000000.wal


Запуск API-сервера


Запустить API-сервер Kubernetes еще проще. Единственный параметр, который надо передать, --etcd-servers, делает то, что вы ожидаете:

apiVersion: v1kind: Podmetadata:  name: kube-apiserver  namespace: kube-systemspec:  containers:  - name: kube-apiserver    command:    - kube-apiserver    - --etcd-servers=http://127.0.0.1:2379    image: k8s.gcr.io/kube-apiserver:v1.18.5  hostNetwork: true


Поместите этот YAML-файл в каталог pods, и API-сервер запустится. Проверка с помощью curl показывает, что Kubernetes API прослушивает порт 8080 с полностью открытым доступом аутентификация не требуется!

$ curl localhost:8080/healthzok$ curl localhost:8080/api/v1/pods{  "kind": "PodList",  "apiVersion": "v1",  "metadata": {    "selfLink": "/api/v1/pods",    "resourceVersion": "59"  },  "items": []}


(Опять же, не запускайте это в продакшене! Я был немного удивлен, что настройка по умолчанию настолько небезопасна. Но я предполагаю, что это сделано для облегчения разработки и тестирования.)
И, приятный сюрприз, kubectl работает из коробки без каких-либо дополнительных настроек!

$ ./kubectl versionClient Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:39:24Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}$ ./kubectl get podNo resources found in default namespace.


Проблема


Но если копнуть немного глубже, то кажется, что что-то идет не так:

$ ./kubectl get pod -n kube-systemNo resources found in kube-system namespace.


Статические поды, которые мы создали, пропали! На самом деле, наш kubelet-узел вообще не обнаруживается:

$ ./kubectl get nodesNo resources found in default namespace.


В чем же дело? Если вы помните, то несколько абзацев назад мы запускали kubelet с чрезвычайно простым набором параметров командной строки, поэтому kubelet не знает, как связаться с сервером API и уведомлять его о своем состоянии. Изучив документацию, мы находим соответствующий флаг:

--kubeconfig string

Путь к файлу kubeconfig, в котором указано как подключаться к серверу API. Наличие --kubeconfig включает режим API-сервера, отсутствие --kubeconfig включает автономный режим.

Все это время, сами того не зная, мы запускали kubelet в автономном режиме. (Если бы мы были педантичны, то можно было считать автономный режим kubelet как минимально жизнеспособный Kubernetes, но это было бы очень скучно). Чтобы заработала настоящая конфигурация, нам нужно передать файл kubeconfig в kubelet, чтобы он знал, как общаться с API-сервером. К счастью, это довольно просто (так как у нас нет проблем с аутентификацией или сертификатами):

apiVersion: v1kind: Configclusters:- cluster:    server: http://127.0.0.1:8080  name: mink8scontexts:- context:    cluster: mink8s  name: mink8scurrent-context: mink8s


Сохраните это как kubeconfig.yaml, убейте процесс kubelet и перезапустите с необходимыми параметрами:

$ sudo ./kubelet --pod-manifest-path=pods --kubeconfig=kubeconfig.yaml


(Кстати, если вы попытаетесь обратиться к API через curl, когда kubelet не работает, то вы обнаружите, что он все еще работает! Kubelet не является родителем своих подов, подобно Dockerу, он больше похож на управляющего демона. Контейнеры, управляемые kubelet, будут работать, пока kubelet не остановит их.)

Через несколько минут kubectl должен показать нам поды и узлы, как мы и ожидаем:

$ ./kubectl get pods -ANAMESPACE     NAME                    READY   STATUS             RESTARTS   AGEdefault       hello-mink8s            0/1     CrashLoopBackOff   261        21hkube-system   etcd-mink8s             1/1     Running            0          21hkube-system   kube-apiserver-mink8s   1/1     Running            0          21h$ ./kubectl get nodes -owideNAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIMEmink8s   Ready    <none>   21h   v1.18.5   10.70.10.228   <none>        Ubuntu 18.04.4 LTS   4.15.0-109-generic   docker://19.3.6


Давайте на этот раз поздравим себя по-настоящему (я знаю, что уже поздравлял) у нас получился минимальный кластер Kubernetes, работающий с полнофункциональным API!

Запускаем под


Теперь посмотрим на что способен API. Начнем с пода nginx:

apiVersion: v1kind: Podmetadata:  name: nginxspec:  containers:  - image: nginx    name: nginx


Здесь мы получим довольно интересную ошибку:

$ ./kubectl apply -f nginx.yamlError from server (Forbidden): error when creating "nginx.yaml": pods "nginx" isforbidden: error looking up service account default/default: serviceaccount"default" not found$ ./kubectl get serviceaccountsNo resources found in default namespace.


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

$ cat <<EOS | ./kubectl apply -f -apiVersion: v1kind: ServiceAccountmetadata:  name: default  namespace: defaultEOSserviceaccount/default created$ ./kubectl apply -f nginx.yamlError from server (ServerTimeout): error when creating "nginx.yaml": No APItoken found for service account "default", retry after the token isautomatically created and added to the service account


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

Мы можем обойти эту проблему, установив опцию automountServiceAccountToken для учетной записи службы (так как нам все равно не придется ее использовать):

$ cat <<EOS | ./kubectl apply -f -apiVersion: v1kind: ServiceAccountmetadata:  name: default  namespace: defaultautomountServiceAccountToken: falseEOSserviceaccount/default configured$ ./kubectl apply -f nginx.yamlpod/nginx created$ ./kubectl get podsNAME    READY   STATUS    RESTARTS   AGEnginx   0/1     Pending   0          13m


Наконец, под появился! Но на самом деле он не запустится, так как у нас нет планировщика (scheduler) еще одного важного компонента Kubernetes. Опять же, мы видим, что API Kubernetes на удивление глупый когда вы создаете под в API, он его регистрирует, но не пытается выяснить, на каком узле его запускать.

На самом деле для запуска пода планировщик не нужен. Можно вручную добавить узел в манифест в параметре nodeName:

apiVersion: v1kind: Podmetadata:  name: nginxspec:  containers:  - image: nginx    name: nginx  nodeName: mink8s

(Замените mink8s на название узла.) После delete и apply мы видим, что nginx запустился и слушает внутренний IP-адрес:

$ ./kubectl delete pod nginxpod "nginx" deleted$ ./kubectl apply -f nginx.yamlpod/nginx created$ ./kubectl get pods -owideNAME    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATESnginx   1/1     Running   0          30s   172.17.0.2   mink8s   <none>           <none>$ curl -s 172.17.0.2 | head -4<!DOCTYPE html><html><head><title>Welcome to nginx!</title>


Чтобы убедиться, что сеть между подами работает корректно, мы можем запустить curl из другого пода:

$ cat <<EOS | ./kubectl apply -f -apiVersion: v1kind: Podmetadata:  name: curlspec:  containers:  - image: curlimages/curl    name: curl    command: ["curl", "172.17.0.2"]  nodeName: mink8sEOSpod/curl created$ ./kubectl logs curl | head -6  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed<!DOCTYPE html><html><head><title>Welcome to nginx!</title>


Довольно интересно покопаться в этом окружении и посмотреть, что работает, а что нет. Я обнаружил, что ConfigMap и Secret работают так, как и ожидается, а Service и Deployment нет.

Успех!


Этот пост становится большим, поэтому я собираюсь объявить о победе и заявить, что это жизнеспособная конфигурация, которую можно назвать Kubernetes". Резюмируя: четыре бинарных файла, пять параметров командной строки и всего лишь 45 строк YAML (не так много по стандартам Kubernetes) и у нас работает немало вещей:

  • Поды управляются с помощью обычного Kubernetes API (с несколькими хаками)
  • Можно загружать публичные образы контейнеров и управлять ими
  • Поды остаются живыми и автоматически перезапускаются
  • Сеть между подами в рамках одного узла работает довольно хорошо
  • ConfigMap, Secret и простейшее монтирование хранилищ работает как положено


Но большая часть из того, что делает Kubernetes по-настоящему полезным, все еще отсутствует, например:

  • Планировщик подов
  • Аутентификация / авторизация
  • Несколько узлов
  • Сеть сервисов
  • Кластерный внутренний DNS
  • Контроллеры для учетных записей служб, развертываний, интеграции с облачными провайдерами и большинство других плюшек, которые приносит Kubernetes


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

Узнать подробнее о курсе на бесплатном вебинаре.


Читать еще:


Подробнее..
Категории: Kubernetes , Devops , Блог компании otus. онлайн-образование , Kuber , Kubectl , Kubelet

Kubernetes tips amp tricks удобные заготовки для kubectl

03.08.2020 10:14:39 | Автор: admin
Внутри компании мы активно делимся между собой полученными знаниями: не только в виде формальных wiki-инструкций, но и сообщениями в Slack (а чтобы ничего не терялось, предусмотрена умная система поиска, но это уже отдельная история). У нас накопилось уже большое количество разнообразных заготовок для консольных операций в Kubernetes с kubectl. Про них и пойдет речь в этой статье.



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

NB: Некоторые из перечисленных ниже команд были составлены нашими инженерами, а другие найдены на просторах интернета. В последнем случае они были проверены и признаны полезными.

Итак, поехали!

Получение списков pod'ов и узлов


  1. Думаю, что получение всех pod'ов из всех пространств имён путем указания ключа --all-namespaces не является секретом ни для кого. Но многие так привыкли к нему, что не заметили появления более короткой версии -A (по меньшей мере, такая возможность точно присутствует начиная с релиза Kubernetes 1.15).
  2. Как найти все проблемные pod'ы, которые не в запущенном состоянии (т.е. не Running)?

    kubectl get pods -A --field-selector=status.phase!=Running | grep -v Complete



    Кстати, присмотреться к --field-selector вообще очень полезно (см. документацию).
  3. Получить список узлов с указанием объема их оперативной памяти:

    kubectl get no -o json | \  jq -r '.items | sort_by(.status.capacity.memory)[]|[.metadata.name,.status.capacity.memory]| @tsv'

  4. Получить список узлов и количество pod'ов на них:

    kubectl get po -o json --all-namespaces | \  jq '.items | group_by(.spec.nodeName) | map({"nodeName": .[0].spec.nodeName, "count": length}) | sort_by(.count)'

  5. Бывает, что по какой-то причине DaemonSet не выехал на какой-то узел. Искать вручную утомительное занятие, поэтому вот мини-скрипт для получения списка узлов, на которые не выехали DaemonSet'ы:

    ns=my-namespacepod_template=my-podkubectl get node | grep -v \"$(kubectl -n ${ns} get pod --all-namespaces -o wide | fgrep ${pod_template} | awk '{print $8}' | xargs -n 1 echo -n "\|" | sed 's/[[:space:]]*//g')\"
  6. Вот так с kubectl top можно получить pod'ы, которые потребляют максимальное количество процессора или памяти:

    # cpukubectl top pods -A | sort --reverse --key 3 --numeric# memorykubectl top pods -A | sort --reverse --key 4 --numeric
  7. Сортировка списка pod'ов в данном случае, по количеству рестартов:

    kubectl get pods --sort-by=.status.containerStatuses[0].restartCount



    Разумеется, сортировка может быть и по другим полям (см. PodStatus и ContainerStatus).

Получение другой информации


  1. Когда производится отладка работы Ingress'а, мы неизбежно доходим до сервиса и далее ищем pod'ы по его селектору. Сначала я искал селектор в манифесте сервиса, но со временем позже начал применять -o wide:

    kubectl -n jaeger get svc -o wideNAME                            TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)                                  AGE   SELECTORjaeger-cassandra                ClusterIP   None              <none>        9042/TCP                                 77d   app=cassandracluster,cassandracluster=jaeger-cassandra,cluster=jaeger-cassandra

    Как легко увидеть, в этом случае мы сразу получаем селектор, по которому сервис находит нужные pod'ы.
  2. Получить по каждому контейнеру каждого pod'а его limits и requests:

    kubectl get pods -n my-namespace -o=custom-columns='NAME:spec.containers[*].name,MEMREQ:spec.containers[*].resources.requests.memory,MEMLIM:spec.containers[*].resources.limits.memory,CPUREQ:spec.containers[*].resources.requests.cpu,CPULIM:spec.containers[*].resources.limits.cpu'

  3. У команды kubectl run (а также create, apply, patch) есть замечательная возможность посмотреть изменения до их применения это делает флаг --dry-run. А если применить вкупе с -o yaml, можно получить манифест требуемой сущности. Например:

    kubectl run test --image=grafana/grafana --dry-run -o yamlapiVersion: apps/v1kind: Deploymentmetadata:  creationTimestamp: null  labels:    run: test  name: testspec:  replicas: 1  selector:    matchLabels:      run: test  strategy: {}  template:    metadata:      creationTimestamp: null      labels:        run: test    spec:      containers:      - image: grafana/grafana        name: test        resources: {}status: {}

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

    kubectl explain hpaKIND:     HorizontalPodAutoscalerVERSION:  autoscaling/v1DESCRIPTION:     configuration of a horizontal pod autoscaler.FIELDS:   apiVersion    <string>     APIVersion defines the versioned schema of this representation of an     object. Servers should convert recognized schemas to the latest internal     value, and may reject unrecognized values. More info:     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources   kind    <string>     Kind is a string value representing the REST resource this object     represents. Servers may infer this from the endpoint the client submits     requests to. Cannot be updated. In CamelCase. More info:     https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds   metadata    <Object>     Standard object metadata. More info:     https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata   spec    <Object>     behaviour of autoscaler. More info:     https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status.   status    <Object>     current information about the autoscaler.

    Полная и весьма полезная информация!

Сети


  1. Получить внутренние IP-адреса узлов кластера:

    kubectl get nodes -o json | \  jq -r '.items[].status.addresses[]? | select (.type == "InternalIP") | .address' | \  paste -sd "\n" -

  2. Вывести все сервисы и nodePort, которые они занимают:

    kubectl get --all-namespaces svc -o json | \  jq -r '.items[] | [.metadata.name,([.spec.ports[].nodePort | tostring ] | join("|"))]| @tsv'

  3. В ситуациях, когда возникают проблемы с CNI (например, с Flannel), для выявления проблемного pod'а надо проверить маршруты. Здесь очень пригодятся подсети pod'ов, которые используются в кластере:

    kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}' | tr " " "\n"


Логи


  1. Получение логов pod'а c человекочитаемым timestamp на случай его отсутствия:

    kubectl -n my-namespace logs -f my-pod --timestamps2020-07-08T14:01:59.581788788Z fail: Microsoft.EntityFrameworkCore.Query[10100]

    Выглядит намного удобнее, не так ли?
  2. Не ждите, пока выведется весь лог контейнера pod'а используйте --tail:

    kubectl -n my-namespace logs -f my-pod --tail=50
  3. Получить логи со всех контейнеров pod'а:

    kubectl -n my-namespace logs -f my-pod --all-containers
  4. Получить логи со всех pod'ов на основании label'а:

    kubectl -n my-namespace logs -f -l app=nginx
  5. Получить логи предыдущего контейнера, который, к примеру, упал:

    kubectl -n my-namespace logs my-pod --previous

Другие быстрые действия


  1. Как скопировать все секреты из одного пространства имён в другое?

    kubectl get secrets -o json --namespace namespace-old | \  jq '.items[].metadata.namespace = "namespace-new"' | \  kubectl create-f  -
  2. Быстро создать самоподписанный сертификат для тестов:

    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=grafana.mysite.ru/O=MyOrganization"kubectl -n myapp create secret tls selfsecret --key tls.key --cert tls.crt

Полезные ссылки по теме


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


P.S.


Читайте также в нашем блоге:

Подробнее..
Категории: Kubernetes , Системное администрирование , Devops , Блог компании флант , Kubectl

АйТиБорода Контейнеризация понятным языком. Интервью с System Engineers из Southbridge

02.10.2020 16:05:32 | Автор: admin

Сегодня вас ожидает путешествие в мир системных инженеров aka DevOps-инженеров: выпуск про виртуализацию, контейнеризацию, оркестрацию с помощью kubernetes, и настройку конфигоd через. Docker, kubernetes, ansible, рулбуки, кублеты, хельм, докерсворм, kubectl, чарты, поды -мощная теория для чёткой практики.


В гостях System Engineers из учебного центра Слёрм и одновременно компании Southbridge Николай Месропян и Марсель Ибраев. Так что, заваривайте чаинский/кофеинский и приготовьтесь к погружению



ДОПОЛНИТЕЛЬНО:




НАВИГАЦИЯ:


0:00 Вступление
1:00 Коля о себе
5:02 Марсель о себе
11:54 О виртуализации
13:50 Отличие контейнеризации от виртуализации
17:54 Почему контейнеры работают быстро
19:05 Аналоги контейнеризации
20:35 Почему Docker захватил рынок
21:30 Про дебаг и логи в контейнера
23:18 Контейнеризация в винде
25:37 Почему нет нативного докера для винды
27:20 WSL
27:58 Про оркестрацию
30:30 Типичные примеры применения оркестратора
32:18 Кубернетис это только про контейнеры?
33:43 Конкуренты Docker
34:45 Как работает kubernetes
47:35 Опять про дебаг и кублеты
50:08 Для каких архитектурных мощностей хорош кубик
50:34 Про поды
51:51 Что с базами данных
1:00:45 Helm & чарты
1:05:11 Statefull-приложения и их разворачивание
1:07:30 Безопасность кубика
1:15:35 Навыки для работы с кубиком
1:16:32 Когда кубик использовать не стоит
1:18:02 Разница между ансиблом и кубиком
1:19:26 Что такое ansible и зачем это нужно
1:22:38 Как работает ансибл
1:26:15 Из чего состоит ансибл
1:33:20 Тесты конфигов
1:37:04 Нужно ли программирование, что бы работать с ансиблом
1:39:20 Навыки для работы с ансиблом
1:42:51 Про Слёрм и ламповый формат образования
1:53:48 Онлайн и корона сказался на качестве получения знаний?
1:57:35 Кто клиент Слёрма и какой порог входа на курсы
1:59:53 КОНКУРС


May the Kubernetes be with you!

Подробнее..
Категории: Kubernetes , Системное администрирование , Devops , Блог компании southbridge , Docker , Серверное администрирование , Ansible , Helm , K8s , Kubectl , Southbridge

Изучаем Bash путем написания интерактивой игры, создаем культуру DevOps, а также шпаргалка по MariaDB и MySQL

14.01.2021 16:09:15 | Автор: admin

Начинаем 2021 год с нового дайджеста полезных материалов. Собрали много инсайтов, записей важных вебинаров, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Начни новое:

  • 5 тенденций гибридного облака, на которые стоит обратить внимание в 2021 году

    Гибридное облако становится главной моделью построения корпоративных ИТ-систем. Наши эксперты рассказывают, как изменятся сами облачные платформы, а также обсуждают дифференцированный выбор облачных сред для рабочих нагрузок, вопросы безопасности и другие темы.

    Вкратце: главный архитектор Red Hat Эмили Бренд (Emily Brand) и другие эксперты делятся советами с ИТ-руководителям.

  • Удаленная работа: 3 способа взбодрить свою команду в 2021 году

    Новый Год это новая возможность подзарядить энергией вашу команду. Представляем новые методики, которые помогут стимулировать креативность, сотрудничество и вовлеченность на виртуальных рабочих местах.

    Вкратце: главный технический специалист Red Hat по работе с публичным сектором Дэвил Эгтс (David Egts) рассказывает о виртуальных комнатах отдыха и других подобных вещах.

Почитать на досуге:

Скачать:

  • Шпаргалка по MariaDB и MySQL

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

Еще полезное:

  • Запускаем Kubernetes на Raspberry Pi

    Каждую главу этой электронной книги можно читать как самостоятельную единицу или как часть общего руководства по запуску Kubernetes на Raspberry Pi.

  • Шпаргалка по Kubectl

    9 критически важных команд kubectl для устранения неполадок и управления при администрировании кластера Kubernetes.

  • Шпаргалка по Emacs

    В Emacs огромное множество клавиатурных сокращений для быстрого вызова команд, эта шпаргалка познакомит с основными из них.

Подробнее..
Категории: Kubernetes , Администрирование баз данных , Open source , Devops , Виртуализация , Облачные вычисления , Блог компании red hat , Red hat , Mysql , Bash , Ansible , Kubectl , Raspberrypi , Mariadb

Изучаем Bash путем написания интерактивной игры, создаем культуру DevOps, а также шпаргалка по MariaDB и MySQL

14.01.2021 18:11:53 | Автор: admin

Начинаем 2021 год с нового дайджеста полезных материалов. Собрали много инсайтов, записей важных вебинаров, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Начни новое:

  • 5 тенденций гибридного облака, на которые стоит обратить внимание в 2021 году

    Гибридное облако становится главной моделью построения корпоративных ИТ-систем. Наши эксперты рассказывают, как изменятся сами облачные платформы, а также обсуждают дифференцированный выбор облачных сред для рабочих нагрузок, вопросы безопасности и другие темы.

    Вкратце: главный архитектор Red Hat Эмили Бренд (Emily Brand) и другие эксперты делятся советами с ИТ-руководителям.

  • Удаленная работа: 3 способа взбодрить свою команду в 2021 году

    Новый Год это новая возможность подзарядить энергией вашу команду. Представляем новые методики, которые помогут стимулировать креативность, сотрудничество и вовлеченность на виртуальных рабочих местах.

    Вкратце: главный технический специалист Red Hat по работе с публичным сектором Дэвил Эгтс (David Egts) рассказывает о виртуальных комнатах отдыха и других подобных вещах.

Почитать на досуге:

Скачать:

  • Шпаргалка по MariaDB и MySQL

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

Еще полезное:

  • Запускаем Kubernetes на Raspberry Pi

    Каждую главу этой электронной книги можно читать как самостоятельную единицу или как часть общего руководства по запуску Kubernetes на Raspberry Pi.

  • Шпаргалка по Kubectl

    9 критически важных команд kubectl для устранения неполадок и управления при администрировании кластера Kubernetes.

  • Шпаргалка по Emacs

    В Emacs огромное множество клавиатурных сокращений для быстрого вызова команд, эта шпаргалка познакомит с основными из них.

Подробнее..
Категории: Kubernetes , Администрирование баз данных , Open source , Devops , Виртуализация , Облачные вычисления , Блог компании red hat , Red hat , Mysql , Bash , Ansible , Kubectl , Raspberrypi , Mariadb

Резервное копирование конфигурации ресурсов в Kubernetes

19.02.2021 12:19:30 | Автор: admin

Администраторы кластеров kubernetes сталкиваются с задачей сохранить конфигурацию ресурсов из пространства имен и перенести в другой кластер, или же сделать резервную копию нестабильной тестовой площадки. С этой задачей без проблем справляется бегло написанный в терминале односторчный скрипт с утилитой kubectl, но что если надоело каждый раз тратить пару минут времени на очередное написание скрипта. Так и появилась утилита kube-dump, по сути это утилита которая умеет только одно - дампить ресурсы кластера.

пример работы утилиты для сохранения всех ресурсов одного неймспейсапример работы утилиты для сохранения всех ресурсов одного неймспейса

При помощи данной утилиты вы можете сохранить ресурсы кластера в виде чистого yaml манифеста без лишних метаданных.

Ключевые особенности:

  • Сохранение выполняется только для тех ресурсов, к которым у вас есть доступ на чтение.

  • На вход можно передать перечень пространств имен, в противном случае будут использованы все доступные для вашего контекста.

  • К сохранению подлежат как ресурсы пространств имен, так и глобальные ресурсы кластера.

  • Использовать утилиту можно локально как обычный скрипт или запустить в контейнере или в кластере kubernetes к примеру как CronJob.

  • Может создавать архивы и ротировать их за собой.

  • Может фиксировать состояние в git репозитории и отправлять в удаленный репозиторий.

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

Конфигурацию для утилиты передаем с помощью аргументов командной строки или при помощью экспортированных переменных окружений или прочитанных из .env файла.

Начало работы

Необходимый минимум для запуска это наличие установленного kubectl и подключенного в него кластера, а также утилит jq и yq. Более подробно описано на странице документации по локальному запуску, а аргументы командной строки описаны здесь или же доступны по ключу --help.

Запустим утилиту для сохранения всех ресурсов кластера:

./kube-dump dump

Если вы не хотите разбираться с установкой зависимостей вы можете воспользоваться контейнером. Подробнее про работу с контейнером описано в этой статье.

Получим свежий образ и запустим утилиту для сохранения пространств имен dev и prod в смонтированную директорию /dump, где для доступа к кластеру мы пробрасываем в контейнер свой конфигурационный файл от kubectl.

docker pull woozymasta/kube-dump:latestdocker run --tty --interactive --rm \  --volume $HOME/.kube:/.kube \  --volume $HOME/dump:/dump \  woozymasta/kube-dump:latest \  dump-namespaces -n dev,prod -d /dump --kube-config /.kube/config

Установка CronJob в кластер

Рассмотрим более сложный пример когда контейнер будет запущен в кластере как CronJob который будет каждую ночь снимать дамп ресурсов и фиксировать правки в git репозитории с последующей отправкой в удаленный репозиторий. Пример подробно описан в статье.

В данном примере подразумевается что у вас есть доступ к управлению ролями кластера, потому что мы будем использовать для работы ServiceAccount и стандартную роль view. Если же вам не подходит глобальная роль view, вы можете создать свою роль для пространства имен или кластера, в помощь можете взять этот пример.

Создадим пространство имен где будет работать наш CronJob и ServiceAccount который будет использовать ClusterRoleBinding для роли view:

kubectl create ns kube-dumpkubectl -n kube-dump apply -f \  https://raw.githubusercontent.com/WoozyMasta/kube-dump/master/deploy/cluster-role-view.yaml

В качестве примера будем использовать авторизацию в GitLab по OAuth токену, по этому создадим секрет с адресом репозитория и токеном для авторизации:\

kubectl -n kube-dump create secret generic kube-dump \  --from-literal=GIT_REMOTE_URL=https://oauth2:$TOKEN@corp-gitlab.com/devops/cluster-bkp.git

Перед установкой настройте переменные окружения под ваши нужды, в примере по умолчанию установлен режим копирования пространств имен dev и prod с последующей фиксацией изменений в ветке my-cluster и отправкой в удаленный репозиторий.

Настроим CronJob в которм укажем периодичность запуска задания:

spec:  schedule: "0 1 * * *"

Или же установите пример как есть и после отредактируйте его:

kubectl -n kube-dump apply -f \  https://github.com/WoozyMasta/kube-dump/blob/master/deploy/cronjob-git-token.yamlkubectl -n kube-dump edit cronjobs.batch kube-dump

Планы по дальнейшему развитию

  • Реализовать отправку дампов в s3 совместимое хранилище;

  • Отправка уведомлений по электронной почте и через веб-хук;

  • Git-crypt для шифрования чувствительных данных;

  • Автодополнение в Bash/Zsh;

  • Поддержка OpenShift.

Также буду рад Вашим комментариям и предложениям с идеями и критикой.

Ссылки

Подробнее..
Категории: Kubernetes , Резервное копирование , Backup , Bash , Kubectl

Recovery mode Мне повезло нужно обновить сертификаты k8s v1.12.3

03.03.2021 22:15:39 | Автор: admin

Неделю назад мне подкинули задачу - обновить сертификаты k8s кластере. С одной стороны задача казалась достаточно тривиальной, НО нетривиальности добавляло моя неуверенность с k8s: до этого момента я пользовался кубером как сервисом и больше чем посмотреть на поды, удалить их написать deployment по шаблону делать ничего не доводилось. Уверенности добавляло наличие инструкции, но как выяснилось она для версии v1.13 а у кластера для, которого требовалось реализовать эту задачу версия была 1.12.3. И тут началось

3-го числа задачу с обновлением решил и захотелось написать инструкцию. Слышал, что в новых версиях сейчас эта задача решается чуть ли не одной командой, но для тех у кого оказался такой же винтаж как и у меня делюсь своим опытом.

Дано k8s кластер:

  • 3 master ноды

  • 3 etcd ноды

  • 5 worker нод

kubectl get nodesNAME                    STATUS   ROLES    AGE    VERSIONproduct1-mvp-k8s-0001   Ready    master   464d   v1.12.3product1-mvp-k8s-0002   Ready    master   464d   v1.12.3product1-mvp-k8s-0003   Ready    master   464d   v1.12.3product1-mvp-k8s-0007   Ready    node     464d   v1.12.3product1-mvp-k8s-0008   Ready    node     464d   v1.12.3product1-mvp-k8s-0009   Ready    node     464d   v1.12.3product1-mvp-k8s-0010   Ready    node     464d   v1.12.3product1-mvp-k8s-0011   Ready    node     464d   v1.12.3

Срок действия сертификата

echo | openssl s_client -showcerts -connect product1-mvp-k8s-0001:6443 -servername api 2>/dev/null | openssl x509 -noout -enddatenotAfter=Mar  4 00:39:56 2021 GMT

Поехали:

  • на всех MASTER нодах бэкапируем /etc/kubernetes

sudo mkdir backup; sudo cp -R /etc/kubernetes backup/ ; sudo tar -cvzf backup/pki_backup_`hostname`-`date +%Y%m%d`.tar.gz backup/kubernetes/

  • Смотрим в структуру /etc/Kubernetes она будет примерно такой

ls -ltotal 80-rw------- 1 root root 5440 Mar  3 13:21 admin.confdrwxr-xr-x 2 root root 4096 Aug 17  2020 audit-policy-rw-r--r-- 1 root root  368 Mar  4  2020 calico-config.yml-rw-r--r-- 1 root root  270 Mar  4  2020 calico-crb.yml-rw-r--r-- 1 root root  341 Mar  4  2020 calico-cr.yml-rw-r--r-- 1 root root  147 Mar  4  2020 calico-node-sa.yml-rw-r--r-- 1 root root 6363 Mar  4  2020 calico-node.yml-rw------- 1 root root 5472 Mar  3 13:21 controller-manager.conf-rw-r--r-- 1 root root 3041 Aug 14  2020 kubeadm-config.v1alpha3.yaml-rw------- 1 root root 5548 Mar  3 13:21 kubelet.conf-rw-r--r-- 1 root root 1751 Mar  4  2020 kubelet.envdrwxr-xr-x 2 kube root 4096 Aug 14  2020 manifestslrwxrwxrwx 1 root root   28 Mar  4  2020 node-kubeconfig.yaml -> /etc/kubernetes/kubelet.conf-rw------- 1 root root 5420 Mar  3 13:21 scheduler.confdrwxr-xr-x 3 kube root 4096 Mar  3 10:20 ssl

у меня все ключи в ssl, а не в pki , который будет нужен kubeadm , то он должен появиться, в своем случае я сделаю на него symlink

ln -s /etc/kubernetes/ssl /etc/kubernetes/pki

  • отыскиваем файл с конфигурацией кластера, в моем случае это был

    kubeadm-config.v1alpha3.yaml

если такового вдруг нет то его возможно сгенерировать

kubectl get cm kubeadm-config -n kube-system -o yaml > /etc/kubernetes/kubeadm-config.yaml

  • Начинаем перегенерацию сертификатов

kubeadm alpha phase certs apiserver  --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Using the existing apiserver certificate and key.kubeadm alpha phase certs apiserver-kubelet-clientI0303 13:12:24.543254   40613 version.go:236] remote version is much newer: v1.20.4; falling back to: stable-1.12[certificates] Using the existing apiserver-kubelet-client certificate and key.kubeadm alpha phase certs front-proxy-clientI0303 13:12:35.660672   40989 version.go:236] remote version is much newer: v1.20.4; falling back to: stable-1.12[certificates] Using the existing front-proxy-client certificate and key.kubeadm alpha phase certs  etcd-server --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Generated etcd/server certificate and key.[certificates] etcd/server serving cert is signed for DNS names [prod-uct1-mvp-k8s-0001 localhost] and IPs [127.0.0.1 ::1]kubeadm alpha phase certs  etcd-server --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Using the existing etcd/server certificate and key.kubeadm alpha phase certs  etcd-healthcheck-client --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Generated etcd/healthcheck-client certificate and key.kubeadm alpha phase certs  etcd-peer --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Generated etcd/peer certificate and key.[certificates] etcd/peer serving cert is signed for DNS names [product1-mvp-k8s-0001 localhost] and IPs [192.168.4.201 127.0.0.1 ::1]

  • проверяем выпущенные сертификаты на актуальность

find /etc/kubernetes/pki/ -name '*.crt' -exec openssl x509 -text -noout -in {} \; | grep -A2 Validity        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 10:29:44 2030 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  3 10:07:29 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  3 10:07:52 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  3 10:06:48 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 10:29:44 2030 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 19:39:56 2022 GMT--        Validity            Not Before: Mar  4 10:29:43 2020 GMT            Not After : Mar  2 10:29:43 2030 GMT--        Validity            Not Before: Mar  4 10:29:43 2020 GMT            Not After : Mar  2 19:40:13 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 19:36:38 2022 GMT

  • В процессе обновления сертификатов буду выпущены заново файлы admin.conf, controller-manager.conf, kubelet.conf, scheduler.conf а существующие переносим в подпапку tmpи генерим новые файлы

kubeadm alpha phase kubeconfig all  --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml [kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/admin.conf"[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/kubelet.conf"[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/controller-manager.conf"[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/scheduler.conf"

  • перезапускаем все контейнеры и kubelet мастер ноды и проверяем что сервис kubelet завершил перезапуск

sudo systemctl stop kubelet; sudo docker stop $(docker ps -aq); sudo docker rm $(docker ps -aq); sudo systemctl start kubeletsystemctl status kubelet -l kubelet.service - Kubernetes Kubelet Server   Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)   Active: active (running) since Wed 2021-03-03 14:00:22 MSK; 10s ago     Docs: https://github.com/GoogleCloudPlatform/kubernetes  Process: 52998 ExecStartPre=/bin/mkdir -p /var/lib/kubelet/volume-plugins (code=exited, status=0/SUCCESS) Main PID: 53001 (kubelet)   Memory: 51.2M   CGroup: /system.slice/kubelet.service

  • проверяем что master нода вернулась нормально в кластер и что доступна конфигурация namespace

kubectl get nodeskubectl get nsNAME STATUS AGEdefault Active 464dproduct1-mvp Active 318dinfra-logging Active 315dinfra-nginx-ingress Active 386dkube-public Active 464dkube-system Active 464dpg Active 318d

  • проверяем что сертификат обновился

notAfter=Mar 3 07:40:43 2022 GMT

Обновление сертификатов на master ноде 1 успешно завершено и повторяем туже процедуру на оставшихся 2-х.

Далее обновляем worker ноды:

  • удаляем или переименовываем kubelet.conf, необходимо для того чтобы при перезапуске подхватился файл bootstrap-kubelet.conf

cd /etc/kubernetes/mv kubelet.conf kubelet.conf_old

  • вносим изменения в файл bootstrap-kubelet.conf если его нет, то создаем по шаблону внизу

apiVersion: v1clusters:- cluster: certificate-authority-data: | LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01ETX server: https://192.168.4.201:6443 name: product1contexts:- context: cluster: product1 user: tls-bootstrap-token-user name: tls-bootstrap-token-user@product1current-context: tls-bootstrap-token-user@product1kind: Configpreferences: {}users:- name: tls-bootstrap-token-user user: token: fgz9qz.lujw0bwsdfhdsfjhgds

где мы должны заменить

- certificate-authority-data корневой сертификат центра сертификации PKI CA мастера, берем например из файла /etc/kubernetes/kubelet.conf на master ноде

- server: https://192.168.4.201:6443 - ip api сервера master ноды, или же виртуальный balance ip

token: fgz9qz.lujw0bwsdfhdsfjhgds - токен, который генерим на master ноде

kubeadm token create

  • перезапускаем kubelet и проверяем результат с master ноды, work нода должна ,быть доступна ready в ресурсе кластера

systemctl restart kubeletsystemctl status kubelet -l kubelet.service - Kubernetes Kubelet Server Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2021-03-03 14:06:33 MSK; 11s ago Docs: https://github.com/GoogleCloudPlatform/kubernetes Process: 54615 ExecStartPre=/bin/mkdir -p /var/lib/kubelet/volume-plugins (code=exited, status=0/SUCCESS)Main PID: 54621 (kubelet) Memory: 52.1M CGroup: /system.slice/kubelet.service

  • проверить, что сертификат обновлен посмотреть на обновление сертификатов в папке

ls -las /var/lib/kubelet/pki/total 244 -rw-------. 1 root root 1135 Mar 3 14:06 kubelet-client-2021-03-03-14-06-34.pem0 lrwxrwxrwx. 1 root root 59 Mar 3 14:06 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2021-03-03-14-06-34.pem4 -rw-r--r--. 1 root root 2267 Mar 2 10:40 kubelet.crt4 -rw-------. 1 root root 1679 Mar 2 10:40 kubelet.key

Повторяем подобную процедуру на всех оставшихся work нодах.

Все мы обновили сертификаты на k8s кластере v1.12.3

Подробнее..
Категории: Kubernetes , Kubectl , Kubelet , Kubeadm , Cert

Ещё три утилиты, упрощающие работу с kubectl fubectl, Kubelive, Web Kubectl

23.04.2021 10:10:48 | Автор: admin

Какая утилита чаще всего встречается в .bash_history SRE/DevOps-инженера, работающего с Kubernetes? Конечно, kubectl. Это привело к тому, что в сообществе нашлось вдохновение для тех, захотел её улучшить, принести новый опыт использования или даже создать некие производные, нацеленные на более удобное взаимодействие. В рамках этого обзора рассмотрены три таких проекта, которые, возможно, покажутся интересными и вам или хотя бы откроют какие-то новые подходы в решении типовых задач.

1. fubectl

Для начала посмотрим на fubectl, который сам автор называет fancy-kubectl. Этот проект сходу не назовёшь самостоятельной утилитой, т.к. на первый взгляд это лишь подготовленный набор алиасов для kubectl. Как тут не вспомнить похожий kubectl-aliases, про который мы писали 3,5 года назад, когда fubectl еще даже не существовало?.. Возможно, именно в простых вещах кроется сермяжная правда. Итак, автор обещает, что fubectl сделает вашу работу с кластером K8s более эффективной давайте попробуем её в действии.

Установка и запуск. Для полноценной работы утилиты потребуется установить пакет fzf, а также для выполнения отдельных команд (kexp, ktree, neat) понадобятся плагины к kubectl (они ставятся через kubectl krew, для этого есть свой alias об этом чуть ниже).

Основной процесс установки прост и заключается в скачивании одного файла:

curl -LO https://rawgit.com/kubermatic/fubectl/master/fubectl.source

и его добавлению в .bashrc или .zshrc:

[ -f <path-to>/fubectl.source ] && source <path-to>/fubectl.source

Кроме того, для ZSH есть альтернативный путь установки с помощью предпочтительного менеджера плагинов.

Применение. Главный и основной алиас это банальный k, заменяющий команду kubectl. Соответственно, все команды, которыми мы привыкли пользоваться, сокращаются до:

  • k get nodes

  • k get deploy -A

  • k -n mynamespace get pods

Это удобно и практически не требует привыкания. Помимо этого, присутствует набор дополнительных алиасов на команды, которые могут часто использоваться в работе. Например:

  • kw алиас для watch:

    • kw nodes

    • kw pods

    • kw nodes,pods,services

  • kdes describe ресурсов;

  • kdel удаление ресурсов;

  • klog вывод логов контейнера podа.

Обратите внимание, что документация в README проекта не совсем актуальна. В fubectl можно найти и специальные команды, определенные как shell-функции. Среди них, например:

  • ksec для декодирования значения из секрета,

  • kex для выполнения команды в контейнере,

  • konsole для создания и запуска контейнера с root shell.

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

Как работает kex в fubectlКак работает kex в fubectl

Полный список поддерживаемых команд можно увидеть, вызвав khelp:

Последний приятный нюанс: благодаря уже упомянутой fzf в утилиту повсеместно встроен механизм fuzzy-поиска, который упрощает ввод команд.

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

2. Kubelive

Утилита создана с целью упрощения вывода kubectl get pods -w с наглядным отображением статуса podа в режиме реального времени. Под капотом этого детища используется Node.js-библиотека @kubernetes/client-node.

Установка и запуск. Инсталляция:

npm install -g kubelive

Для работы потребуется Node.js не ниже версии v10.

Если kubectl уже настроен на хосте, то больше ничего не требуется.По аналогии с kubectl будет использоваться стандартный .kube/config (или путь, указанный в переменной окружения KUBECONFIG).

Применение. При запуске kubelive мы получаем интерактивную консоль с возможностью переключения между пространствами имен с помощью стрелок на клавиатуре. Также доступны с помощью быстрых клавиш некоторые базовые операции: рестарт podа, копирование его имени, выход из приложения/интерактивного режима:

[D]: Delete [C]: Copy [Q]: Quit

Для получения общего представления об интерфейсе достаточно посмотреть на демонстрацию из README проекта:

Список поддерживаемых команд на текущий момент так ограничен, что можно полностью привести его в статье:

  • kubelive get pods (или просто kubelive) список podов в кластере;

  • kubelive get services список сервисов;

  • kubelive get replicationcontrollers список ReplicationController;

  • kubelive get nodes список узлов;

  • kubelive get <resource> --context <name> список ресурсов в разных контекстах.

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

Если количество namespaceов превышает 30, шапка просто перестает отображать наименования (разработчик об этом знает), а переход между ними добавляет заметную (секунд на 3-5) задержку.

Кроме того, количество podов также имеет значение, т.к. на экране мы увидим только те, которые влезли, это добавляет неудобств Также на данный момент нет возможности фильтрации/указания нужного пространства имен, хотя и существуют несколько issue на эту тему. Ещё не хватает возможности отображения других сущностей Kubernetes (Deployment, StatefulSet и т.п.) и их манифестов.

Ко всему прочему, не стоит забывать, что для своей работы утилита требует установки Node.js со всеми ее зависимостями (а их не так мало). Используя kubelive на больших кластерах, я заметил, как растёт потребление CPU этой утилитой при беглом переключении по вкладкам namespaceов.

Подводя итог: этот инструмент, существующий с августа 2019 года, показался недостаточно зрелым, но сами реализованные в нем идеи (удобное представление информации о Kubernetes-кластере в консоли), пожалуй, еще найдут свой отклик. Наконец, хотя заявленный проектом Roadmap и может внушить некоторый оптимизм в смысле функциональных перспектив его единственный разработчик утратил реальную активность с прошлого года, что говорит не в пользу будущего Kubelive.

3. Web Kubectl

Это решение иного толка: оно позволяет работать с kubectl прямо из браузера и посему не требует его установки на десктопе или серверах. Для этого в Web Kubectl используют собственный форк проекта gotty, что позволяет запускать веб-терминал на базе JavaScript.

Установка и запуск. Для запуска приложения предлагается использовать Docker-образ:

docker run --name="webkubectl" -p 8080:8080 -d --privileged kubeoperator/webkubectl

После этого достаточно перейти на localhost:8080 и загрузить kubeconfig-файл или указать service account tokens для доступа к Kubernetes-кластеру:

Применение. Зайдя в одну из сессий, мы получаем возможность использовать терминал с kubectl прямо в браузере:

При этом есть поддержка одновременного использования, т.к. присутствует изоляция сеанса на уровне сессии. У каждого сеанса под капотом свое изолированное пространство (подпроцесс запускается в новом пространстве имен Linux через unshare), которое не доступно для других. Там и создается файл .kube/config. При завершении сеанса предоставленное пространство имен и хранилище удаляются. По умолчанию время сеанса не ограничено по времени, но это можно изменить через gotty.

Помимо штатного kubectl в вашем распоряжении также Helm, k9s (о нем мы уже писали), kubectx и даже уже упомянутый в нашем прошлом обзоре набор алисов.

Отдельно выделю наличие API, с помощью которого можно осуществлять доступ к веб-терминалу. Для этого потребуется сформировать токен с содержимым kubeconfig в base64 (cat ~/.kube/config.yaml | base64 -w0):

$ curl http://<webkubectl-address>:<port>/api/kube-config -X POST -d '{"name":"k8s-cluster-bj1","kubeConfig":"<kubeconfig file content base64 encoded>"}'

Ту же самую операцию можно осуществить через запрос к Kubernetes API server и bearer token:

$ curl http://<webkubectl-address>:<port>/api/kube-token -X POST -d '{"name":"gks-hk-dev","apiServer":"https://k8s-cluster:6443","token":"token-content"}'

Если все сделано правильно, в ответе будет получен токен:

{"success":true,"token":"lgfgbp1wkjxzmmbuypbj","message":""}

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

http://<webkubectl-address>:<port>/terminal/?token=<token fetched from api>

Токен перестает быть действительным сразу после первого использования или же через 5 минут простоя.

Если же вы захотите запускать Web Kubectl не локально, обратите внимание, что по умолчанию трафик между сервером и клиентом не защищен: использовать SSL-сертификат и добавлять базовую авторизацию рекомендуется через все тот же gotty. Таким образом, например, можно настроить доступ к изолированному кластеру в VPC вот схема из документации проекта:

_______________________________________________________________________|   Local Network     |          DMZ           |      VPC/Datacenter  ||                     |                        |                      ||                     |    _______________     |   ----------------   ||   ---------------   |    |             |  /~~~~~>| Kubernetes A |   ||   | Your Laptop |~~~~~~~>| Web Kubectl | /   |   ----------------   ||   ---------------   |    |             | \   |                      ||                     |    ---------------  \  |   ----------------   ||                     |                      \~~~~>| Kubernetes B |   ||                     |                        |   ----------------   |-----------------------------------------------------------------------

Для запуска Web Kubectl также доступны дополнительные переменные среды с говорящими за себя названиями:

  • SESSION_STORAGE_SIZE

  • KUBECTL_INSECURE_SKIP_TLS_VERIFY

  • GOTTY_OPTIONS

  • WELCOME_BANNER

Опыт использования. Инструмент показал себя с хорошей стороны и оставил приятные впечатления по быстродействию. Наличие API дает возможность интегрировать webkubectl в свое приложение, а частота релизов на GitHub показывает интерес авторов к своему проекту. Во многом этот интерес объясняется тем, что webkubectl часть более крупного проекта, готового для production дистрибутива Kubernetes под названием KubeOperator от той же китайской компании. Из личных пожеланий проекту отмечу, что было бы здорово иметь возможность группировки сессий, а также административную панель для управления доступом.

Заключение

Популярность Kubernetes с каждым днем растет, как и количество приложений и сервисов вокруг этой технологии. Всё это формирует развитую экосистему и даёт нам возможность пользоваться удобными инструментами для решения практически любых задач. Этот обзор был посвящен трем проектам, объединенным одной темой kubectl, и разным не только по своему назначению, но и тем впечатлениям, что оставили при первом знакомстве с ними. Надеюсь, какие-то из них могут оказаться полезными и для вас.

P.S.

Читайте также в нашем блоге:

Подробнее..
Категории: Kubernetes , Системное администрирование , Devops , Cli , Блог компании флант , Kubectl

Перевод Контролируем удаление с финализаторами

18.06.2021 08:07:31 | Автор: admin

image


В Kubernetes не так-то просто что-то удалить вы уверены, что удалили объект, но оказывается, что он все еще присутствует в кластере. Вы, конечно, можете выполнять команду kubectl delete в повседневных операциях и надеяться на лучшее, но знание принципов работы delete команд в Kubernetes поможет вам понять, почему некоторые объекты остаются после удаления.


В этой статье мы рассмотрим:


  • Какие свойства ресурса влияют на удаление.
  • Как финализаторы и ссылки на родителя-владельца управляют удалением объектов.
  • Как можно использовать propagationPolicy, чтобы изменить порядок удаления.
  • Как работает удаление, с примерами.

Для простоты во всех примерах мы используем ConfigMaps и базовые команды kubectl. Мы увидим, как работают эти команды, и обсудим результаты их использования на практике.


Базовая команда delete


В Kubernetes есть несколько команд для создания, чтения, обновления и удаления объектов. Здесь мы поговорим о четырех командах kubectl: create, get, patch и delete.
Примеры базовой команды kubectl delete:


kubectl create configmap mymapconfigmap/mymap created


kubectl get configmap/mymapNAME    DATA   AGEmymap   0      12s


kubectl delete configmap/mymapconfigmap "mymap" deleted


kubectl get configmap/mymapError from server (NotFound): configmaps "mymap" not found

Перед командой стоит знак $, далее следует ее результат. Как видите, мы начали с kubectl create configmap mymap, чтобы создать пустой configmap mymap. Теперь нужно выполнить get и убедиться, что он существует. Затем мы удалили configmap. Если снова сделать get, получим ошибку HTTP 404, потому что configmap не найден.


У команды deleteочень простая диаграмма состояний:


image
Диаграмма состояний для delete


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


Как работают финализаторы


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


Финализаторы это ключи в манифесте ресурса, отвечающие за операции, которые надо выполнить до удаления объекта. Они контролируют сборку мусора для ресурсов и сообщают контроллерам, какие операции очистки нужно выполнить до удаления ресурса. Они не обязательно обозначают код, который нужно выполнить. По сути, это просто списки ключей, вроде аннотаций. Как и аннотациями, ими также можно управлять.


Скорее всего, вы встречали следующие финализаторы:


  • kubernetes.io/pv-protection
  • kubernetes.io/pvc-protection

Они используются для постоянных томов и не дают случайно удалить их. Точно так же некоторые финализаторы могут использоваться для предотвращения удаления любого ресурса.


Ниже приводится configmap без свойств, но с финализатором:


cat <<EOF | kubectl create -f -apiVersion: v1kind: ConfigMapmetadata:  name: mymap  finalizers:  - kubernetesEOF

Контроллер ресурса configmap не понимает, что делать с ключом финализатора kubernetes. Такие финализаторы для configmap я называю мертвыми, и обычно они используются с неймспейсами. Вот что происходит при попытке удалить configmap:


kubectl delete configmap/mymap &configmap "mymap" deletedjobs[1]+  Running kubectl delete configmap/mymap

Kubernetes сообщает, что объект удален, но на самом деле, в традиционном понимании, никуда он не удален. Скорее он находится в процессе удаления. Если мы снова выполним get, то узнаем, что объект изменен и теперь содержит временную метку удаления deletionTimestamp.


kubectl get configmap/mymap -o yamlapiVersion: v1kind: ConfigMapmetadata:  creationTimestamp: "2020-10-22T21:30:18Z"  deletionGracePeriodSeconds: 0  deletionTimestamp: "2020-10-22T21:30:34Z"  finalizers:  - kubernetes  name: mymap  namespace: default  resourceVersion: "311456"  selfLink: /api/v1/namespaces/default/configmaps/mymap  uid: 93a37fed-23e3-45e8-b6ee-b2521db81638

Если в двух словах, объект был изменен, но не удален. Все потому, что Kubernetes увидел, что у объекта есть финализаторы, и поместил его в состояние read-only. Временная метка удаления показывает, что объект можно только читать а еще из него можно удалить апдейты ключа финализатора. Другими словами, удаление будет завершено, только когда мы удалим из объекта финализатор.


Удалить финализаторы можно с помощью команды patch. Фоновое удаление завершится, и объект будет удален. Если мы опять выполним get configmap, то ничего не увидим.


kubectl patch configmap/mymap \    --type json \    --patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'configmap/mymap patched[1]+  Done  kubectl delete configmap/mymapkubectl get configmap/mymap -o yamlError from server (NotFound): configmaps "mymap" not found

Диаграмма состояния для финализации выглядит так:


image
Диаграмма состояний для финализации


Если мы попытаемся удалить объект с финализатором, он останется на этапе финализации, пока контроллер не удалит ключи финализаторов или финализаторы не будут удалены через Kubectl. Когда список финализаторов будет пуст, Kubernetes поместит его в очередь на удаление из реестра.


Ссылки на владельца


Ссылки на владельца (owner references) описывают отношения между группами объектов. Это свойства ресурсов, которые указывают, как они связаны друг с другом, чтобы можно было удалять целые деревья ресурсов.


Правила финализатора обрабатываются, если есть ссылки на владельца. Ссылки на владельца состоят из имени и UID. Они связывают ресурсы в одном неймспейсе и им нужен UID. Ссылки на владельца для подов обычно указывают на replica set, которому они принадлежат. Если удалить deploy или stateful set, дочерние replica set и pod тоже удалятся.


Посмотрим на примере, как работают ссылки на владельца. В первом примере мы сначала создаем родительский объект, а потом дочерний. В результате получаем простейший configmap со ссылками на владельца, то есть родителя:


cat <<EOF | kubectl create -f -apiVersion: v1kind: ConfigMapmetadata:  name: mymap-parentEOFCM_UID=$(kubectl get configmap mymap-parent -o jsonpath="{.metadata.uid}")cat <<EOF | kubectl create -f -apiVersion: v1kind: ConfigMapmetadata:  name: mymap-child  ownerReferences:  - apiVersion: v1    kind: ConfigMap    name: mymap-parent    uid: $CM_UIDEOF

Если мы удалим дочерний объект, в котором есть ссылка на владельца, родитель никуда не денется:


kubectl get configmapNAME           DATA   AGEmymap-child    0      12m4smymap-parent   0      12m4skubectl delete configmap/mymap-childconfigmap "mymap-child" deletedkubectl get configmapNAME           DATA   AGEmymap-parent   0      12m10s

В следующем случае мы воссоздали configmap из примера выше. Если мы удалим родителя, а не дочерний объект, в котором есть ссылка на него, а потом сделаем get для configmap, то увидим, что все configmap пропали:


kubectl get configmapNAME           DATA   AGEmymap-child    0      10m2smymap-parent   0      10m2skubectl delete configmap/mymap-parentconfigmap "mymap-parent" deletedkubectl get configmapNo resources found in default namespace.

Получается, что если в дочернем объекте есть ссылка на родителя, он автоматически удаляется при удалении родителя. Это называется cascade. По умолчанию cascade имеет значение true, но можно указать --cascade=false в kubectl delete, чтобы удалить родительский объект, не трогая дочерние.


В следующем примере у нас есть родительский и дочерний объекты, а еще ссылки на владельца. Если мы удалим родителя, указав --cascade=false, дочерние объекты сохранятся:


kubectl get configmapNAME           DATA   AGEmymap-child    0      13m8smymap-parent   0      13m8skubectl delete --cascade=false configmap/mymap-parentconfigmap "mymap-parent" deletedkubectl get configmapNAME          DATA   AGEmymap-child   0      13m21s

Параметр --cascade указывает на политику распространения в API, которая позволяет менять порядок объектов удаления в дереве. В следующем примере используется отправка запроса к API через curl для удаления с фоновой политикой распространения (propagation policy):


kubectl proxy --port=8080 &Starting to serve on 127.0.0.1:8080curl -X DELETE \  localhost:8080/api/v1/namespaces/default/configmaps/mymap-parent \  -d '{ "kind":"DeleteOptions", "apiVersion":"v1", "propagationPolicy":"Background" }' \  -H "Content-Type: application/json"{  "kind": "Status",  "apiVersion": "v1",  "metadata": {},  "status": "Success",  "details": { ... }}

Политику распространения нельзя указать в командной строке с помощью kubectl только при прямом вызове API. Просто создайте прокси, чтобы иметь доступ к серверу API со своего компьютера, и выполните команду curl с одним URL, чтобы послать команду delete.


Есть три варианта политики распространения:


  • Foreground: дочерние объекты удаляются до родительского (обратный порядок).
  • Background: родительский объект удаляется до дочерних (прямой порядок).
  • Orphan: ссылки на владельца игнорируются.

Если вы удаляете объект, в котором есть ссылки на владельца, то финализаторы также будут учитываться. В результаты деревья объектов могут сохраняться, и удаление будет частичным. В этом случае изучите имеющиеся ссылки на владельца и финализаторы, чтобы понять, что происходит.


Принудительное удаление неймспейса


В некоторых случаях для удаления неймспейсов может потребоваться принудительная финализация: если вы удалили неймспейс и очистили все объекты в нем, но неймспейс по-прежнему существует, его можно удалить принудительно, обновив его подресурс, finalize. Так контроллер неймспейса поймет, что нужно удалить финализатор и выполнить очистку:


cat <<EOF | curl -X PUT \  localhost:8080/api/v1/namespaces/test/finalize \  -H "Content-Type: application/json" \  --data-binary @-{  "kind": "Namespace",  "apiVersion": "v1",  "metadata": {    "name": "test"  },  "spec": {    "finalizers": null  }}EOF

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


Итоги


Как показывают примеры, финализаторы могут помешать удалению ресурсов в Kubernetes, особенно если речь о родительских и дочерних объектах. Обычно финализаторы добавляются в код не просто так, поэтому нужно все проверить, прежде чем удалять их вручную. С помощью ссылок на владельца можно указывать и удалять деревья ресурсов, хотя и в этом случае будут учитываться финализаторы. Наконец, можно использовать политику распространения, чтобы указывать порядок удаления в прямых вызовах API и контролировать процесс удаления объектов. Теперь вы чуть больше знаете о том, как работает удаление в Kubernetes, и можете поэкспериментировать самостоятельно в продакшен-кластере.


Видео от автора:


Подробнее..
Категории: Kubernetes , Системное администрирование , Devops , Блог компании southbridge , Серверное администрирование , K8s , Kubectl , Finalizers

Сборник полезных ссылок для системного администратора

14.08.2020 14:14:13 | Автор: admin


Сборник полезных ссылок для системного администратора, руководства, инструкции, учебные курсы, секреты-советы и многое другое ниже в нашем еженедельном посте.

Когда вы системный администратор, то отвечаете не за что-то одно, а сразу на всё. Причем горящие задачи частенько возникают самым внезапным образом. Если не заниматься чем-то каждый день, оно рано или поздно вылетает из головы, и вы просто не можете вспомнить нужные команды и опции именно в том момент, когда кругом всё горит и рушится. Поэтому мы подготовили 10 полезных шпаргалок, которые пригодятся вне зависимости от того, насколько вы крутой сисадмин:

  • Сети
    PDF-шпаргалка по утилитам и командам Linux для управления серверами и сетями.
  • Файрвол
    Эта шпаргалка поможет прокачать знания по безопасности Linux.
  • Продвинутый SSH
    Для большинства SSH это просто инструмент для удаленного входа. А на самом деле он может гораздо больше.
  • Пользователи и разрешения
    Здесь собраны примеры и команды, которые пригодятся при управлении пользователями и разрешениями.
  • Базовые команды
    Linux-команды для рутинных задач: навигация и управление файлами, установка софта на типовых дистрибутивах, сервисы.
  • Git
    Сегодня это де-факто стандарт управления версиями, пора научиться работать с ним эффективно.
  • Curl
    Типовые синтаксисы и сценарии применения утилиты curl, в том числе, как использовать ее для запроса API.
  • SELinux
    Полезное руководство по использованию и работе с Security-Enhanced Linux.
  • Kubectl
    9 важных команд kubectl для устранения неполадок и управления кластерами Kubernetes.
  • awk
    Памятка по типовым функциями awk.

Бонус: Bash-сценарии руководство для сисадминов



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

Почтовая рассылка Enable Sysadmin

Руководства, инструкции, учебные курсы, секреты-советы и многое другое.
Подробнее..
Категории: Системное администрирование , Open source , Linux , Git , Настройка linux , Учебный процесс в it , Curl , Блог компании red hat , Red hat , Bash , Ssh , Kubectl , Selinux , Awk

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru