Как установить dashboard kubernetes

Как установить dashboard kubernetes

4 contributors

Users who have contributed to this file

The fastest way of deploying Dashboard has been described in our README. It is destined for people that are new to Kubernetes and want to quickly start using Dashboard. Other possible setups for more experienced users, that want to know more about our deployment procedure can be found below.

To access Dashboard directly (without kubectl proxy ) valid certificates should be used to establish a secure HTTPS connection. They can be generated using public trusted Certificate Authorities like Let’s Encrypt, optionally Cert-Manager can auto-issue and auto-renew them. Use them to replace the auto-generated certificates from Dashboard.

By default self-signed certificates are generated and stored in-memory. In case you would like to use your custom certificates follow the below steps, otherwise skip directly to the Dashboard deploy part.

Under Deployment section, add arguments to pod definition, it should look as follows:

—auto-generate-certificates can be left in place, and will be used as a fallback.

This setup is not fully secure. Certificates are not used and Dashboard is exposed only over HTTP. In this setup access control can be ensured only by using Authorization Header feature.

To deploy Dashboard execute following command:

Besides official releases, there are also development releases, that are pushed after every successful master build. It is not advised to use them on production environment as they are less stable than the official ones. Following sections describe installation and discovery of development releases.

In most of the use cases you need to execute the following command to deploy latest development release:

Once installed, the deployment is not automatically updated. In order to update it you need to delete the deployment’s pods and wait for it to be recreated. After recreation, it should use the latest image.

Delete all Dashboard pods (assuming that Dashboard is deployed in kubernetes-dashboard namespace):

Источник

Разворачиваем среду для работы с микросервисами. Часть 1 установка Kubernetes HA на bare metal (Debian)

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

Здравствуйте уважаемые читатели Хабра!

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

Данный цикл будет состоять минимум из четырех статей:

Вступление:

Для кого предназначены данные статьи? В первую очередь, для тех, кто только начинает свой путь в изучении Kubernetes. Также данный цикл будет полезен для инженеров, которые думают переходить от монолита к микросервисам. Все описанное — это мой опыт, в том числе полученный и при переводе нескольких проектов из монолита в Kubernetes. Возможно, что какие-то части публикаций будут интересны и опытным инженерам.

Что я не буду подробно рассматривать в данной серии публикаций:

Что я хочу рассмотреть подробно:

Оглавление:

Список и назначение хостов

Все ноды моего кластера будут располагаться на виртуальных машинах с предустановленной системой Debian 9 stretch c ядром 4.19.0-0.bpo.5-amd64. Для виртуализации я использую Proxmox VE.

Таблица ВМ и их ТТХ:

NameIP адресCommentCPUMEMDISK1DISK2
master0110.73.71.25master node4vcpu4GbHDD
master0210.73.71.26master node4vcpu4GbHDD
master0310.73.71.27master node4vcpu4GbHDD
worknode0110.73.75.241work node4vcpu4GbHDDSSD
worknode0210.73.75.242work node4vcpu4GbHDDSSD
worknode0310.73.75.243work node4vcpu4GbHDDSSD

Не обязательно, что у Вас должна быть именно такая конфигурация машин, но все таки я советую придерживаться рекомендациям официальной документации, а для мастеров увеличить количество оперативной памяти минимум до 4Гб. Забегая вперед скажу, что при более маленьком количестве, я ловил глюки в работе CNI Callico
Ceph тоже достаточно прожорлив к памяти и производительности дисков.
Наши продакшн инсталляции работают без виртуализации на голом железе, но я знаю много примеров, где хватало и виртуальных машин с достаточно скромными ресурсами. Все зависит от ваших потребностей и нагрузок.

Список и версии ПО

Kubeadm, начиная с версии 1.14, перестал поддерживать API версии v1alpha3 и полностью перешел на API версии v1beta1, которую будет поддерживать в ближайшем будущем, поэтому в статье я буду рассказывать только про v1beta1.
Итак, мы считаем, что у Вы подготовили машины для kubernetes кластера. Они все доступны друг другу по сети, имеют «выход» в интернет и на них установлена «чистая» операционная система.
Для каждого шага установки я буду уточнять, на каких именно машинах выполняется команда или блок команд. Все команды выполнять из-под пользователя root, если не указано иного.
Все файлы конфигурации, а также скрипт для их подготовки доступны для скачивания в моем github
Итак, начнем.

