Серия вебинаров: Строительные блоки для выполнения CI / CD с Kubernetes

Вступление

Если вы начинаете работать с containers, вы, вероятно, захотите узнать, как автоматизировать сборку, тестирование и развертывание. , Используя Cloud Native подход к этим процессам, вы можете использовать нужные инфраструктурные API для автоматической упаковки и развертывания приложений.

Два строительных блока для автоматизации включают container images и container orchestrators. В течение последнего года или около того Kubernetes стал выбором по умолчанию для оркестровки контейнеров. В этой первой статье серии * CI / CD с Kubernetes * вы будете:

Создавайте образы контейнеров с помощью Docker, Buildah и Kaniko.
Настройте кластер Kubernetes с помощью Terraform и создайте Deployments и Services.
Расширьте функциональность кластера Kubernetes с помощью Custom Resources.

К концу этого руководства у вас будут образы контейнеров, созданные с помощью Docker, Buildah и Kaniko, и кластер Kubernetes с развертываниями, службами и пользовательскими ресурсами.

В следующих статьях этой серии будут рассмотрены смежные темы: управление пакетами для Kubernetes, инструменты CI / CD, такие как Jenkins X и Spinnaker, службы. Меши и GitOps.

Предпосылки

Сервер Ubuntu 16.04 с учетной записью пользователя без полномочий root. Следуйте нашему руководству по Initial Server Setup с Ubuntu 16.04.
Docker установлен на вашем сервере. Пожалуйста, следуйте шагам 1 и 2 из Как установить и использовать Docker в Ubuntu 16.04 для инструкций по установке.
Https://hub.docker.com [учетная запись Docker Hub]. Для ознакомления с началом работы с Docker Hub см. Https://docs.docker.com/docker-hub/[these инструкции].
Учетная запись DigitalOcean и токен личного доступа. Пожалуйста, обратитесь к these инструкциям, чтобы получить свой токен доступа.
Знакомство с контейнерами и докером. Пожалуйста, обратитесь к Webinar Series: Начало работы с контейнерами для получения более подробной информации.
Знакомство с понятиями Kubernetes. Пожалуйста, обратитесь к An Введение в Kubernetes для более подробной информации.

Шаг 1 - Создание изображений контейнеров с помощью Docker и Buildah

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

Создание контейнерных изображений с помощью Dockerfiles

Docker автоматически создает образы вашего контейнера, читая инструкции из Dockerfile, текстового файла, который содержит команды, необходимые для сборки образа контейнера. Используя команду + docker image build +, вы можете создать автоматическую сборку, которая будет выполнять инструкции командной строки, приведенные в Dockerfile. При создании образа вы также передаете build context с Dockerfile, который содержит набор файлов, необходимых для создания среды и запуска приложения в образе контейнера.

Как правило, вы создаете папку проекта для вашего Dockerfile и создаете контекст. Создайте папку с именем ++, чтобы начать:

mkdir
cd

Затем создайте Dockerfile внутри папки + demo +:

nano Dockerfile

Добавьте следующее содержимое в файл:

~ / Демо / Dockerfile

FROM ubuntu:16.04

LABEL MAINTAINER [email protected]

RUN apt-get update \
   && apt-get install -y nginx \
   && apt-get clean \
   && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* \
   && echo "daemon off;" >> /etc/nginx/nginx.conf

EXPOSE 80
CMD ["nginx"]

Этот Dockerfile состоит из набора инструкций, которые создадут образ для запуска Nginx. Во время процесса сборки + ubuntu: 16.04 + будет функционировать как базовый образ, и пакет + nginx + будет установлен. Используя инструкцию + CMD, вы также настраиваете` + nginx` как команду по умолчанию при запуске контейнера.

Затем вы создадите образ контейнера с помощью команды + docker image build, используя текущий каталог (.) В качестве контекста сборки. Передача опции + -t + этой команде присваивает образ ++:

sudo docker image build -t  .

Вы увидите следующий вывод:

