По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
На данный момент Kubernetes является одной из самых интересных технологий в мире DevOps. В последнее время вокруг него образовалось очень много хайпа, по одной простой причине, и причина эта – всемогущие контейнеры. Компания Docker Inc. привлекла народное внимание к контейнерам с помощью маркетинговых компаний о своем прекрасном продукте (у нас есть статья о первоначальной настройке Docker). Но что интересно, Docker – не первопроходец в мире контейнеров, но они положили начало их победоносному походу по миру. Что же было в начале? А в начале были Linux контейнеры, внимание к которым также возросло после такого ажиотажа вокруг Docker контейнеров, при этом и повысив потребность к контейнерным оркестраторам. Давайте поближе познакомимся с Кормчим – он же Kubernetes. Первоначально это являлось разработкой Google, для управления их гигантской инфраструктурой, состоящей из миллионов контейнеров. В какой-то момент Google отдал Кормчего в люди, а именно - Cloud Native Computing Foundation. На данный момент, Docker добавил Kubernetes в свои сборки как один из вариантов оркестраторов наравне с Docker Swarm. Теперь Kubernetes также будет частью сборок Docker Community и Docker Enterprise Edition. Общий обзор Кормчего Пожалуй, тут нужно разъяснить: Kubernetes является греческим именем кормчего или управляющего кораблём В зарубежных коммьюнити Кормчий носит несколько названий – Kubernetes, k8s или kube и является платформой с открытым кодом. Данная платформа позволяет автоматизировать операции с контейнерами – запуск, масштабирование, управление контейнизированными приложениями и так далее. Kubernetes может помочь вам сохранить десятки часов жизни и бесценного времени. Kubernetes позволяет вам помещать в кластер группы хостов с контейнерами и управлять этими кластерами. Эти кластеры могут работать в публичных, частных и гибридных облаках – может, однажды, даже в Хогвартсе откажутся от сложных заклинаний в пользу Kubernetesа. Как я уже упомянул, Kubernetes изначально является разработкой Google, но будет также нелишним знать, что Kubernetes включен во многие облачные коммерческие предложения Корпорации Добра. Сам Google запускает более чем 2 миллиарда контейнеров в неделю. Это почти 300 миллионов контейнеров в день с помощью своей внутренней платформы Borg. Эта платформа – предшественник Kubernetes. Все ошибки Borg были учтены и исправлены в Кормчем./ Использование Kubernetes позволяет получать радость от управления и запуска контейнизированных приложений – он автоматизирует запуск и откаты сборок, мониторит запущенные сервисы – т.е вы можете узнать о том, что что-то пойдет не так еще до непосредственной инициации процесса. Кроме того, Kubernetes управляет ресурсами и может масштабировать необходимые ресурсы для приложений в зависимости от того, сколько им требуется, для того, чтобы избежать лишней траты ресурсов. Как работает Kubernetes? Посмотрите на схему с официального сайта (ссылка ниже): Как вы видите, Kubernetes это очень сложная система (особенно если сравнивать с нативным оркестратором Docker Swarm). Чтобы понять, как он работает, необходимо сначала понять его базовые принципы. Желаемое состояние Желаемое состоятие (Desired state) – это один из базовых концептов Kubernetes. Вы можете указать необходимое состояние для запуска контейнеров в т.н Подах. То есть, к примеру, если контейнер почему-то перестал работать, Kubernetes заново создаст Под основываясь на указанном желаемом состоянии. Kubernetes всегда проверяет состояние контейнеров в кластере, и этим занимается т.н Kubernetes Мастер, который является частью плоскости управления. Можно использовать объект kubectl – он напрямую взаимодействует с кластером для установки или изменения Desired State через Kubernetes API. Объекты Kubernetes Обратимся к официальной документации Kubernetes: объект в Kubernetes это «запись о намерениях» (record of intent) – после создания объекта, Kubernetes будет постоянно проверять наличие этого объекта. При создании объекта, вы сообщаете Кормчему как должна выглядеть загрузка вашего кластера, иначе говоря – каково его желаемое состояние. Состояние сущностей в системе в любой взятый момент времени представлено Kubernetes объектами. Кроме того, объекты также служат как дополнительный уровень абстракции над интерфейсом контейнеров. Вы можете напрямую взаимодействовать с сущностями объектов вместо взаимодействия с контейнерами. Ниже приведем список базовых объектов в Kubernetes. Под (Pod) – наименьшая запускаемая единица в ноде. Это группа контейнеров, которые должны работать вместе. Довольно часто (но не всегда) в поде находится только один контейнер; Сервис(Service) – данный объект используется для обозначения логической суммы подов и политик, используемых для доступа к подам; Раздел (Volume) – директория, которая доступна всем контейнерам внутри пода; Именные пространства (Namespaces) – виртуальные кластеры, поддерживаемые физическим кластером; Также в Kubernetes есть несколько контроллеров, которые построены на базовых объектах и они предоставляют дополнительные фичи. Ниже список данных контроллеров: ReplicaSet - проверяет что какое-то количество копий подов также все время запущено; Deployment - используется для смены текущего состояния на желаемое состояние; StatefulSet - используется для контроля над развертыванием и доступов к разделам; DaemonSet - используется для копирования пода на все ноды кластера или только на указанные ноды; Job - используется для реализации какой-то задачи и прекращения существования после завершения задачи или после указанного времени Плоскость управления в Kubernetes Плоскость управления в Kubernetes используется для установки кластера в желаемое состояние, и для этого Kubernetes выполняет множество задач автоматически – старт и перезагрузка контейнеров, изменение количества реплик приложения и так далее. Различные части плоскости управления, такие как Kubernetes Мастер и процесс kubelet задают тон тому, как Kubernetes взаимодействует с вашим кластером. Плоскость управления содержит записи о всех объектах Kubernetes в системе и запускает бесконечные петли управления для контроля состояния объектов. В каждый момент времени эти петли будут реагировать на изменения в кластере и будет приводить состояние всех объектов в системе из текущего состояния в желаемое. Представьте себе правительство страны, которое проверяет все ли работают и существуют в соответствии с законом. Kubernetes Мастер являются частью плоскости управления, и выполняет такую же задачу по сохранению желаемого состояния во всем вашем кластере. Команда kubectl является интерфейсом для взаимодействия с мастером в кластере через API. В документации написано: «мастер» - это группа процессов, управляющих состоянием кластера. Как правило, все эти процессы запущены одной ноде в кластере и эта нода также называется мастер-нодой. Мастер-нода также может быть реплицирована для избыточности и отказоустойчивости. Каждый мастер в кластере являет собой совокупность следующих процессов: kube-apiserver - единственная точка управления для целого кластера. Команда cubectl взаимодействует напрямую через API; kube-controller-manager - управляет состоянием кластера, управляя различными контроллерами; kube-scheduler - планирует задачи на всех доступных нодах в кластере; Ноды в Kubernetes Ноды в Kubernetes – это ваши «сервера» - виртуалки, физические и так далее, которые находятся в кластере и на которых запущены ваши приложения. Ноды также контролируются мастером и постоянно мониторятся для того, чтобы устанавливать желаемое состояние для приложений. Раньше они назывались «миньонами» - но не теми желтыми милахами из мультика. Каждая нода в кластере держит два процесса: kubelet– интерфейс между нодой и мастером; kube-proxy – сетевая прокси, через которую проходят сервисы, указанные в API на каждой ноде. Также эта прокси может совершать простой TCP и UDP проброс портов; Установка Kubernetes Теперь давайте посмотрим как это работает. Для этого необходимо установить Kubernetes у вас на сервере. Нужно скачать и установить Docker Community Edition версий 17.12.+ и затем для локального запуска нужно установить Minikube. Ссылка для скачивания Docker Community Edition - здесь; Ссылка для скачивания Minikube - тут (MiniKube) При использовании Minikube надо помнить, что создается локальная виртуальная машина и запускает кластер, состоящий из одной ноды. Но ни в коем случае не используйте его для продакшена – Minikube служит исключительно для тестирования и разработки. Для запуска однонодного кластера достаточно лишь выполнить команду minikube start. Бадумс, вы одновременно запустили виртуальную машину, кластер и сам Kubernetes. $minikube start Starting local Kubernetes v1.10.0 cluster... Starting VM... Getting VM IP address... Moving files into cluster... Setting up certs... Connecting to cluster... Setting up kubeconfig... Starting cluster components... Kubectl is now configured to use the cluster. Loading cached images from config file. Для проверки установки надо ввести команду kubectl version $ kubectl version Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T20:00:41Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
img
Python - один из самых популярных языков программирования. Однако в CentOS 8 он не установлен по-умолчанию. В более ранних выпусках CentOS по умолчанию была доступна неверсированная команда Python. После установки CentOS, можно было перейти в оболочку Python, просто запустив команду «python» в терминале. Как это ни парадоксально, CentOS 8 не имеет неверсионной команды Python по умолчанию. Напрашивается вопрос, почему? RedHat заявляет, что этот выбор сделан «чтобы избежать блокировки пользователей в конкретной версии Python». В настоящее время RedHat 8 неявно использует Python 3.6 по умолчанию, хотя Python 2.7 дополнительно предоставляется для поддержки существующего программного обеспечения. Ранее неверсионная команда Python в дистрибутивах CentOS, хотя и была удобной, создавала определенные проблемы. Неверсионный Python обычно указывает на интерпретатор Python 2, но поскольку Python 2 сейчас находится на EOL (конец срока службы), это становится проблематичным по нескольким причинам. Простое перенаправление команды на Python 3 может показаться несложным решением, но на многих уровнях это будет проблематично из-за возможной путаницы с версионированием. Вместо того, чтобы продолжать указывать команду «python» на версию Python по умолчанию из-за знакомства или указывать на Python 3, чтобы идти в ногу со временем, был сделан выбор больше не включать стандартную команду «python». В этом руководстве мы рассмотрим установку как активно используемой версии Python 2, так и новой версии Python 3 в CentOS 8 и Red Hat Enterprise Linux (RHEL) 8. Установка Python 2 Шаг 1. Обновление среды Всегда полезно начинать с проверки того, что все наши системные пакеты обновлены перед установкой нового программного обеспечения. Для этого мы собираемся воспользоваться новым программным обеспечением для управления пакетами DNF. # dnf update -y Шаг 2: Установите Python 2 Теперь, когда среда обновлена, давайте продолжим и будем использовать DNF для установки Python 2. К счастью, и Python 2, и 3 включены в репозитории базовых пакетов CentOS 8, поэтому установка выполняется просто. # dnf install python2 -y Шаг 3: Проверьте установку Python 2 Чтобы убедиться, что Python 2 установлен, мы можем запустить простую команду «python2» с флагом версии. # python2 -V Python 2.7.16 Шаг 4: Запуск Python 2 Впоследствии, чтобы получить доступ к оболочке Python 2, мы можем выполнить следующую команду. # python2 Python 2.7.16 (default, Nov 17 2019, 00:07:27) [GCC 8.3.1 20190507 (Red Hat 8.3.1-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Готово! Python 2 теперь установлен! Следует отметить, что PIP-установщик пакетов Python также устанавливается по умолчанию при установке Python 2, поэтому вы сможете сразу начать работу с пакетами Python. Установка Python 3 Шаг 1. Обновление среды Еще раз давайте убедимся, что наши системные пакеты обновлены. # dnf update -y Шаг 2: Установите Python 3 Теперь мы готовы установить Python 3. # dnf install python3 -y Шаг 3: Проверьте установку Python 3 Мы можем проверить установку и версию Python 3 так же, как и в Python 2. # python3 -V Python 3.7.5rc1 Шаг 4: Запуск Python 3 Затем мы можем войти в среду оболочки Python 3, выполнив следующую команду. # python3 Python 3.6.8 (default, Nov 21 2019, 19:31:34) [GCC 8.3.1 20190507 (Red Hat 8.3.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> Как и в случае установки Python 2, pip3 также включается при установке Python 3. Вот и все! Теперь можно начинать работу с Python на вашем сервере CentOS 8. Установка версии Python по умолчанию Вы должны были заметить, что для использования Python 3, это команда python3 и python2 для Python 2. Что делать, если ваши приложения настроены на обращение к python, который недоступен для всей системы? # python bash: python: command not found... Вы можете использовать механизм альтернатив, чтобы включить неверсированную команду python для всей системы и установить для нее определенную версию: # alternatives --set python /usr/bin/python3 Для Python 2: # alternatives --set python /usr/bin/python2 Чтобы посмотреь настроенную версию Python по умолчанию используйте следующую команду: # python -V Чтобы сбросить эту конфигурацию и удалить неверсионную команду python, выполните: # alternatives --auto python
img
В графическом интерфейсе FreePBX существует коммерческий модуль SysAdmin Pro, стоимость которого составляет $25 (на
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59