Схема HA кластера kubernetes

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes
Примерная схема HA кластера. Художник из меня так себе, если честно, но постараюсь объяснить в двух словах и достаточно упрощенно, особо не углубляясь в теорию.
Итак, наш кластер будет состоять из трех master нод и трех worker нод. На каждой master ноде kubernetes у нас будет работать etcd (на схеме зеленые стрелочки) и служебные части kubernetes; назовем их обобщенно — kubeapi.
Через кластер etcd master ноды обмениваются состоянием кластера kubernetes. Эти же адреса я укажу как точки входа ingress контроллера для внешнего трафика (на схеме красные стрелочки)
На worker нодах у нас работает kubelet, который связывается с api сервером kubernetes через haproxy установленным локально на каждой worker ноде. В качестве адреса api сервера для kubelet я буду использовать локалхост 127.0.0.1:6443, а haproxy по roundrobin будет раскидывать запросы по трем master нодам, также он будет проверять доступность master нод. Данная схема позволит нам создать HA, и в случае выхода из строя одной из master нод, worker ноды будут спокойно посылать запросы на две оставшихся в живых master ноды.

Перед началом работы

Перед началом работы на каждую ноду кластера поставим пакеты, которые нам понадобятся для работы:

На master ноды скопируем репозиторий с шаблонами конфигов

Проверим, что ip адрес хостов на мастерах соответствует тому, на котором будет слушать API сервер kubernetes

и так для всех master нод.

Обязательно отключите SWAP, иначе kubeadm будет выдавать ошибку

Отключить можно командой

Не забудьте закомментировать в файле /etc/fstab

Заполняем файл create-config.sh

Для автоматического заполнения конфигов, нужных для установки кластера kubernetes, я накидал небольшой скриптик create-config.sh. Вам нужно заполнить в нем буквально 8 строчек. Указать IP адреса и hostname своих мастеров. А также указать etcd tocken, можете его не менять. Я приведу ниже ту часть скрипта в которой нужно сделать изменения.

Обновление ядра ОС

Данный шаг является необязательным, так как ядро нужно будем обновлять из back портов, и делаете Вы это на свой страх и риск. Возможно, Вы никогда столкнетесь с данной проблемой, а если и столкнетесь, то обновить ядро можно и после разворачивания kubernetes. В общем, решать Вам.
Обновление ядра требуется для устранения старого бага docker, который исправили только в ядре linux версии 4.18. Более подробно про этот баг можно почитать вот здесь. Выражался баг в периодическом зависании сетевого интерфейса на нодах kubernetes c ошибкой:

У меня после установки ОС было ядро версии 4.9

На каждой машине для kubernetes выполняем
Шаг №1
Добавляем back ports в source list

Источник

How to Install and Configure the Kubernetes Dashboard

The web-based Kubernetes console is an interface that provides information about the state of the Kubernetes cluster. The dashboard is also used for deploying containerized applications as well as for general cluster resource management. Traditionally, kubectl is primarily used in the terminal for nearly all cluster related tasks. Still, it is useful to have a visual representation of our cluster in a user-friendly interface. To install the dashboard, kubectl needs to be installed and running on the server.

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

Deploy Kubernetes Dashboard

First, we will deploy the k8s dashboard using the kubectl command in the terminal.

Import Default Configuration

Next, we will download a default configuration to our server.В

Reconfigure

We will replace the default configuration file with the one we have just downloade d, edit it, and then apply the specific changes unique to our settings.

Now, we should e dit the configuration file and enter the following settings.

Lastly, save and exit the file using the :wq command in vim.

Apply Changes

To apply our changes, we will use the kubectl apply command to implement the previous modifications we made to our configuration. This effectively locks in our updates, which are then applied to our existing system.

Verify Status

Now we will c heck the Dashboard’s creation and deployment status using this command.

Create Modules

Next, we will c reate two modules; one for the dashboard and one for the metrics. The dash n (-n) flag represents a namespace.

Check Service

Now we can check the NodePort service that we modified earlier. Notice the kubectl get command now defines ‘services,’ which includes the nodeport IP’s.

To use the Kubernetes Dashboard, we need to create an administrator user. The admin user can modify objects in all namespaces and manage any components of the cluster.

Create Manifest File