OutputSending build context to Docker daemon  49.25MB
Step 1/5 : FROM ubuntu:16.04
---> 7aa3602ab41e
Step 2/5 : MAINTAINER [email protected]
---> Using cache
---> 552b90c2ff8d
Step 3/5 : RUN apt-get update     && apt-get install -y nginx     && apt-get clean     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*     && echo "daemon off;" >> /etc/nginx/nginx.conf
---> Using cache
---> 6bea966278d8
Step 4/5 : EXPOSE 80
---> Using cache
---> 8f1c4281309e
Step 5/5 : CMD ["nginx"]
---> Using cache
---> f545da818f47
Successfully built f545da818f47
Successfully tagged nginx:latest

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

docker image ls

OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nkhare/nginx        latest              4073540cbcec        3 seconds ago       171MB
ubuntu              16.04               7aa3602ab41e        11 days ago

Теперь вы можете использовать изображение + nkhare / nginx: latest + для создания контейнеров.

Создание изображений контейнеров с помощью Project Atomic-Buildah

Buildah - это инструмент CLI, разработанный Project Atomic, для быстрого создания _Open Container Initiative (https://www.opencontainers.org [OCI]) _-совместимых изображений. OCI предоставляет спецификации для времени выполнения контейнеров и изображений в целях стандартизации лучших отраслевых практик.

Buildah может создать изображение из рабочего контейнера или из Dockerfile. Он может создавать изображения полностью в пространстве пользователя без демона Docker и может выполнять такие операции с изображениями, как + build +, + list +, + push + и + tag +. На этом этапе вы скомпилируете Buildah из исходного кода, а затем используете его для создания образа контейнера.

Для установки Buildah вам понадобятся необходимые зависимости, в том числе инструменты, которые позволят вам, среди прочего, управлять пакетами и их безопасностью Выполните следующие команды для установки этих пакетов:

cd
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:alexlarsson/flatpak
sudo add-apt-repository ppa:gophers/archive
sudo apt-add-repository ppa:projectatomic/ppa
sudo apt-get update
sudo apt-get install bats btrfs-tools git libapparmor-dev libdevmapper-dev libglib2.0-dev libgpgme11-dev libostree-dev libseccomp-dev libselinux1-dev skopeo-containers go-md2man

Поскольку вы скомпилируете исходный код + buildah + для создания его пакета, вам также необходимо установить Go:

sudo apt-get update
sudo curl -O https://storage.googleapis.com/golang/go1.8.linux-amd64.tar.gz
sudo tar -xvf go1.8.linux-amd64.tar.gz
sudo mv go /usr/local
sudo echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.profile
source ~/.profile
go version

Вы увидите следующий вывод, указывающий на успешную установку:

Outputgo version go linux/amd64

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

Выполните следующие команды для установки + runc + и + buildah +:

mkdir ~/buildah
cd ~/buildah
export GOPATH=`pwd`
git clone https://github.com/containers/buildah ./src/github.com/containers/buildah
cd ./src/github.com/containers/buildah
make runc all TAGS="apparmor seccomp"
sudo cp ~/buildah/src/github.com/opencontainers/runc/runc /usr/bin/.
sudo apt install buildah

Затем создайте файл + / etc / Containers / registries.conf для настройки ваших реестров контейнеров:

sudo nano /etc/containers/registries.conf

Добавьте следующий файл в файл, чтобы указать свои реестры:

/etc/containers/registries.conf

# This is a system-wide configuration file used to
# keep track of registries for various container backends.
# It adheres to TOML format and does not support recursive
# lists of registries.

# The default location for this configuration file is /etc/containers/registries.conf.

# The only valid categories are: 'registries.search', 'registries.insecure',
# and 'registries.block'.

[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']

# If you need to access insecure registries, add the registry's fully-qualified name.
# An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = []

# If you need to block pull access from a registry, uncomment the section below
# and add the registries fully-qualified name.
#
# Docker only
[registries.block]
registries = []

Файл конфигурации + registries.conf + указывает, к каким реестрам следует обращаться при заполнении имен образов, которые не включают реестр или часть домена.

Теперь выполните следующую команду для создания образа, используя репозиторий + https: // github.com / do-community / rsvpapp-webinar1 + в качестве контекста сборки. Этот репозиторий также содержит соответствующий Dockerfile:

sudo buildah build-using-dockerfile -t rsvpapp:buildah github.com/do-community/rsvpapp-webinar1

Эта команда создает изображение с именем + rsvpapp: buildah + из Dockerfille, доступного в репозитории + https: // github.com / do-community / rsvpapp-webinar1 +.

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

sudo buildah images

Вы увидите следующий вывод:

OutputIMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
b0c552b8cf64         docker.io/teamcloudyuga/python:alpine                    Sep 30, 2016 04:39     95.3 MB

Одним из этих образов является + localhost / rsvpapp: buildah +, который вы только что создали. Другой, + docker.io / teamcloudyuga / python: alpine +, является базовым образом из Dockerfile.

Как только вы создали изображение, вы можете отправить его в Docker Hub. Это позволит вам сохранить его для дальнейшего использования. Сначала вам нужно будет войти в свою учетную запись Docker Hub из командной строки:

docker login -u  -p

После успешного входа вы получите файл + ~ / .docker / config.json +, который будет содержать ваши учетные данные Docker Hub. Затем вы можете использовать этот файл с + buildah + для отправки изображений в Docker Hub.

Например, если вы хотите отправить изображение, которое вы только что создали, вы можете выполнить следующую команду, ссылаясь на + authfile + и изображение, которое нужно нажать:

sudo buildah push --authfile ~/.docker/config.json rsvpapp:buildah docker:///rsvpapp:buildah

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

sudo buildah push rsvpapp:buildah docker-daemon:rsvpapp:buildah

Наконец, взгляните на созданные вами изображения Docker:

sudo docker image ls

OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

nkhare/nginx        latest              01f0982d91b8        17 minutes ago      172MB
ubuntu              16.04               b9e15a5d1e1a        5 days ago          115MB

Как и ожидалось, вы должны увидеть новый образ + rsvpapp: buildah +, который был экспортирован с помощью + buildah +.

Теперь у вас есть опыт создания изображений контейнеров с помощью двух разных инструментов, Docker и Buildah. Давайте перейдем к обсуждению того, как настроить кластер контейнеров с Kubernetes.

Шаг 2 - Настройка кластера Kubernetes в DigitalOcean с использованием kubeadm и Terraform

Существуют разные способы настройки Kubernetes в DigitalOcean. Чтобы узнать больше о том, как настроить Kubernetes с помощью kubeadm, например, вы можете посмотреть на https://www.digitalocean.com / community / tutorials / how-to-create-a-kubernetes-1-11-cluster-using-kubeadm-on-ubuntu-18-04 [Как создать кластер Kubernetes с помощью Kubeadm в Ubuntu 18.04].

Поскольку в этой серии руководств обсуждается подход Cloud Native к разработке приложений, мы будем применять эту методологию при настройке нашего кластера. В частности, мы автоматизируем создание нашего кластера, используя kubeadm и Terraform, инструмент, который упрощает создание и изменение инфраструктуры.

Используя свой личный токен доступа, вы подключитесь к DigitalOcean с Terraform для предоставления 3 серверов. Вы будете запускать команды + kubeadm + внутри этих виртуальных машин, чтобы создать кластер Kubernetes с 3 узлами, содержащий один главный узел и двух рабочих.

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

ssh-keygen -t rsa

Вы увидите следующий вывод:

OutputGenerating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):

Нажмите + ENTER, чтобы сохранить пару ключей в каталоге` + ~ / .ssh` в вашем домашнем каталоге, или введите другой пункт назначения.

Далее вы увидите следующее приглашение:

OutputEnter passphrase (empty for no passphrase):

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

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

OutputYour identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:lCVaexVBIwHo++NlIxccMW5b6QAJa+ZEr9ogAElUFyY root@3b9a273f18b5
The key's randomart image is:
+---[RSA 2048]----+
|++.E ++o=o*o*o   |
|o   +..=.B = o   |
|.    .* = * o    |
| .   =.o + *     |
|  . . o.S + .    |
|   . +.    .     |
|    . ... =      |
|        o= .     |
|       ...       |
+----[SHA256]-----+

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

cat ~/.ssh/id_rsa.pub

Добавьте этот ключ в свою учетную запись DigitalOcean, следуя these указания.

Далее установите Terraform:

sudo apt-get update
sudo apt-get install unzip
wget https://releases.hashicorp.com/terraform/0.11.7/terraform_0.11.7_linux_amd64.zip
unzip terraform_0.11.7_linux_amd64.zip
sudo mv terraform /usr/bin/.
terraform version

Вы увидите вывод, подтверждающий вашу установку Terraform:

OutputTerraform v

Затем выполните следующие команды, чтобы установить + kubectl +, инструмент CLI, который будет взаимодействовать с вашим кластером Kubernetes, и создать каталог + ~ / .kube + в домашнем каталоге вашего пользователя:

sudo apt-get install apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo touch /etc/apt/sources.list.d/kubernetes.list
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install kubectl
mkdir -p ~/.kube

Создание каталога + ~ / .kube + позволит вам скопировать файл конфигурации в это место. Это будет сделано после запуска сценария установки Kubernetes далее в этом разделе. По умолчанию CLI + kubectl + ищет файл конфигурации в каталоге + ~ / .kube + для доступа к кластеру.

Затем, клонируйте репозиторий примера проекта для этого учебника, который содержит скрипты Terraform для настройки инфраструктуры:

git clone https://github.com/do-community/k8s-cicd-webinars.git

Перейдите в каталог скриптов Terraform:

cd k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/

Получите отпечаток вашего открытого ключа SSH:

ssh-keygen -E md5 -lf ~/.ssh/id_rsa.pub | awk '{print $2}'

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

OutputMD5:

Имейте в виду, что ваш ключ будет отличаться от показанного здесь.

Сохраните отпечаток в переменной среды, чтобы Terraform мог использовать его:

export FINGERPRINT=

Затем экспортируйте свой токен личного доступа DO:

export TOKEN=

Теперь взгляните на каталог проекта + ~ / k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / +:

ls

Outputcluster.tf  destroy.sh  files outputs.tf  provider.tf  script.sh

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

Выполните скрипт + script.sh +, чтобы запустить настройку кластера Kubernetes:

./script.sh

Когда выполнение скрипта будет завершено, + kubectl + будет сконфигурирован для использования созданного вами кластера Kubernetes.

Перечислите узлы кластера, используя + kubectl get node +:

kubectl get nodes

OutputNAME                STATUS    ROLES     AGE       VERSION
k8s-master-node     Ready     master    2m        v1.10.0
k8s-worker-node-1   Ready     <none>    1m        v1.10.0
k8s-worker-node-2   Ready     <none>    57s       v1.10.0

Теперь у вас есть один главный и два рабочих узла в состоянии + Ready +.

С настроенным кластером Kubernetes вы можете теперь исследовать другой вариант создания изображений контейнера: Kaniko от Google.

Шаг 3 - Создание контейнерных изображений с Kaniko

Ранее в этом руководстве вы создавали образы контейнеров с помощью Dockerfiles и Buildah. Но что, если бы вы могли создавать изображения контейнеров непосредственно в Kubernetes? Есть способы запустить команду + docker image build внутри Kubernetes, но это не нативный инструмент Kubernetes. Для создания образов вам потребуется зависимость от демона Docker, и он должен будет работать на одном из Pods в кластере.

Инструмент под названием Kaniko позволяет создавать образы контейнеров с помощью Dockerfile в существующем кластере Kubernetes. На этом шаге вы создадите образ контейнера с помощью Dockerfile, используя Kaniko. Затем вы отправите это изображение в Docker Hub.

Чтобы отправить изображение в Docker Hub, вам необходимо передать учетные данные Docker Hub в Kaniko. На предыдущем шаге вы вошли в Docker Hub и создали файл + ~ / .docker / config.json со своими учетными данными для входа. Давайте использовать этот файл конфигурации для создания объекта ConfigMap Kubernetes для хранения учетных данных внутри кластера Kubernetes. Объект ConfigMap используется для хранения параметров конфигурации, отделяя их от вашего приложения.

Чтобы создать ConfigMap с именем + docker-config с помощью файла` + ~ / .docker / config.json`, выполните следующую команду:

sudo kubectl create configmap docker-config --from-file=$HOME/.docker/config.json

Затем вы можете создать файл определения Pod с именем + pod-kaniko.yml + в каталоге + ~ / k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / + (хотя он может идти куда угодно) ,

Сначала убедитесь, что вы находитесь в каталоге + ~ / k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / +:

cd ~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/

Создайте файл + pod-kaniko.yml +:

nano pod-kaniko.yml

Добавьте следующее содержимое в файл, чтобы указать, что произойдет при развертывании вашего модуля Pod. Обязательно замените ++ в поле Pod + args + на собственное имя пользователя Docker Hub:

~ / K8S-cicd-вебинары / webinar1 / 2-kubernetes / 1-Terraform / стручка-kaniko.yaml

apiVersion: v1
kind: Pod
metadata:
 name: kaniko
spec:
 containers:
 - name: kaniko
   image: gcr.io/kaniko-project/executor:latest
   args: ["--dockerfile=./Dockerfile",
           "--context=/tmp/rsvpapp/",
           "--destination=docker.io//rsvpapp:kaniko",
           "--force" ]
   volumeMounts:
     - name: docker-config
       mountPath: /root/.docker/
     - name: demo
       mountPath: /tmp/rsvpapp
 restartPolicy: Never
 initContainers:
   - image: python
     name: demo
     command: ["/bin/sh"]
     args: ["-c", "git clone https://github.com/do-community/rsvpapp-webinar1.git /tmp/rsvpapp"]
     volumeMounts:
     - name: demo
       mountPath: /tmp/rsvpapp
 restartPolicy: Never
 volumes:
   - name: docker-config
     configMap:
       name: docker-config
   - name: demo
     emptyDir: {}

Этот файл конфигурации описывает, что произойдет, когда ваш Pod развернут. Во-первых, Init container будет клонировать репозиторий Git с Dockerfile, + https: //github.com/do-community/ rsvpapp-webinar1.git + `, в общий том под названием + demo + . Контейнеры Init запускаются перед контейнерами приложений и могут использоваться для запуска утилит или других задач, которые нежелательно запускать из контейнеров приложений. Контейнер вашего приложения `+ kaniko + затем создаст образ с помощью Dockerfile и отправит полученное изображение в Docker Hub, используя учетные данные, которые вы передали в том ConfigMap + docker-config +.

Чтобы развернуть модуль + kaniko +, выполните следующую команду:

kubectl apply -f pod-kaniko.yml

Вы увидите следующее подтверждение:

Outputpod/kaniko created

Получить список стручков:

kubectl get pods

Вы увидите следующий список:

OutputNAME      READY     STATUS     RESTARTS   AGE
kaniko    0/1       Init:0/1   0          47s

Подождите несколько секунд, а затем снова запустите + kubectl get pods + для обновления статуса:

kubectl get pods

Вы увидите следующее:

OutputNAME      READY     STATUS    RESTARTS   AGE
kaniko    1/1       Running   0          1m

Наконец, еще раз запустите + kubectl get pods + для окончательного обновления статуса:

kubectl get pods

OutputNAME      READY     STATUS      RESTARTS   AGE
kaniko    0/1       Completed   0          2m

Эта последовательность вывода сообщает вам, что контейнер Init запущен, клонируя GitHub-репозиторий внутри тома + demo +. После этого процесс сборки Kaniko запустился и в итоге завершился.

Проверьте логи модуля:

kubectl logs kaniko

Вы увидите следующий вывод:

Outputtime="2018-08-02T05:01:24Z" level=info msg="appending to multi args docker.io//rsvpapp:kaniko"
time="2018-08-02T05:01:24Z" level=info msg="Downloading base image nkhare/python:alpine"
.
.
.
ime="2018-08-02T05:01:46Z" level=info msg="Taking snapshot of full filesystem..."
time="2018-08-02T05:01:48Z" level=info msg="cmd: CMD"
time="2018-08-02T05:01:48Z" level=info msg="Replacing CMD in config with [/bin/sh -c python rsvp.py]"
time="2018-08-02T05:01:48Z" level=info msg="Taking snapshot of full filesystem..."
time="2018-08-02T05:01:49Z" level=info msg="No files were changed, appending empty layer to config."
2018/08/02 05:01:51 mounted blob: sha256:bc4d09b6c77b25d6d3891095ef3b0f87fbe90621bff2a333f9b7f242299e0cfd
2018/08/02 05:01:51 mounted blob: sha256:809f49334738c14d17682456fd3629207124c4fad3c28f04618cc154d22e845b
2018/08/02 05:01:51 mounted blob: sha256:c0cb142e43453ebb1f82b905aa472e6e66017efd43872135bc5372e4fac04031
2018/08/02 05:01:51 mounted blob: sha256:606abda6711f8f4b91bbb139f8f0da67866c33378a6dcac958b2ddc54f0befd2
2018/08/02 05:01:52 pushed blob sha256:16d1686835faa5f81d67c0e87eb76eab316e1e9cd85167b292b9fa9434ad56bf
2018/08/02 05:01:53 pushed blob sha256:358d117a9400cee075514a286575d7d6ed86d118621e8b446cbb39cc5a07303b
2018/08/02 05:01:55 pushed blob sha256:5d171e492a9b691a49820bebfc25b29e53f5972ff7f14637975de9b385145e04
2018/08/02 05:01:56 index.docker.io//rsvpapp:kaniko: digest: sha256:831b214cdb7f8231e55afbba40914402b6c915ef4a0a2b6cbfe9efb223522988 size: 1243

Из журналов видно, что контейнер + kaniko + создает образ из Dockerfile и помещает его в свою учетную запись Docker Hub.

Теперь вы можете получить изображение Docker. Обязательно замените ++ на ваше имя пользователя Docker Hub:

docker pull /rsvpapp:kaniko

Вы увидите подтверждение тяги:

Outputkaniko: Pulling from /rsvpapp
c0cb142e4345: Pull complete
bc4d09b6c77b: Pull complete
606abda6711f: Pull complete
809f49334738: Pull complete
358d117a9400: Pull complete
5d171e492a9b: Pull complete
Digest: sha256:831b214cdb7f8231e55afbba40914402b6c915ef4a0a2b6cbfe9efb223522988
Status: Downloaded newer image for /rsvpapp:kaniko

Теперь вы успешно создали кластер Kubernetes и создали новые образы внутри кластера. Давайте перейдем к обсуждению Deployments и Services.

Шаг 4 - Создание развертываний и сервисов Kubernetes

Kubernetes Deployments позволит вам запускать ваши приложения. Развертывания задают желаемое состояние для ваших модулей, обеспечивая согласованность между вашими развертываниями. На этом шаге вы создадите файл развертывания Nginx с именем + deploy.yml + в `+ ~ / k8s-cicd-webinars / webinar1 / 2-kubernetes / 1- Terraform / + `каталог для создания Nginx Deployment.

Сначала откройте файл:

nano deployment.yml

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

~ / K8S-cicd-вебинары / webinar1 / 2-kubernetes / 1-Terraform / deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.7.9
       ports:
       - containerPort: 80

Этот файл определяет Deployment с именем + nginx-deploy +, который создает три модуля, каждый из которых выполняет контейнер + nginx + на порту + 80 +.

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

kubectl apply -f deployment.yml

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

Outputdeployment.apps/nginx-deployment created

Перечислите свои Развертывания:

kubectl get deployments

OutputNAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           29s

Вы можете видеть, что + nginx-deploy + Deployment было создано, и желаемое и текущее количество модулей было одинаковым: + 3 +.

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

kubectl get pods

OutputNAME                                READY     STATUS      RESTARTS   AGE
kaniko                              0/1       Completed   0          9m
nginx-deployment-75675f5897-nhwsp   1/1       Running     0          1m
nginx-deployment-75675f5897-pxpl9   1/1       Running     0          1m
nginx-deployment-75675f5897-xvf4f   1/1       Running     0          1m

Из этого вывода видно, что работает нужное количество модулей.

Чтобы раскрыть развертывание приложения внутри и снаружи, вам необходимо создать объект Kubernetes с именем Service. Каждый Сервис указывает ServiceType, который определяет, как сервис предоставляется. В этом примере мы будем использовать NodePort ServiceType, который предоставляет Сервис на статическом порту на каждом узле.

Для этого создайте файл + service.yml + в каталоге + ~ / k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom / +:

nano service.yml

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

~ / K8S-cicd-вебинары / webinar1 / 2-kubernetes / 1-Terrafrom / service.yml

kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 type: NodePort
 ports:
 - protocol: TCP
   port: 80
   targetPort: 80
   nodePort: 30111

Эти настройки определяют службу + nginx-service + и указывают, что она будет нацелена на порт + 80 + на вашем модуле Pod. + nodePort + определяет порт, куда приложение будет принимать внешний трафик.

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

kubectl apply -f service.yml

Вы увидите подтверждение:

Outputservice/nginx-service created

Список услуг:

kubectl get service

Вы увидите следующий список:

OutputNAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        5h
nginx-service   NodePort    10.100.98.213   <none>        80:/TCP   7s

Ваш сервис + nginx-service доступен через порт` + 30111 + , и теперь вы можете получить к нему доступ с любого из общедоступных IP-адресов узла. Например, переход к `+ http: //: 30111 + или + http: //: 30111 + должен привести вас к стандартной странице приветствия Nginx.

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

kubectl delete deployment nginx-deployment
kubectl delete service nginx-service

Эти команды удаляют созданное вами развертывание и службу.

Теперь, когда вы работали с Deployments and Services, давайте перейдем к созданию пользовательских ресурсов.

Шаг 5 - Создание пользовательских ресурсов в Kubernetes

Kubernetes предлагает ограниченные, но готовые к работе функциональные возможности и функции. Однако можно расширить предложения Kubernetes, используя функцию Custom Resources. В Kubernetes resource является конечной точкой в API Kubernetes, которая хранит коллекцию API objects. Например, ресурс Pod содержит коллекцию объектов Pod. Пользовательские ресурсы позволяют добавлять пользовательские предложения для сетей, хранилищ и многого другого. Эти дополнения могут быть созданы или удалены в любой момент.

Помимо создания пользовательских объектов, вы также можете использовать субконтроллеры компонента Controller Kubernetes в плоскости управления, чтобы убедиться, что текущее состояние ваших объектов равно желаемому состоянию. Контроллер Kubernetes имеет субконтроллеры для указанных объектов. Например, ReplicaSet является субконтроллером, который гарантирует, что желаемое количество Pod остается постоянным. Когда вы комбинируете пользовательский ресурс с контроллером, вы получаете действительно декларативный API, который позволяет вам указать желаемое состояние ваших ресурсов.

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

Чтобы создать пользовательский ресурс, сначала создайте файл с именем + crd.yml + в каталоге + ~ / k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom / +:

nano crd.yml

Добавьте следующее пользовательское определение ресурса (CRD):

~ / K8S-cicd-вебинары / webinar1 / 2-kubernetes / 1-Terrafrom / crd.yml

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
 name: webinars.digitalocean.com
spec:
 group: digitalocean.com
 version: v1
 scope: Namespaced
 names:
   plural: webinars
   singular: webinar
   kind: Webinar
   shortNames:
   - wb

Чтобы развернуть CRD, определенный в + crd.yml +, выполните следующую команду:

kubectl create -f crd.yml

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

Outputcustomresourcedefinition.apiextensions.k8s.io/webinars.digitalocean.com created

Файл + crd.yml + создал новый путь к ресурсу RESTful: + / apis / digtialocean.com / v1 / namespaces / * / webinars +. Теперь вы можете ссылаться на свои объекты, используя + webinars +, + webinar +, + Webinar + и + wb +, поскольку вы перечислили их в разделе + names + в + CustomResourceDefinition +. Вы можете проверить ресурс RESTful с помощью следующей команды:

kubectl proxy & curl 127.0.0.1:8001/apis/digitalocean.com

Вы увидите следующий вывод:

OutputHTTP/1.1 200 OK
Content-Length: 238
Content-Type: application/json
Date: Fri, 03 Aug 2018 06:10:12 GMT

{
   "apiVersion": "v1",
   "kind": "APIGroup",
   "name": "digitalocean.com",
   "preferredVersion": {
       "groupVersion": "digitalocean.com/v1",
       "version": "v1"
   },
   "serverAddressByClientCIDRs": null,
   "versions": [
       {
           "groupVersion": "digitalocean.com/v1",
           "version": "v1"
       }
   ]
}

Затем создайте объект для использования новых пользовательских ресурсов, открыв файл с именем + webinar.yml +:

nano webinar.yml

Добавьте следующий контент для создания объекта:

~ / K8S-cicd-вебинары / webinar1 / 2-kubernetes / 1-Terrafrom / webinar.yml

apiVersion: "digitalocean.com/v1"
kind: Webinar
metadata:
 name: webinar1
spec:
 name: webinar
 image: nginx

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

kubectl apply -f webinar.yml

Вы увидите следующий вывод:

Outputwebinar.digitalocean.com/webinar1 created

Теперь вы можете управлять объектами + webinar +, используя + kubectl +. Например:

kubectl get webinar

OutputNAME       CREATED AT
webinar1   21s

Теперь у вас есть объект с именем + webinar1 +. Если бы существовал Контроллер, он бы перехватил создание объекта и выполнил любые определенные операции.

Удаление пользовательского определения ресурса

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

kubectl delete webinar --all

Ты увидишь:

Outputwebinar.digitalocean.com "webinar1" deleted

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

kubectl delete crd webinars.digitalocean.com

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

Outputcustomresourcedefinition.apiextensions.k8s.io "webinars.digitalocean.com" deleted

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

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

Шаг 6 - Удаление кластера Kubernetes

Чтобы уничтожить сам кластер Kubernetes, вы можете использовать скрипт + destroy.sh + из папки + ~ / k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom +. Убедитесь, что вы находитесь в этом каталоге:

cd ~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom

Запустите скрипт:

./destroy.sh

Запустив этот скрипт, вы позволите Terraform взаимодействовать с API DigitalOcean и удалять серверы в вашем кластере.

Заключение

В этом уроке вы использовали различные инструменты для создания изображений контейнеров. С помощью этих изображений вы можете создавать контейнеры в любой среде. Вы также настроили кластер Kubernetes, используя Terraform, и создали объекты Deployment и Service для развертывания и предоставления своего приложения. Кроме того, вы расширили функциональность Kubernetes, определив пользовательский ресурс.

Теперь у вас есть надежная основа для создания среды CI / CD на Kubernetes, которую мы рассмотрим в следующих статьях.

TOC

Серия вебинаров: Строительные блоки для выполнения CI / CD с Kubernetes

Вступление

Предпосылки

Шаг 1 - Создание изображений контейнеров с помощью Docker и Buildah

Создание контейнерных изображений с помощью Dockerfiles

Создание изображений контейнеров с помощью Project Atomic-Buildah

Шаг 2 - Настройка кластера Kubernetes в DigitalOcean с использованием kubeadm и Terraform

Шаг 3 - Создание контейнерных изображений с Kaniko

Шаг 4 - Создание развертываний и сервисов Kubernetes

Шаг 5 - Создание пользовательских ресурсов в Kubernetes

Удаление пользовательского определения ресурса

Шаг 6 - Удаление кластера Kubernetes

Заключение

Related