First, we will c reate a service account manifest file in which we will define the administrative user for kube-admin and the associated namespace they have access to.

Next, we add the following information to the Yaml file and apply it using the kubectl apply command.

This command applies the specific settings.

Next, we will bind the cluster-admin role to t he created user.

Once the file is open in vim, enter the following information.

Save the file using the :wq command in vim and a pply the changes to the file.

Set Variable

In this step, we store the specific name of the service account.

Now we will g enerate a token for the account. This is necessary for security and further employment of the user in other systems, namespaces, or clusters.

We would advise keeping the token as secure as possible. After creating the token, we can finally access the dashboard control panel. Copy the key as we will need it momentarily to access the dashboard.

Access the Dashboard

Before accessing the dashboard, it should be noted that it deploys a minimal RBAC configuration by default and requires a Bearer Token to log in. This is the token we created above. To locate the port and IP address, run this command.

In our setup, w e used port 30741, as you can see in the second line of output of the previous command. You can log in using this port on any server.

We can also access the dashboard using the following kubectl command.

Next, e nter the token noted above on this screen and click the ‘Sign In‘ button.

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

This opens the default dashboard view.

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

This completes the installation and configuration of the Kubernetes dashboard.

Deploy a Containerized Application

The Dashboard provides other benefits, such as allowing us to create and deploy containerized applications using a simple wizard. You can manually add specific app info or upload a file containing the application’s configuration in either a YAML or JSON format. Click theВ ‘CREATE‘В button in the upper-right corner of any page to start that process.

Other Features

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

Get started Today!

Our Support Teams are filled with experienced Linux technicians and talented system administrators who have intimate knowledge of multiple web hosting technologies, especially those discussed in this article.

Should you have any questions regarding this information, we are always available to answer any inquiries with issues related to this article, 24 hours a day, 7 days a week 365 days a year.

If you are a Fully Managed VPS server, Cloud Dedicated, VMWare Private Cloud, Private Parent server, Managed Cloud Servers, or a Dedicated server owner and you are uncomfortable with performing any of the steps outlined, we can be reached via phone at @800.580.4985, a chat, or support ticket to assisting you with this process.

Источник

Adam the Automator

How to Install and Set Up Kubernetes Dashboard [Step by Step]

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

Shanky

Read more posts by this author.

If you’re deploying hundreds of containers within Kubernetes, how do you keep an eye on them all? A command-line interface won’t work. You need a visual representation of everything. Introducing Kubernetes dashboard.

Kubernetes Dashboard is the official web-based UI for Kubernetes user interface, consisting of a group of resources to simplify cluster management.

In this tutorial, you will learn how to install and set up the Kubernetes Dashboard step by step on an Ubuntu machine.

Prerequisites

This post will be a step-by-step tutorial. To follow along, be sure you have:

Installing Kubernetes Dashboard

Before you can start to enjoy the benefits of the Kubernetes Dashboard, you must first install it, so let’s get into it. To install Kubernetes Dashboard, you’ll need the kubectl command-line interface tool. Kubectl is a command-line tool that manages a Kubernetes Dashboard installation and many other Kubernetes tasks.

Enough talk; let’s install the Kubernetes dashboard.

1. First, open your favorite SSH client and connect to your Kubernetes master node.

2. Next, install the Kubernetes dashboard by running the kubectl apply command as shown below. The kubectl apply command downloads the recommended.yaml file and invokes the instructions within to set up each component for the dashboard.

As you see below, all the resources inside the Kubernetes dashboard, such as service, deployment, replica set, pods, are deployed successfully in the cluster.

Setting up the Kubernetes Dashboard

By now, you have a functional Kubernetes dashboard running, but it still requires a bit of configuration to be fully functional. You must now configure the dashboard to be available outside the cluster by exposing the dashboard service.

Assuming you are still connected to the Kubernetes machine through the SSH client:

1. Edit the Kubernetes dashboard service created in the previous section using the kubectl edit command, as shown below. Running the below command will open an editable service configuration file displaying the service configuration.

2. Once the file is opened, change the type of service from ClusterIP to NodePort and save the file as shown below. By default, the service is only available internally to the cluster ( ClusterIP ) but changing to NodePort exposes the service to the outside.

Setting the service type to NodePort allows all IPs (inside or outside of) the cluster to access the service.

In the below code snippet, the Kubernetes dashboard service is listening on TCP port 443 and maps TCP port 8443 from port 443 to the dashboard pod port TCP/8443.

Whenever you modify the service type, you must delete the pod. Once deleted, Kubernetes will create a new one for you with the updated service type to access the entire network.

6. Now, create a service account using kubectl create serviceaccount in the kubernetes-dashboard namespace. You’ll need this service account to authenticate any process or application inside a container that resides within the pod.

When you create a service account, a service account token also gets generated; this token is stored as a secret object.

7. Fetch the service token secret by running the kubectl get secret command. You’ll use this token to access the dashboard in the next section.

8. Create the clusterrolebinding rule using the kubectl create clusterrolebinding command assigning the cluster-admin role to the previously-created service account to have full access across the entire cluster.

Accessing the Kubernetes Dashboard

Now that you’ve installed and set up the Kubernetes dashboard, the only thing left to do is enjoy its functionality!

Open your favorite browser and navigate to https://kuberntes-master-node:NodePort/#/login to access the Kubernetes dashboard.

The Kubernetes master node is the host you’ve installed the dashboard onto, while the node port is the node port found in step five of the previous section.

The main Kubernetes Dashboard page requires you to authenticate either via a valid bearer token or with a pre-existing kubeconfig file. For this tutorial, you’ll be using the token generated in the previous section to access the Kubernetes dashboard.

Ensure you have selected Token and provide the secret token obtained from step seven in the previous section. If all goes well, the dashboard should authenticate you and present to you the Services page.

Ensuring Resources Show up in the Dashboard

Your Kubernetes dashboard is now installed and working. Great! But, as one final task, let’s create a simple deployment with the dashboard to ensure it’s working as expected.

Let’s come up with a basic example like adding an NGINX service to the cluster via the dashboard and hope it all goes well!

Assuming you are already logged into the Kubernetes dashboard:

Click on the Services option from the Service menu. You’ll see each service running on the cluster. Next, click on the add button (plus sign) on the top right-hand corner, as shown below.

Copy and paste the below content into the Create from Input tab and click on the upload button to send the service configuration to the cluster.

If all goes well, the dashboard should then display the nginx service on the Services page!

NGINX service is deployed on the Kubernetes dashboard.

Conclusion

You should now know how to deploy and access the Kubernetes dashboard. The Kubernetes dashboard is a visual way to manage all of your cluster resources without dropping down to the command line.

Now that you have a Kubernetes dashboard set up, what applications will you deploy next to it?

More from Adam The Automator & Friends

Get this interactive comic book to learn how Veeam and AWS can help you fight ransomware, data sprawl, rising cloud costs, unforeseen data loss and make you a hero!

ATA is known for its high-quality written tutorials in the form of blog posts. Support ATA with ATA Guidebook PDF eBooks available offline and with no ads!

Источник

Установка и настройка кластера Kubernetes на Ubuntu Server

Есть различные готовые реализации кластера Kubernetes, например:

Использовать одну из готовых реализаций — быстрый и надежный способ развертывания системы оркестрации контейнеров Docker. Однако, мы рассмотрим ручное создание кластера Kubernetes из 3-х нод — один мастер (управление) и две рабочие ноды (запуск контейнеров).

Для этого выполним следующие шаги:

Подготовка системы

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

Настройка системы

1. Задаем имена узлам. Для этого выполняем команды на соответствующих серверах:

hostnamectl set-hostname k8s-master1.dmosk.local

hostnamectl set-hostname k8s-worker1.dmosk.local

hostnamectl set-hostname k8s-worker2.dmosk.local

* в данном примере мы зададим имя k8s-master1 для мастера и, соответственно, k8s-worker1 и k8s-worker2 — для первого и второго рабочих нод. Каждая команда выполняется на своем сервере.

Необходимо, чтобы наши серверы были доступны по заданным именам. Для этого необходимо на сервере DNS добавить соответствующие А-записи. Или на каждом сервере открываем hosts:

И добавляем записи на подобие:

192.168.0.15 k8s-master1.dmosk.local k8s-master1
192.168.0.20 k8s-worker1.dmosk.local k8s-worker1
192.168.0.25 k8s-worker2.dmosk.local k8s-worker2

* где, 192.168.0.15, 192.168.0.20, 192.168.0.25 — IP-адреса наших серверов, k8s-master1, k8s-worker1, k8s-worker2 — имена серверов, dmosk.local — наш внутренний домен.

2. Устанавливаем необходимые компоненты — дополнительные пакеты и утилиты. Для начала, обновим список пакетов и саму систему:

apt-get update && apt-get upgrade

Выполняем установку пакетов:

apt-get install curl apt-transport-https git iptables-persistent

В процессе установки iptables-persistent может запросить подтверждение сохранить правила брандмауэра — отказываемся.

3. Отключаем файл подкачки. С ним Kubernetes не запустится.

Выполняем команду для разового отключения:

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

И комментируем строку:

#/swap.img none swap sw 0 0

4. Загружаем дополнительные модули ядра.

* модуль br_netfilter расширяет возможности netfilter (подробнее); overlay необходим для Docker.

Загрузим модули в ядро:

Проверяем, что данные модули работают:

lsmod | egrep «br_netfilter|overlay»

Мы должны увидеть что-то на подобие:

overlay 114688 10
br_netfilter 28672 0
bridge 176128 1 br_netfilter

5. Изменим параметры ядра.

Создаем конфигурационный файл:

net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

* net.bridge.bridge-nf-call-iptables контролирует возможность обработки трафика через bridge в netfilter. В нашем примере мы разрешаем данную обработку для IPv4 и IPv6.

Применяем параметры командой:

Брандмауэр

Для мастер-ноды и рабочей создаем разные наборы правил.

По умолчанию, в Ubuntu брандмауэр настроен на разрешение любого трафика. Если мы настраиваем наш кластер в тестовой среде, настройка брандмауэра не обязательна.

1. На мастер-ноде (Control-plane)

* в данном примере мы открываем следующие порты:

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

2. На рабочей ноде (Worker):

На нодах для контейнеров открываем такие порты:

Сохраняем правила командой:

Установка и настройка Docker

На все узлы кластера выполняем установку Docker следующей командой:

apt-get install docker docker.io

После установки разрешаем автозапуск сервиса docker:

systemctl enable docker

<
«exec-opts»: [«native.cgroupdriver=systemd»],
«log-driver»: «json-file»,
«log-opts»: <
«max-size»: «100m»
>,
«storage-driver»: «overlay2»,
«storage-opts»: [
«overlay2.override_kernel_check=true»
]
>

* для нас является важной настройкой cgroupdriver — она должна быть выставлена в значение systemd. В противном случае, при создании кластера Kubernetes выдаст предупреждение. Хоть на возможность работы последнего это не влияет, но мы постараемся выполнить развертывание без ошибок и предупреждений со стороны системы.

И перезапускаем docker:

systemctl restart docker

Установка Kubernetes

Установку необходимых компонентов выполним из репозитория. Добавим его ключ для цифровой подписи:

Создадим файл с настройкой репозитория:

deb https://apt.kubernetes.io/ kubernetes-xenial main

Обновим список пакетов:

apt-get install kubelet kubeadm kubectl

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

apt-mark hold kubelet kubeadm kubectl

Установка завершена — можно запустить команду:

. и увидеть установленную версию программы:

Наши серверы готовы к созданию кластера.

Создание кластера

По-отдельности, рассмотрим процесс настройки мастер ноды (control-plane) и присоединения к ней двух рабочих нод (worker).

Настройка control-plane (мастер ноды)

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

* данная команда выполнит начальную настройку и подготовку основного узла кластера. Ключ —pod-network-cidr задает адрес внутренней подсети для нашего кластера.

Выполнение займет несколько минут, после чего мы увидим что-то на подобие:

.
Then you can join any number of worker nodes by running the following on each as root:

* данную команду нужно вводить на worker нодах, чтобы присоединить их к нашему кластеру. Можно ее скопировать, но позже мы будем генерировать данную команду по новой.

В окружении пользователя создаем переменную KUBECONFIG, с помощью которой будет указан путь до файла конфигурации kubernetes:

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

И добавляем в него строку:

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

На данном этапе мы должны увидеть только мастер ноду:

NAME STATUS ROLES AGE VERSION
k8s-master.dmosk.local NotReady 10m v1.20.2

Чтобы завершить настройку, необходимо установить CNI (Container Networking Interface) — в моем примере это flannel:

* краткий обзор и сравнение производительности CNI можно почитать в статье на хабре.

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

Настройка worker (рабочей ноды)

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

Данная команда покажет нам запрос на присоединения новой ноды к кластеру, например:

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

Run ‘kubectl get nodes’ on the control-plane to see this node join the cluster.

На мастер ноде вводим:

NAME STATUS ROLES AGE VERSION
k8s-master1.dmosk.local Ready control-plane,master 18m v1.20.2
k8s-worker1.dmosk.local Ready 79s v1.20.2
k8s-worker2.dmosk.local Ready 77s v1.20.2

Наш кластер готов к работе. Теперь можно создавать поды, развертывания и службы. Рассмотрим эти процессы подробнее.

Поды — неделимая сущность объекта в Kubernetes. Каждый Pod может включать в себя несколько контейнеров (минимум, 1). Рассмотрим несколько примеров, как работать с подами. Все команды выполняем на мастере.

Создание

Поды создаются командой kubectl, например:

* в данном примере мы создаем под с названием nginx, который в качестве образа Docker будет использовать nginx (последнюю версию); также наш под будет слушать запросы на порту 80.

Чтобы получить сетевой доступ к созданному поду, создаем port-forward следующей командой:

* в данном примере запросы к кластеру kubernetes на порт 8888 будут вести на порт 80 (который мы использовали для нашего пода).

Команда kubectl port-forward является интерактивной. Ее мы используем только для тестирования. Чтобы пробросить нужные порты в Kubernetes используются Services — об этом будет сказано ниже.

Можно открыть браузер и ввести адрес http:// :8888 — должна открыться страница приветствия для NGINX.

Просмотр

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

Например, в нашем примере мы должны увидеть что-то на подобие:

NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 3m26s

Посмотреть подробную информацию о конкретном поде можно командой:

kubectl describe pods nginx

Запуск команд внутри контейнера

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

* в данном примере будет запущена команда date внутри контейнера nginx.

Также мы можем подключиться к командной строке контейнера командой:

Удаление

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

kubectl delete pods nginx

Использование манифестов

В продуктивной среде управление подами выполняется с помощью специальных файлов с описанием того, как должен создаваться и настраиваться под — манифестов. Рассмотрим пример создания и применения такого манифеста.

Создадим файл формата yml:

apiVersion: v1
kind: Pod
metadata:
name: web-srv
labels:
app: web_server
owner: dmosk
description: web_server_for_site
spec:
containers:
— name: nginx
image: nginx:latest
ports:
— containerPort: 80
— containerPort: 443

— name: php-fpm
image: php-fpm:latest
ports:
— containerPort: 9000

— name: mariadb
image: mariadb:latest
ports:
— containerPort: 3306

* в данном примере будет создан под с названием web-srv; в данном поде будет развернуто 3 контейнера — nginx, php-fpm и mariadb на основе одноименных образов.

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

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

Мы должны увидеть ответ:

Смотрим поды командой:

NAME READY STATUS RESTARTS AGE
web-srv 3/3 Ready 0 3m11s

* для Ready мы можем увидеть 0/3 или 1/3 — это значит, что контейнеры внутри пода еще создаются и нужно подождать.

Deployments

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

Создание

Deployment создаем командой со следующим синтаксисом:

* данной командой мы создадим deployment с именем web-set; в качестве образа будем использовать nginx:latest.

Просмотр

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

kubectl get deploy

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

kubectl describe deploy web-set

* в данном примере мы посмотрим описание deployment с названием web-set.

Scaling

Как было написано выше, deployment может балансировать нагрузкой. Это контролируется параметром scaling:

* в данном примере мы указываем для нашего созданного ранее deployment использовать 3 реплики — то есть Kubernetes создаст 3 экземпляра контейнеров.

Также мы можем настроить автоматическую балансировку:

В данном примере Kubernetes будет создавать от 5 до 10 экземпляров контейнеров — добавление нового экземпляра будет происходить при превышении нагрузки на процессор до 75% и более.

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

Редактирование

Для нашего развертывания мы можем изменить используемый образ, например:

* данной командой для deployment web-set мы заменим образ nginx на httpd; ключ record позволит нам записать действие в историю изменений.

Если мы использовали ключ record, то историю изменений можно посмотреть командой:

kubectl rollout history deploy/web-set

Перезапустить deployment можно командой:

kubectl rollout restart deploy web-set

Манифест

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

Создаем новый файл:

apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deploy
labels:
app: web_server
owner: dmosk
description: web_server_for_site
spec:
replicas: 5
selector:
matchLabels:
project: myweb
template:
metadata:
labels:
project: myweb
owner: dmosk
description: web_server_pod
spec:
containers:
— name: myweb-httpd
image: httpd:latest
ports:
— containerPort: 80
— containerPort: 443


apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: web-deploy-autoscaling
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myweb-autoscaling
minReplicas: 5
maxReplicas: 10
metrics:
— type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 75
— type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80

* в данном манифесте мы создадим deployment и autoscaling. Итого, мы получим 5 экземпляров подов для развертывания web-deploy, которые могут быть расширены до 10 экземпляров. Добавление нового будет происходить при превышении нагрузки на процессор более чем на 75% или потреблением оперативной памяти более чем на 80%.

Чтобы создать объекты с помощью нашего манифеста вводим:

deployment.apps/web-deploy created
horizontalpodautoscaler.autoscaling/web-deploy-autoscaling created

Объекты web-deploy и web-deploy-autoscaling созданы.

Удаление

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

kubectl delete deploy web-set

Удалить критерии autoscaling для конкретного развертывания можно командой:

kubectl delete hpa web-set

Удалить все критерии autoscaling можно командой:

Удалить объекты, созданные с помощью манифеста можно командой:

Services

Службы позволяют обеспечить сетевую доступность для развертываний. Существует несколько типов сервисов:

Мы рассмотрим первые два варианта.

Привязка к Deployments

Попробуем создать сопоставления для ранее созданного развертывания:

* где web-deploy — deployment, который мы развернули с помощью манифеста. Публикация ресурса происходит на внутреннем порту 80. Обращаться к контейнерам можно внутри кластера Kubernetes.

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

* данная команда отличается от команды выше только типом NodePort — для данному deployment будет сопоставлен порт для внешнего подключения, который будет вести на внутренний (в нашем примере, 80).

Просмотр

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

kubectl get services

Мы можем увидеть что-то на подобие:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-deploy NodePort 10.111.229.132 80:30929/TCP 21s

* в данном примере указано, что у нас есть служба типа NodePort, а к сервису можно подключиться по порту 30929.

Можно попробовать открыть браузер и ввести http:// :30929 — мы должны увидеть нужную нам страницу (в наших примерах, либо NGINX, либо Apache).

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

Удаление

Удаляем созданную службу командой:

kubectl delete services web-deploy

* в данном примере будет удалена служба для развертывания web-deploy.

Удалить все службы можно командой:

Манифест

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

apiVersion: v1
kind: Service
metadata:
name: web-service
labels:
app: web_server
owner: dmosk
description: web_server_for_site
spec:
selector:
project: myweb
type: NodePort
ports:
— name: app-http
protocol: TCP
port: 80
targetPort: 80

— name: app-smtp
protocol: TCP
port: 25
targetPort: 25

* в данном примере мы создадим службу, которая будем связываться с развертыванием по лейболу project: myweb.

Ingress Controller

В данной инструкции не будет рассказано о работе с Ingress Controller. Оставляем данный пункт для самостоятельного изучения.

Данное приложение позволяет создать балансировщик, распределяющий сетевые запросы между нашими сервисами. Порядок обработки сетевого трафика определяем с помощью Ingress Rules.

Существует не маленькое количество реализаций Ingress Controller — их сравнение можно найти в документе по ссылке в Google Docs.

Для установки Ingress Controller Contour (среди множества контроллеров, он легко устанавливается и на момент обновления данной инструкции полностью поддерживает последнюю версию кластера Kubernetes) вводим:

Установка веб-интерфейса

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

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

Переходим на страницу веб-интерфейса в GitHub и копируем ссылку на последнюю версию файла yaml:

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

* на момент обновления инструкции, последняя версия интерфейса была 2.1.0.

Скачиваем yaml-файл командой:

* где https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml — ссылка, которую мы скопировали на портале GitHub.

Открываем на редактирование скачанный файл:

Комментируем строки для kind: Namespace и kind: Secret (в файле несколько блоков с kind: Secret — нам нужен тот, что с name: kubernetes-dashboard-certs):

.
#apiVersion: v1
#kind: Namespace
#metadata:
# name: kubernetes-dashboard
.
#apiVersion: v1
#kind: Secret
#metadata:
# labels:
# k8s-app: kubernetes-dashboard
# name: kubernetes-dashboard-certs
# namespace: kubernetes-dashboard
#type: Opaque

* нам необходимо закомментировать эти блоки, так как данные настройки в Kubernetes мы должны будем сделать вручную.

Теперь в том же файле находим kind: Service (который с name: kubernetes-dashboard) и добавляем строки type: NodePort и nodePort: 30001 (выделены красным):

kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
type: NodePort
ports:
— port: 443
targetPort: 8443
nodePort: 30001
selector:
k8s-app: kubernetes-dashboard

* таким образом, мы публикуем наш сервис на внешнем адресе и порту 30001.

Для подключения к веб-интерфейсу не через локальный адрес, начиная с версии 1.17, обязательно необходимо использовать зашифрованное подключение (https). Для этого нужен сертификат. В данной инструкции мы сгенерируем самоподписанный сертификат — данный подход удобен для тестовой среды, но в продуктивной среде необходимо купить сертификат или получить его бесплатно в Let’s Encrypt.

И так, создаем каталог, куда разместим наши сертификаты:

Сгенерируем сертификаты командой:

* можно не менять параметры команды, а так их и оставить. Браузер все-равно будет выдавать предупреждение о неправильном сертификате, так как он самоподписанный.

kubectl create namespace kubernetes-dashboard

* это та первая настройка, которую мы комментировали в скачанном файле recommended.yaml.

Теперь создаем настройку для secret с использованием наших сертификатов:

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

Теперь создаем остальные настройки с помощью скачанного файла:

Мы увидим что-то на подобие:

serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created

Создадим настройку для админского подключения:

apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: kubernetes-dashboard
name: dashboard-admin
namespace: kubernetes-dashboard


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: dashboard-admin-bind-cluster-role
labels:
k8s-app: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
— kind: ServiceAccount
name: dashboard-admin
namespace: kubernetes-dashboard

Создаем настройку с применением созданного файла:

Теперь открываем браузер и переходим по ссылке https:// :30001 — браузер покажет ошибку сертификата (если мы настраиваем по инструкции и сгенерировали самоподписанный сертификат). Игнорируем ошибку и продолжаем загрузку.

Kubernetes Dashboard потребует пройти проверку подлинности. Для этого можно использовать токен или конфигурационный файл:

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

На сервере вводим команду для создания сервисной учетной записи:

Создадим привязку нашего сервисного аккаунта с Kubernetes Dashboard:

. получаем токен для подключения (выделен красным):

Data
====
ca.crt: 1066 bytes
namespace: 11 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IkpCT0J5TWF2VWxWQUotdHZYclFUaWwza2NfTW1IZVNuSlZSN3hWUzFrNTAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4tbnRqNmYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMzIwNjVhYmQtNzAwYy00Yzk5LThmZjktZjc0YjM5MTU0Y2VhIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.wvDGeNiTCRBakDplO6PbdqvPH_W2EsBgJjZnTDflneP3cdXQv6VgBkI8NalplXDRF-lF36KbbC2hpRjbkblrLW7BemIVWYOznmc8kmrgCSxO2FVi93NK3biE9TkDlj1BbdiyfOO86L56vteXGP20X0Xs1h3cjAshs-70bsnJl6z3MY5GbRVejOyVzq_PWMVYsqvQhssExsJM2tKJWG0DnXCW687XHistbYUolhxSRoRpMZk-JrguuwgLH5FYIIU-ZdTZA6mz-_hqrx8PoDvqEfWrsniM6Q0k8U3TMaDLlduzA7rwLRJBQt3C0aD6XfR9wHUqUWd5y953u67wpFPrSA

Используя полученный токен, вводим его в панели авторизации:

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

Мы должны увидеть стартовое окно системы управления:

Как установить dashboard kubernetes. Смотреть фото Как установить dashboard kubernetes. Смотреть картинку Как установить dashboard kubernetes. Картинка про Как установить dashboard kubernetes. Фото Как установить dashboard kubernetes

Удаление нод

При необходимости удалить ноду из нашего кластера, вводим 2 команды:

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *