ArgoCD — это декларативный инструмент непрерывной доставки GitOps для Kubernetes. Т.е дает возможность выполнять деплой приложений в K8S и хранить все конфиги в гите.

Установка ArgoCD в Unix/Linux

Для начало что необходимо, так установить Кубернетес, у меня есть ряд статей на эту тему:

Установка Kubernetes кластера в Unix/Linux

Установка Kubernetes в Unix/Linux

Команды Kubernetes в Unix/Linux

Создание AWS EKS кластера в Unix/Linux

Установка minikube в Unix/Linux

После чего, создаем неймспейс:

$ kubectl create namespace argocd

Установка ArgoCD через KubeCTL

Первое что необходимо, так — это поставить данную утилиту под названием kubectl!

Выполняем деплой:

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Можно выполнить установку еще так (Non-HA):

$ export VESION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')
$ export ARGO_VERSION="v1.8.0-rc1"
$ kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo/${ARGO_VERSION}/manifests/install.yaml

Можно выполнить установку еще так (HA):

$ export ARGO_VERSION="v1.8.0-rc1"
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/${ARGO_VERSION}/manifests/ha/install.yaml

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

Первое что необходимо, так — это поставить данную утилиту под названием helm!

И выполняем deploy:

$ helm repo add argo https://argoproj.github.io/argo-helm

$ helm install argocd \
	-n argocd \
	--set global.image.repository="argoproj/argocd" \
	--set global.image.tag="v1.8.1" \
	--set server.service.type="LoadBalancer" \
	argo/argo-cd

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

helm install argocd \
	-n argocd \
	--set global.image.repository="argoproj/argocd" \
	--set global.image.tag="v1.8.1" \
	argo/argo-cd

Проверим что все подымается так:

$ kubectl get po -n argocd && \
kubectl get service -n argocd

Можем идти дальше.

Кстати, пароль будет таким:

$ export OLD_ARGOCD_PWD=$(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2)

Если что, его можно поменять.

Установка ArgoCD через Terraform

Я недавно писал модуль для работы с helm, и на примере ArgoCD выполнил деплой. Код выглядит так:

#
# MAINTAINER Vitaliy Natarov "vitaliy.natarov@yahoo.com"
#
terraform {
  required_version = "~> 0.13"
}

module "helm_release" {
  source = "../../modules/release"

  enable_release     = true
  release_name       = "argocd-dev"
  release_chart      = "argo-cd"
  release_repository = "https://argoproj.github.io/argo-helm"
  release_version    = "v1.7.6"

  release_namespace        = "argocd-dev"
  release_create_namespace = true
  release_values           = []

  release_set = [
    {
      name  = "server.service.type"
      value = "LoadBalancer"
    }
  ]
  release_set_sensitive = []
  release_postrender    = []

  release_timeout       = 600
  release_force_update  = false
  release_recreate_pods = true
  release_lint          = false

}

Код с моими модулями можно найти тут — https://github.com/SebastianUA/terraform/blob/master/helm/examples/release/main.tf

Попозже дополню данную статью этим материалом.

Настройка ArgoCD в Unix/Linux

Поле того, как у вас задеплоится ArgoCD, вы не можете знать пароль от стандартного пользователя (admin), но его можно посмотреть тут:

$ kubectl get secret -n argocd argocd-secret -o yaml

Или, так:

$ kubectl get secret -n argocd argocd-secret -o yaml | grep -Ei "  admin.password: "

Т.к кубернетес пишет все секреты в base64, то декодировать строку можно так:

$ kubectl get secret -n argocd argocd-secret -o yaml | grep -Ei "  admin.password: " | awk '{print $2}' | base64 --decode

Пока не понял как расшифровать пароль с BCrypt. По этому, пойду по простому пути, а именно — перепишу пароль на нужный, например, вы хотите поставить пароль «admin» — т.е как и логин. Дано:

• Plain Text: admin
• BCrypt Hash:

$2b$10$ixLkbNDoNmoo3sHorEFequhJeEsZBtFVGlYjEhKZqBv2dlgTmbt.G

И выполняем патч:

$ kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "admin.password": "$2b$10$ixLkbNDoNmoo3sHorEFequhJeEsZBtFVGlYjEhKZqBv2dlgTmbt.G",
    "admin.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

Можно использовать login & password — admin.

Можно, просто выключить авторизацию так:

$ kubectl patch deploy argocd-server -n argocd -p '[{"op": "add", "path": "/spec/template/spec/containers/0/command/-", "value": "--disable-auth"}]' --type json

Добавление пользователей в ArgoCD

Посмотреть конфиг с юзерами и паролями, можно так:

$ kubectl get secret -n argocd argocd-secret -o yaml

Первое что нужно — это отредактировать:

$ kubectl edit -n argocd configmap/argocd-cm

И приводим к виду:

data:
  accounts.vnatarov: apiKey, login
  accounts.vnatarov.enabled: "true"
  accounts.test: apiKey, login
  accounts.test.enabled: "true"

Где:

• vnatarov & test — это имена юзеров.
• apiKey — Позволяет генерировать токены.
• login — Позволяет выполнять вход в UI админку ArgoCD.
• enabled: «true» — Говорит системе то, что юзер будет включен.

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

Патчим пароли:

$ kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "vnatarov.password": "$2b$10$ySVNtxkJVrSmh2GQA2zTLOzNedw1QPtDMYXp0X21WYSFwqvVUdWfm",
    "vnatarov.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "test.password": "$2b$10$O1Jc1FgWcDN.PC0mA6xdPOT4OmUQXHupcO9/0k6r6MHYLhuH7ALP6",
    "test.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

Или, можно отредактировать (но тогда нужно будет зашифровать фразу в base64):

$ kubectl edit secret -n argocd argocd-secret

Чет какие-то баги в аргоСД и я смог пофиксить способом что описал выше, по этому, выполнил вход в админку:

$ yes | argocd login 127.0.0.1:8080 --username admin --password admin

Можно поглядеть учетки:

$ argocd account list
NAME      ENABLED  CAPABILITIES
admin     true     login
test      true     login, apiKey
vnatarov  true     apiKey, login

Ну и обновляем пароль:

$ argocd account update-password --account test --new-password 'test'

Точно так же для моего другого юзера:

$ argocd account update-password --account vnatarov --new-password 'vnatarov'
*** Enter current password:
Password updated

Приведу полный вывод моего конфига configmap-ы argocd-cm:

$ kubectl get -n argocd configmap/argocd-cm -o yaml

apiVersion: v1
data:
  accounts.test: login,apiKey
  accounts.test.enabled: "true"
  accounts.vnatarov: apiKey,login
  accounts.vnatarov.enabled: "true"
  application.instanceLabelKey: argocd.argoproj.io/instance
  statusbadge.enabled: "true"
  url: https://127.0.0.1:8080
  users.anonymous.enabled: "true"
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: argocd
    meta.helm.sh/release-namespace: argocd
  creationTimestamp: "2021-01-05T18:18:34Z"
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: argocd
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
    helm.sh/chart: argo-cd-2.11.0
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:application.instanceLabelKey: {}
      f:metadata:
        f:annotations:
          .: {}
          f:meta.helm.sh/release-name: {}
          f:meta.helm.sh/release-namespace: {}
        f:labels:
          .: {}
          f:app.kubernetes.io/component: {}
          f:app.kubernetes.io/instance: {}
          f:app.kubernetes.io/managed-by: {}
          f:app.kubernetes.io/name: {}
          f:app.kubernetes.io/part-of: {}
          f:helm.sh/chart: {}
    manager: Go-http-client
    operation: Update
    time: "2021-01-05T18:18:34Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:accounts.test.enabled: {}
        f:accounts.vnatarov.enabled: {}
        f:statusbadge.enabled: {}
        f:url: {}
        f:users.anonymous.enabled: {}
    manager: kubectl-edit
    operation: Update
    time: "2021-01-05T21:18:04Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:accounts.test: {}
        f:accounts.vnatarov: {}
    manager: argocd-server
    operation: Update
    time: "2021-01-05T21:32:26Z"
  name: argocd-cm
  namespace: argocd
  resourceVersion: "122982"
  selfLink: /api/v1/namespaces/argocd/configmaps/argocd-cm
  uid: adc7f9e5-1318-44c7-a59e-ba1625a8f887

Приведу полный вывод моего конфига secret-а argocd-secret:

$ kubectl get secret -n argocd argocd-secret -o yaml

apiVersion: v1
data:
  accounts.test.password: JDJhJDEwJEhyUW0uQlo2alFTRWxvT1J3N3BKMnVXOGVGLnVRUGc4cC5LQ2JSTGJqUzRtYWtWVDRZZ1dl
  accounts.test.passwordMtime: MjAyMS0wMS0wNVQyMToyNzo0NFo=
  accounts.test.tokens: bnVsbA==
  accounts.vnatarov.password: JDJhJDEwJGExRElNNnk5SFhqM1h3ZmZjMkFNa094eGdROUYzTTg0OUQ2M1BoOFhnZXB3VkNrc2ZoZnYy
  accounts.vnatarov.passwordMtime: MjAyMS0wMS0wNVQyMTozMjoyNlo=
  accounts.vnatarov.tokens: bnVsbA==
  admin.password: JDJiJDEwJGl4TGtiTkRvTm1vbzNzSG9yRUZlcXVoSmVFc1pCdEZWR2xZakVoS1pxQnYyZGxnVG1idC5H
  admin.passwordMtime: MjAyMS0wMS0wNVQyMDoyMTowNFo=
  server.secretkey: MDZ5QVA3WVZ4cTQ0ZDFDdXZzaEZqZjcydDZmUmVmdjQ0UXFsenhUWDZEcz0=
  test.password: JDJiJDEwJE8xSmMxRmdXY0ROLlBDMG1BNnhkUE9UNE9tVVFYSHVwY085LzBrNnI2TUhZTGh1SDdBTFA2
  test.passwordMtime: MjAyMS0wMS0wNVQyMjo0NTozNEVFVA==
  tls.crt: YYYYY=
  tls.key: XXXXXXX==
  vnatarov.password: JDJiJDEwJHlTVk50eGtKVnJTbWgyR1FBMnpUTE96TmVkdzFRUHRETVlYcDBYMjFXWVNGd3F2VlVkV2Zt
  vnatarov.passwordMtime: MjAyMS0wMS0wNVQyMjoyNjo0N0VFVA==
kind: Secret
metadata:
  annotations:
    meta.helm.sh/release-name: argocd
    meta.helm.sh/release-namespace: argocd
  creationTimestamp: "2021-01-05T18:18:34Z"
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: argocd
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: argocd-secret
    app.kubernetes.io/part-of: argocd
    helm.sh/chart: argo-cd-2.11.0
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:meta.helm.sh/release-name: {}
          f:meta.helm.sh/release-namespace: {}
        f:labels:
          .: {}
          f:app.kubernetes.io/component: {}
          f:app.kubernetes.io/instance: {}
          f:app.kubernetes.io/managed-by: {}
          f:app.kubernetes.io/name: {}
          f:app.kubernetes.io/part-of: {}
          f:helm.sh/chart: {}
      f:type: {}
    manager: Go-http-client
    operation: Update
    time: "2021-01-05T18:18:34Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:admin.password: {}
        f:test.password: {}
        f:test.passwordMtime: {}
        f:vnatarov.password: {}
        f:vnatarov.passwordMtime: {}
    manager: kubectl-patch
    operation: Update
    time: "2021-01-05T20:45:35Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:accounts.test.password: {}
        f:accounts.test.passwordMtime: {}
        f:accounts.test.tokens: {}
        f:accounts.vnatarov.password: {}
        f:accounts.vnatarov.passwordMtime: {}
        f:accounts.vnatarov.tokens: {}
        f:admin.passwordMtime: {}
        f:server.secretkey: {}
        f:tls.crt: {}
        f:tls.key: {}
    manager: argocd-server
    operation: Update
    time: "2021-01-05T21:32:26Z"
  name: argocd-secret
  namespace: argocd
  resourceVersion: "122983"
  selfLink: /api/v1/namespaces/argocd/secrets/argocd-secret
  uid: 17e9ff5c-946d-4655-bd05-c983091ef210
type: Opaque

Приведу полный вывод моего конфига secret-а argocd-secret:

$ kubectl get -n argocd configmap/argocd-rbac-cm -o yaml

apiVersion: v1
data:
  policy.csv: |
    # Built-in policy which defines two roles: role:readonly and role:admin,
    # and additionally assigns the admin user to the role:admin role.
    # There are two policy formats:
    # 1. Applications (which belong to a project):
    # p, <user/group>, <resource>, <action>, <project>/<object>
    # 2. All other resources:
    # p, <user/group>, <resource>, <action>, <object>

    p, role:readonly, applications, get, */*, allow
    p, role:readonly, certificates, get, *, allow
    p, role:readonly, clusters, get, *, allow
    p, role:readonly, repositories, get, *, allow
    p, role:readonly, projects, get, *, allow
    p, role:readonly, accounts, get, *, allow
    p, role:readonly, gpgkeys, get, *, allow

    p, role:admin, applications, create, */*, allow
    p, role:admin, applications, update, */*, allow
    p, role:admin, applications, delete, */*, allow
    p, role:admin, applications, sync, */*, allow
    p, role:admin, applications, override, */*, allow
    p, role:admin, applications, action/*, */*, allow
    p, role:admin, certificates, create, *, allow
    p, role:admin, certificates, update, *, allow
    p, role:admin, certificates, delete, *, allow
    p, role:admin, clusters, create, *, allow
    p, role:admin, clusters, update, *, allow
    p, role:admin, clusters, delete, *, allow
    p, role:admin, repositories, create, *, allow
    p, role:admin, repositories, update, *, allow
    p, role:admin, repositories, delete, *, allow
    p, role:admin, projects, create, *, allow
    p, role:admin, projects, update, *, allow
    p, role:admin, projects, delete, *, allow
    p, role:admin, accounts, update, *, allow
    p, role:admin, gpgkeys, create, *, allow
    p, role:admin, gpgkeys, delete, *, allow

    g, role:admin, role:readonly
    g, admin, role:admin
    g, vnatarov, role:admin
  policy.default: role:readonly
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: argocd
    meta.helm.sh/release-namespace: argocd
  creationTimestamp: "2021-01-05T18:18:34Z"
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: argocd
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: argocd-rbac-cm
    app.kubernetes.io/part-of: argocd
    helm.sh/chart: argo-cd-2.11.0
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:meta.helm.sh/release-name: {}
          f:meta.helm.sh/release-namespace: {}
        f:labels:
          .: {}
          f:app.kubernetes.io/component: {}
          f:app.kubernetes.io/instance: {}
          f:app.kubernetes.io/managed-by: {}
          f:app.kubernetes.io/name: {}
          f:app.kubernetes.io/part-of: {}
          f:helm.sh/chart: {}
    manager: Go-http-client
    operation: Update
    time: "2021-01-05T18:18:34Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:policy.csv: {}
        f:policy.default: {}
    manager: kubectl-edit
    operation: Update
    time: "2021-01-05T20:34:00Z"
  name: argocd-rbac-cm
  namespace: argocd
  resourceVersion: "116734"
  selfLink: /api/v1/namespaces/argocd/configmaps/argocd-rbac-cm
  uid: aa1649df-d477-4258-bb3a-f7219326ad84

Можно юзать!

Убрать HTTPS в ArgoCD

Патчим:

$ kubectl patch deploy argocd-server -n argocd -p '[{"op": "add", "path": "/spec/template/spec/containers/0/command/-", "value": "--insecure"}]' --type json

И потом все норм.

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

Команда простая (на примере дефолтного админа):

$ kubectl -n argocd create rolebinding default-admin --clusterrole=admin --serviceaccount=argo:default

Дальше — больше.

Создание ArtifactRepository для ArgoCD

Создаем это так:

$ cat <<EoF > argo-patch.yaml
data:
  config: |
    artifactRepository:
      s3:
        endpoint: s3.amazonaws.com
        bucket: batch-artifact-repository
EoF

Где:

• batch-artifact-repository — это созданный бакет.

И применяем:

$ kubectl -n argocd patch \
  configmap/argocd-cm \
  --patch "$(cat argo-patch.yaml)"

Вот так вот.

Установка оператора (Argo CD Operator) для ArgoCD (Helm)

Установка очень простая:

$ kubectl apply -f https://operatorhub.io/install/argocd-operator-helm.yaml

После чего, проверяем:

$ kubectl get csv -n my-argocd-operator-helm

Или, еще проще способ:

$ curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.17.0/install.sh | bash -s v0.17.0

После чего, проверяем:

$ kubectl get csv -n olm

Вот и все.

Использование ArgoCD в Unix/Linux

Пропишу команду для дальнейшего использования:

$ export ARGOCD_SERVER=$(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2)

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

$ kubectl port-forward service/argocd-server -n argocd 8080:443

И после данного действия, у вас будет работать argoCD на 127.0.0.1:8080

Т.к я использую макбук, то следующая команда установит argocd CLI на мой мак:

$ brew install argocd

Далее, выполним логин:

$ argocd login localhost:8080 --insecure --username admin --grpc-web

NOTE: Нужно знать пароль!

Далее, ставим 1-е приложение:

$ argocd app create guestbook \
--repo https://github.com/pcrete/argocd-example-apps.git \
--path guestbook \
--dest-server https://kubernetes.default.svc \
--dest-namespace guestbook

И далее, ставим 2-е приложение:

$ argocd app create webapp \
--repo https://gitlab.com/gitops-argocd-demo/webapp-chart.git \
--path . \
--dest-server https://kubernetes.default.svc \
--dest-namespace hello-gitops \
--sync-policy automated \
--auto-prune \
--self-heal

Можно открыть в браузере аргоСД и поглядеть что оно будет делать.

Вот и все, статья «Установка ArgoCD в Unix/Linux» завершена.

Если честно, VMware мне больше нравится чем VirtualBox, но лицензию я не хочу покупать для домашнего использования. По этому, выбор пал на то, чтобы перейти с VMware Fusion на VirtualBox. Для этого дела, мне пришлось зарегистрироваться на официальном сайте, заполнить данные. Но сразу я скачать не смог, возникли трудности с ПО и мне нужно было обратиться в поддержку. Поддержка решала данный вопрос около недели, но все решилось и я смог загрузить DMG на свой мак.

Конвертация VMware virtual machine -> VirtualBox на MacOS

Для начала, заходим на официальный сайт и качаем утилиту под названием «ovftool».

Установить DMG на МасОС через CLI можно так:

Установка dmg пакетов через CLI (командную строку) в MacOS X

Монтирование dmg образов через CLI (командную строку) в MacOS X

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

/Applications/VMware\ OVF\ Tool/ovftool

Чтобы получить помощь, выполните:

$ /Applications/VMware\ OVF\ Tool/ovftool -h
Usage: ovftool [options] <source> [<target>]
where
<source>: Source URL locator to an OVF package, VMX file, or virtual machine in
          vCenter or on ESX Server.
<target>: Target URL locator which specifies either a file location, or a
          location in the vCenter inventory or on an ESX Server.

If <target> is not specified, information about the source is displayed to the
console.

Options:
     --acceptAllEulas            : Accept all end-user licenses agreements
                                   without being prompted.
     --allowAllExtraConfig       : Whether we allow all the ExtraConfig
                                   options. These options are a security risk
                                   as they control low-level and potential
                                   unsafe options on the VM.
     --allowExtraConfig          : Whether we allow ExtraConfig options. These
                                   options are a security risk as they control
                                   low-level and potential unsafe options on
                                   the VM.
     --annotation                : Add annotation to vi, vmx, vapprun, vCloud,
                                   OVF, and OVA source locators
     --authdPortSource           : Use this to override default vmware authd
                                   port (902) when using a host as source.
     --authdPortTarget           : Use this to override default vmware authd
                                   port (902) when using a host as target.
     --chunkSize                 : Specifies the chunk size to use for files in
                                   a generated OVF package. The default is not
                                   to chunk. The chunk size without unit is
                                   assumed to be in megabytes. Accepted units
                                   are b, kb, mb, gb; e.g., 2gb or 100kb.
     --compress                  : Compress the disks in an OVF package. Value
                                   must be between 1 and 9. 1 is the fastest,
                                   but gives the worst compression, whereas 9
                                   is the slowest, but gives the best
                                   compression.
     --computerName              : Sets the computer name in the guest for a VM
                                   using the syntax --computerName:<VM
                                   ID>=<value>. Only applies to vCloud targets
                                   version 5.5 or newer.
     --coresPerSocket            : Specifies the distribution of the total
                                   number of CPUs over a number of virtual
                                   sockets using the syntax
                                   --coresPerSocket:<VM ID>=<value>. Only
                                   applies to vCloud targets version 5.5 or
                                   newer.
 -ds/--datastore                 : Target datastore name for a VI locator.
     --decodeBase64              : Decode option values with Base64.
     --defaultStorageProfile     : The storage profile for all VMs in the OVF
                                   package. The value should be an SPBM profile
                                   ID. Only applies to VI targets version 5.5
                                   or newer.
     --defaultStorageRawProfile  : The storage profile for all VMs in the OVF
                                   package. The value should be raw SPBM
                                   profile. The value will overwrite that in
                                   --defaultStorageProfile. Only applies to VI
                                   targets version 5.5 or newer.
     --deploymentOption          : Selects what deployment option to use (if
                                   the source OVF package supports multiple
                                   options.)
     --disableVerification       : Skip validation of signature and
                                   certificate.
 -dm/--diskMode                  : Select target disk format. Supported formats
                                   are: monolithicSparse, monolithicFlat,
                                   twoGbMaxExtentSparse, twoGbMaxExtentFlat,
                                   seSparse (VI target), eagerZeroedThick (VI
                                   target), thin (VI target), thick (VI
                                   target), sparse, and flat
     --diskSize                  : Sets the size of a VM disk in megabytes
                                   using the syntax --diskSize:<VM ID>,<disk
                                   instance ID>=<value>. Only applies to vCloud
                                   targets version 5.5 or newer.
     --eula                      : EULA to be inserted in the first virtual
                                   system or virtual system collection in the
                                   OVF. If the EULA is in a file, use the
                                   option --eula@=filename instead.
     --exportDeviceSubtypes      : Enables export of resource subtype for
                                   CD/Floppy/Parallel/Serial devices. This can
                                   limit portability as not all device backings
                                   are supported on all hypervisors. The
                                   default is false.
     --exportFlags               : Specifies one or more export flags to
                                   control what gets exported. The supported
                                   values for VI sources are mac, uuid, and
                                   extraconfig. Supported value for vCloud
                                   sources are preserveIdentity. One or more
                                   options can be provided, separated by
                                   commas.
     --extraConfig               : Sets an ExtraConfig element for all
                                   VirtualHardwareSections. The syntax is
                                   --extraConfig:<key>=<value>. Applies to vi,
                                   vmx, vapprun, vCloud, ovf, and ova source
                                   locators.
     --fencedMode                : If a parent network exists on the vCloud
                                   target, this property specifies the
                                   connectivity to the parent. Possible values
                                   are bridged, isolated, and natRouted.
 -h /--help                      : Prints this message.
     --hideEula                  : In OVF probe mode, hides the EULA.
     --ipAllocationPolicy        : IP allocation policy for a deployed OVF
                                   package.Supported values are: dhcpPolicy,
                                   transientPolicy, fixedPolicy,
                                   fixedAllocatedPolicy.
     --ipProtocol                : Select what IP protocol to use (IPv4, IPv6).
     --lax                       : Relax OVF specification conformance and
                                   virtual hardware compliance checks. Use only
                                   if you know what you are doing.
     --locale                    : Selects locale for target.
     --machineOutput             : Output OVF Tool messages in a machine
                                   friendly manner.
     --makeDeltaDisks            : Build delta disk hierarchy from the given
                                   source locator.
     --maxVirtualHardwareVersion : The maximal virtual hardware version to
                                   generate.
     --memorySize                : Sets the memory size in megabytes of a VM
                                   using the syntax --memorySize:<VM
                                   ID>=<value>. Only applies to vCloud targets
                                   version 5.5 or newer.
 -n /--name                      : Specifies target name (defaults to source
                                   name).
     --net                       : Set a network assignment in the deployed OVF
                                   package. A network assignment is set using
                                   the syntax --net:<OVF name>=<target name>.
                                   If the target is vCloud 5.5 or newer, a
                                   fence mode can also be specified using the
                                   syntax --net:<OVF name>=<target name>,<fence
                                   mode>. Possible fence mode values are:
                                   bridged, isolated, and natRouted.
 -nw/--network                   : Target network for a VI deployment.
     --nic                       : Specifies NIC configuration in a VM using
                                   the syntax --nic:<VM ID>,<index>=<OVF net
                                   name>,<isPrimary>,<ipAddressingMode>,<ipAddress>.
                                   Possible values for ipAddressingMode are:
                                   DHCP, POOL, MANUAL, and NONE. ipAddress is
                                   optional and should only be used when
                                   ipAddressingMode is set to MANUAL. Only
                                   applies to vCloud targets version 5.5 or
                                   newer.
     --noDisks                   : Disable disk conversion.
     --noImageFiles              : Do not include image files in destination.
     --noSSLVerify               : Skip SSL verification for VI connections.
     --numberOfCpus              : Sets the number of CPUs for a VM using the
                                   syntax --numberOfCpus:<VM ID>=<value>. Only
                                   applies to vCloud targets version 5.5 or
                                   newer.
 -o /--overwrite                 : Force overwrites of existing files.
     --powerOffSource            : Ensures a VM/vApp is powered off before
                                   importing from a VI source.
     --powerOffTarget            : Ensures a VM/vApp is powered off before
                                   overwriting a VI target.
     --powerOn                   : Powers on a VM/vApp deployed on a VI target.
     --privateKey                : Sign OVF package with the given private key
                                   (.pem file). The file must contain a private
                                   key and a certificate.
     --privateKeyPassword        : Password for the private key. Should be used
                                   in conjunction with privateKey if the
                                   private key requires password
                                   authentication. If required and not
                                   specified, the tool will prompt for the
                                   password.
     --prop                      : Set a property in the deployed OVF package.
                                   A property is set using the syntax
                                   --prop:<key>=<value>.
     --proxy                     : Proxy used for HTTP[S] access.
     --proxyNTLMAuth             : Enable NTLM authentication for proxy.
 -q /--quiet                     : No output to screen except errors.
     --schemaValidate            : Validate OVF descriptor against OVF schema.
     --shaAlgorithm              : Select SHA digest algorithm when creating
                                   OVF package. Supported values are SHA1,
                                   SHA256 and SHA512. Default value is SHA256.
     --skipManifestCheck         : Skip validation of OVF package manifest.
     --skipManifestGeneration    : Skip generation of OVF package manifest.
     --sourcePEM                 : File path to PEM formatted file used to
                                   verify VI connections.
     --sourceSSLThumbprint       : SSL fingerprint of SOURCE. OVF Tool verifies
                                   the SSL fingerprint it gets from SOURCE if
                                   the value is set.
 -st/--sourceType                : Explicitly express that source is OVF, OVA,
                                   VMX, VI, vCloud, ISO, FLP, vApprun
     --sslCipherList             : Use this to override default OpenSSL ciphers
                                   suite.
     --sslVersion                : Use this to set preferred TLS/SSL version
                                   for HTTPS connections. The valid values are
                                   as following:
                                     TLSv1_0: Set preferred TLS/SSL version to
                                   TLSv1.0.
                                     TLSv1_1: Set preferred TLS/SSL version to
                                   TLSv1.1.
                                     TLSv1_2: Set preferred TLS/SSL version to
                                   TLSv1.2.
     --storageProfile            : Sets the storage profile for a VM using the
                                   syntax --storageProfile:<VM ID>=<value>.
                                   Only applies to vCloud targets version 5.5
                                   or newer.
     --targetPEM                 : File path to PEM formatted file used to
                                   verify VI connections.
     --targetSSLThumbprint       : SSL fingerprint of TARGET. OVF Tool verifies
                                   the SSL fingerprint it gets from TARGET if
                                   the value is set.
 -tt/--targetType                : Explicitly express that target is OVF, OVA,
                                   VMX, VI, vCloud, ISO, FLP, vApprun
     --vCloudTemplate            : Create only a vApp template. Default value
                                   is false
     --vService                  : Set a vService assignment in the deployed
                                   OVF package. A vService assignment is set
                                   using the syntax
                                   --vService:<dependencyId>=<providerId>.
     --verifyOnly                : Do not upload the source but only verify it
                                   against the target host. Applies to VI 4
                                   targets only.
 -v /--version                   : Prints the version of this tool.
     --viCpuResource             : Specify the CPU resource settings for
                                   VI-locator targets. The syntax is
                                   --viCpuResource=<shares>:<reservation>:<limit>.
     --viMemoryResource          : Specify the CPU resource settings for
                                   VI-locator targets. The syntax is
                                   --viMemoryResource=<shares>:<reservation>:<limit>.
 -vf/--vmFolder                  : Target VM folder in VI inventory (relative
                                   to datacenter).

For more help, type: --help <topic>, where topics are:
 locators    : For detailed source and destination locator syntax
 examples    : For examples of use
 config      : For syntax of configuration files
 debug       : For debug purpose
 integration : For a list of options primarily used when ovftool is exec'ed
               from another tool or shellscript.

Использование довольно простое, например я использовал:

$ /Applications/VMware\ OVF\ Tool/ovftool /Users/captain/VirtualBox\ VMs/Windows\ 7/Windows\ 7\ x64.vmwarevm/Windows\ 7\ x64.vmx /Users/captain/VirtualBox\ VMs/Windows\ 7/Windows\ 7/windows_7.ovf
Opening VMX source: /Users/captain/VirtualBox VMs/Windows 7/Windows 7 x64.vmwarevm/Windows 7 x64.vmx
Opening OVF target: windows_7.ovf
Writing OVF package: windows_7.ovf
Disk progress: 5%

В папке которой был выполнен экспорт файлов, появятся файлы. Кликаем по файлу с «*.ovf» (у меня это windows_7.ovf):

Смотрим что хотим импортить, если что — изменяем и нажимаем на «Import». Импортинг занял 2 минуты у меня для Виндовс 7.

С приходом 64-битной ОС в МакОС, стало сложнее использование старые утилиты. Новые тоже не просто найти бесплатно. По этому, пришлось уйти с VMware…

Конвертация VMware virtual machine -> VirtualBox на Linux

В принципе — все тоже самое что я делал в МакОС, только нужно скачать бинарный файл для Linux-а. Если у кого-то возникнут трудность — смогу помочь! Пишите в комментариях возникшие ошибки и при первой возможности — отпишусь.

Вот и все, статья «Конвертация VMware virtual machine -> VirtualBox в Unix/Linux» завершена.

Сделаю себе заметку со списком команд для работы с Kubernetes. Дополнять буду по мере необходимости использования тех или иных команд на работе или на моем сервере.

Для начала, если используете или планируете использовать vi/vim, то добавим настройки. Открываем:

$ vim ~/.vimrc

Вставляем:

" Yaml file handling
autocmd FileType yaml setlocal ts=2 sts=2 sw=2 expandtab
filetype plugin indent on
autocmd FileType yaml setl indentkeys-=<:>

" Copy paste with ctr+c, ctr+v, etc
:behave mswin
:set clipboard=unnamedplus
:smap <Del> <C-g>"_d
:smap <C-c> <C-g>y
:smap <C-x> <C-g>x
:imap <C-v> <Esc>pi
:smap <C-v> <C-g>p
:smap <Tab> <C-g>1> 
:smap <S-Tab> <C-g>1<

Так же можно добавить автодополнение команд для kubectl.

Если используете BASH:

$ source <(kubectl completion bash) && \
echo "source <(kubectl completion bash)" >> ~/.bashrc

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

$ bash ~/.bashrc

Если используете ZSH:

$ source <(kubectl completion zsh) && \
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc

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

$ . ~/.zshrc

И так, приступим к командам.

Работа с POD-ами в Kubernetes

Вывести все поды которые задеплоились:

$ kubectl get pods
NAME                                                              READY   STATUS    RESTARTS   AGE
mirrormaker-in-kubernetes-chart-mirrormaker-in-kubernetes-mpsb8   0/1     Pending   0          19d

Вывести все нейм-спейсы которые используют поды:

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                                              READY   STATUS    RESTARTS   AGE
default       mirrormaker-in-kubernetes-chart-mirrormaker-in-kubernetes-mpsb8   0/1     Pending   0          19d
docker        compose-7b7c5cbbcc-6l5gt                                          1/1     Running   0          28d
docker        compose-api-dbbf7c5db-jxmz4                                       1/1     Running   1          28d

Чтобы вывести информацию о задеплоином ПОД-е, используем:

$ kubectl get pod mirrormaker-in-kubernetes-chart-mirrormaker-in-kubernetes-mpsb8 -o wide
NAME                                                              READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
mirrormaker-in-kubernetes-chart-mirrormaker-in-kubernetes-mpsb8   0/1     Pending   0          19d   <none>   <none>   <none>           <none>

Т.е синтаксис такой:

$ kubectl get pod <NAME_of_POD_HERE> -o wide

Или чтобы вывести инфу в виде YAML вывода, используем:

$ kubectl get pod <NAME_of_POD_HERE> -o yaml

Если нужно получить YAML вывод от ПОД-а без информации о кластере, то вот команда:

$ kubectl get pod my-pod -o yaml --export

Для вывода\дискрайба POD-а, выполняем:

$ kubectl describe pod <NAME_of_POD_HERE>

Или:

$ kubectl describe pods <NAME_of_POD_HERE>

Можно еще так:

$ kubectl describe nodes <NAME_of_POD_HERE>

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

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

Получить все поды по определенной лейбе:

$ kubectl get pods --selector=app=my_app_here -o \
  jsonpath='{.items[*].metadata.labels.version}'

Так же, при необходимости, можно вывести все поды по конкретному неймспйсу и чтобы ПОД-ы были запущены:

$ kubectl get pods --field-selector=status.phase=Running -n docker
NAME                          READY   STATUS    RESTARTS   AGE
compose-7b7c5cbbcc-6l5gt      1/1     Running   0          28d
compose-api-dbbf7c5db-jxmz4   1/1     Running   1          28d

Получить ExternalIPs всех узлов:

$ kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

Получить ПОД-ы со всеми лейбами которые они имеют, можно запустив команду:

$ kubectl get pods --show-labels

Удалить под можно так:

$ kubectl delete pod <NAME_OF_POD_HERE_1> <NAME_OF_POD_HERE_2>

Чтобы удалить ПОД с помощью файла в котором хранится конфигурация, можно так:

$ kubectl delete -f ./pod.json 

Удалить ПОД-ы по определенной лейбе:

$ kubectl delete pods -l name=myLabel   

Для удаления всех ПОД-ов в определенном неймспейсе:

$ kubectl -n <NAMESPACE_HERE> delete pod --all

Удалить все POD-ы, соответствующие awk pattern1 или pattern2 паттернам:

$ kubectl get pods  -n <NAMESPACE_HERE> --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n <NAMESPACE_HERE> pod

Идем дальше.

Работа с Deployments в Kubernetes

Создаем один deployment:

$ kubectl run <NAME_of_POD_HERE> --image=<NAME_of_IMAGE_HERE> --record

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

$ kubectl get deployments

Скользящее обновление «www» контейнеров «frontend» развертывания, обновление образа:

$ kubectl set image deployment/frontend www=image:v2

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

$ kubectl rollout history deployment/<YOUR_DEPLOYMENT_NAME_HERE>

Если нужно получить конкретную, то выполняем:

$ kubectl rollout undo deployment/<YOUR_DEPLOYMENT_NAME_HERE> --to-revision=N

Наблюдайте за непрерывным обновлением статуса развертывания «внешнего интерфейса» до завершения

$ kubectl rollout status -w deployment/<YOUR_DEPLOYMENT_NAME_HERE>

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

$ kubectl scale deployment/<NAME_of_POD_HERE> --replicas=<N_COUNT_REPLICAS>

Можно использовать файл:

$ kubectl scale --replicas=3 -f scale_replicas.yaml

Если текущий размер деплоймена с равен 3, масштабируйте его до 4 так:

$ kubectl scale --current-replicas=3 --replicas=4 deployment/<YOUR_DEPLOYMENT_HERE>

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

$ kubectl scale --replicas=5 rc/<YOUR_DEPLOYMENT_HERE_1> rc/<YOUR_DEPLOYMENT_HERE_2> rc/<YOUR_DEPLOYMENT_HERE_3>

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

$ cat pod.json | kubectl replace -f -

Можно выполнить команду и пересоздать ПОД силой (Будет аутедж!):

$ kubectl replace --force -f ./pod.json

И так далее.

Работа с Services в Kubernetes

Чтобы получить список сервисов, выполняем:

$ kubectl get services
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   28d

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

$ kubectl get services --sort-by=.metadata.name

Создать POD в виде сервиса (создает endpoints):

$ kubectl expose deployment/<YOUR_DEPLOYMENT_NAME_HERE> --port=8080 --type=NodePort

Удалить service по определенной лейбе:

$ kubectl delete service -l name=myLabel   

Для удаления всех service-ов в определенном неймспейсе:

$ kubectl -n <NAMESPACE_HERE> delete service --all

Шагаем дальше!

Работа с Volumes в Kubernetes

Чтобы получить список Persistent Volumes:

$ kubectl get pv

Чтобы получить список Persistent Volumes Claims:

$ kubectl get pvc

Если есть необходимость сортировки, можно использовать:

$ kubectl get pv -n <YOUR_NAMESPACE_HERE> --sort-by=.spec.capacity.storage

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

Работа с Secrets в Kubernetes

Для начала, получим список сикретов:

$ kubectl get secrets
NAME                                                    TYPE                                  DATA   AGE
default-token-rr6t6                                     kubernetes.io/service-account-token   3      28d
sh.helm.release.v1.mirrormaker-in-kubernetes-chart.v1   helm.sh/release.v1                    1      19d

Если не знаете как создать сикрет через CLI, то можно использовать помощь:

$ kubectl create secret generic --help

Например, создаем вот такой сикрет:

$ kubectl create secret generic mysql --from-literal=password=root

Получим информацию о созданном сикрете так:

$ kubectl get secrets mysql -o yaml
apiVersion: v1
data:
  password: cm9vdA==
kind: Secret
metadata:
  creationTimestamp: "2019-12-23T21:33:24Z"
  name: mysql
  namespace: default
  resourceVersion: "210625"
  selfLink: /api/v1/namespaces/default/secrets/mysql
  uid: e0ad6215-cc96-4e03-9ea8-ca5a58a5980c
type: Opaque

Или, можно создать сикрет следующим образом:

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

Кому как удобнее, так и используйте.

Вывести все секреты, которые в данный момент используются ПОД-ами:

$ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

Что дальше? Дальше идем….

Работа с ConfigMaps в Kubernetes

Чтобы создать конфиг-мапу, например с JS файла:

$ kubectl create configmap <configmap_name_here> --from-file=config.js

Получаем инфу о конфиг-мапе:

$ kubectl get configmap <configmap_name_here> -o yaml

Работа с DNS в Kubernetes

Получим все DNS-ы по всем неймспейсам:

$ kubectl get pods --all-namespaces |grep dns
kube-system   coredns-5c98db65d4-95dlc                                          1/1     Running   1          28d
kube-system   coredns-5c98db65d4-rhvvs                                          1/1     Running   1          28d

Проверить DNS для nginx ПОД-а (при условии, что POD / контейнер работает) можно так:

$ kubectl exec -ti busybox -- nslookup nginx

Примечание: kube-proxy, работающий в worker узлах, управляет службами и устанавливает правила iptables для прямого трафика.

Работа с Ingress в Kubernetes

Получаем все ингресы:

$ kubectl get ingress

Или, если необходимо использовать другой namespace:

$ kubectl get ingress -n docker
No resources found in docker namespace.

Команды для управления типом службы Ingress для ClusterIP:

$ kubectl expose deployment <YOUR_DEPLOYMENT_HERE> --port=2368

Идем дальше.

Работа с Horizontal Pod Autoscaler в Kubernetes

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

$ kubectl get hpa

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

$ kubectl get hpa -n docker
No resources found in docker namespace.

Задеплоим сервис с репликой, например:

$ kubectl autoscale deployment <YOUR_DEPLOYMENT_HERE> --min=6 --max=666 

Для помощи, используем:

$ kubectl autoscale --help

Работа с DaemonSets в Kubernetes

Чтобы получить ДемонСеты, стоит выполнить:

$ kubectl get daemonsets

Или:

$ kubectl get ds

Дальше добавлю если будет тут инфа.

Работа с Scheduler в Kubernetes

Политика на основе NodeSelector:

$ kubectl label node minikube foo=bar

Связывание узлов через API-сервер:

$ kubectl proxy 
$ curl -H "Content-Type: application/json" -X POST --data @binding.json http://localhost:8001/api/v1/namespaces/default/pods/foobar-sched/binding

Работа с Tains and Tolerations в Kubernetes

Есть команда:

$ kubectl taint node master foo=bar:NoSchedule

Как-то так.

Troubleshooting в Kubernetes

И так, вот список команд которые помогут в траблшутинге K8S:

$ kubectl describe
$ kubectl logs
$ kubectl exec
$ kubectl get nodes --show-labels
$ kubectl get events

Пример, если необходимо получить логи с ПОД-а:

$ kubectl logs <YOUR_POD_HERE>

Тоже самое, но с использованием меток:

$ kubectl logs -l name=<YOUR_LABEL_HERE> 

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

$ kubectl logs <YOUR_POD_HERE> --previous 

Тоже самое, но мулитиконвеер:

$ kubectl logs <YOUR_POD_HERE> -c <YOUR_CONTAINER_HERE>

Журналы дампа, с именем метки = yourLabel (стандартный вывод):

$ kubectl logs -l name= yourLabel -c <YOUR_CONTAINER_HERE>

Можно добавить опцию «-f» чтобы получать логи в реальном времени:

$ kubectl logs -f <YOUR_POD_HERE>

Запускать pod как интерактивную оболочку:

$ kubectl run -i --tty busybox --image=busybox -- sh

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

$ kubectl run nginx --image=nginx --restart=Never -n 
your_namespace_here

Запустите pod с nginx и запишите его спецификацию в файл с именем pod.yaml можно так:

$ kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > pod.yaml

Приатачиться к контейнеру можно так:

$ kubectl attach <YOUR_POD_HERE> -i

Чтобы сделать форвординг портов с локальной машины (например 5555) на ПОД (порт 6666), выполните:

$ kubectl port-forward <YOUR_POD_HERE> 5555:6666

Чтобы выполнить команду на ПОД-е (только в одном контейнере):

$ kubectl exec <YOUR_POD_HERE> -- ls / 

Чтобы выполнить команду на ПОД-е (в нескольких контейнерах):

$ kubectl exec <YOUR_POD_HERE> -c <YOUR_CONTAINER_HERE> -- ls / 

Показать метрики для данного ПОД-а и его контейнеров:

$ kubectl top pod <YOUR_POD_HERE> --containers

Выводим список ивентов отсортированых по timestamp:

$ kubectl get events --sort-by=.metadata.creationTimestamp

Может что-то еще полезное найду и дополню тут.

Взаимодействие с нодами и кластером

Можно пометить ноду как «недоступную» чтобы на нее не шел трафик:

$ kubectl cordon <YOUR_POD_HERE>

Выводим узел на мейнененс окно:

$ kubectl drain <YOUR_POD_HERE>

Вернуть ноду можно так:

$ kubectl uncordon <YOUR_POD_HERE>

Посмотреть метрики на хосте:

$ kubectl top node <YOUR_POD_HERE>

Чтобы вывести мастер-адресс и его сервисы, выполните:

$ kubectl cluster-info
Kubernetes master is running at https://kubernetes.docker.internal:6443
KubeDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

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

$ kubectl cluster-info dump

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

$ kubectl cluster-info dump --output-directory=./k8s_state.json 

Идем дальше.

Работа с Role Based Access Control в Kubernetes

Перечислите все поддерживаемые типы ресурсов вместе с их короткими именами, группой API, являются ли они пространством имен и Kind:

$ kubectl api-resources

Такс, чтобы вывести все ресурсы пространства имен:

$ kubectl api-resources --namespaced=true

Чтобы вывести все ресурсы не относящихся к пространству имен:

$ kubectl api-resources --namespaced=false

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

$ kubectl api-resources -o name

Или, использовать такой подход (показать все ресурсы с расширенным (он же «широкий») выводом):

$ kubectl api-resources -o wide 

Получить все ресурсы, которые поддерживают «list» и «get»:

$ kubectl api-resources --verbs=list,get

Получить все ресурсы в группе API «Расширения»:

$ kubectl api-resources --api-group=extensions
NAME                  SHORTNAMES   APIGROUP     NAMESPACED   KIND
daemonsets            ds           extensions   true         DaemonSet
deployments           deploy       extensions   true         Deployment
ingresses             ing          extensions   true         Ingress
networkpolicies       netpol       extensions   true         NetworkPolicy
podsecuritypolicies   psp          extensions   false        PodSecurityPolicy
replicasets           rs           extensions   true         ReplicaSet

Почти подошли к завершению…

Работа с Role Based Access Control в Kubernetes

Создаем роль:

$ kubectl create role YOUR_ROLE_HERE --verb=get --verb=list --verb=watch --resource=pods

Получаем инфу о роле:

$ kubectl get rolebinding <YOUR_ROLE_HERE> -o yaml

Работа с Security Contexts в Kubernetes

Чтобы задеплоить контекст который описан в файле, выполните:

$ kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml

Или 2-й пример:

$ kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml

Дополню позже, когда столкнусь с необходимостью….

Работа с Pod Security Policies в Kubernetes

Дополню позже, когда столкнусь с необходимостью….

Работа с Network Policies в Kubernetes

Создаем аннотацию:

$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

Чтобы получить полную или обновленную информацию, советую обратиться к официальной документации!

Вот и все, статья «Команды Kubernetes в Unix/Linux» завершена.

Minikube реализует локальный кластер Kubernetes на MacOS или Linux ОС. Основные цели minikube — стать лучшим инструментом для разработки локальных приложений Kubernetes и поддерживать все подходящие функции Kubernetes.

Установка minikube на MacOS

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

$ sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C

Как видно с моего вывода — у меня имеется все необходимое.

-=== СПОСОБ 1 ===-

Устанавливаем homebrew, статья тут — установка homebrew

А затем можно вводить комнду:

$ brew cask install minikube

-=== СПОСОБ 2 ===-

Также можно установить его на macOS, загрузив отдельный двоичный файл:

$ sudo curl -Lo /usr/local/bin/minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
  && sudo chmod +x /usr/local/bin/minikube

Проверим версию можно так:

$ minikube version
minikube version: v1.4.0
commit: 7969c25a98a018b94ea87d949350f3271e9d64b6

Вот так вот!

Настройка minikube в Unix/Linux

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

$ grep -E --color 'vmx|svm' /proc/cpuinfo

Затем стоит установить kubectl. Далее, стоит установить гипервизер, например kvm или virtualbox:

Установить Virtualbox на Centos/Fedora

Установить VirtualBox на Ubuntu/Debian или Linux Mint

Установка гипервизора KVM на Debian/Ubuntu

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

$ sudo apt install cpu-checker && sudo kvm-ok

Если после запуска kvm-ok вы получите следующий вывод, вы можете использовать KVM на своем компьютере (в противном случае проверьте свою конфигурацию):

$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

Теперь давайте установим KVM и libvirt и добавим нашего текущего пользователя в группу libvirt для предоставления достаточных разрешений:

$ sudo apt install libvirt-clients libvirt-daemon-system qemu-kvm \
    && sudo usermod -a -G libvirt $(whoami) \
    && newgrp libvirt

После установки libvirt вы можете проверить допустимость хоста для запуска виртуальных машин с помощью инструмента virt-host-validate, который является частью libvirt:

$ sudo virt-host-validate

Ставим kubectl:

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl \
    && sudo install kubectl /usr/local/bin && rm kubectl

Если KVM используется в качестве единственного драйвера для Minikube на нашей машине, более удобно установить его в качестве драйвера по умолчанию и запускать Minikube с меньшим количеством аргументов командной строки. Следующая команда устанавливает драйвер KVM по умолчанию:

$ minikube config set vm-driver kvm2

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

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
  && chmod +x minikube

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

$ sudo mkdir -p /usr/local/bin/ && \
install minikube /usr/local/bin/

Можно проверить версию утилиты:

$ minikube version

Установка выполнена.

Работа с minikube в Unix/Linux

Запуск очень простой:

$ minikube start

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

$ minikube start --cpus 6 --memory 8192
😄  minikube v1.2.0 on darwin (amd64)
👍  minikube will upgrade the local cluster from Kubernetes 1.10.0 to 1.15.0
💿  Downloading Minikube ISO ...
 129.33 MB / 129.33 MB [============================================] 100.00% 0s
💡  Tip: Use 'minikube start -p <name>' to create a new cluster, or 'minikube delete' to delete this one.
🔄  Restarting existing virtualbox VM for "minikube" ...
⌛  Waiting for SSH access ...
🐳  Configuring environment for Kubernetes v1.15.0 on Docker 17.12.1-ce
💾  Downloading kubeadm v1.15.0
💾  Downloading kubelet v1.15.0
🚜  Pulling images ...
🔄  Relaunching Kubernetes v1.15.0 using kubeadm ...
⌛  Verifying: apiserver proxy etcd scheduler controller dns
🏄  Done! kubectl is now configured to use "minikube"

PS: Запуск был выполнен на МакОС, а в качестве гипервизера был выбрал virtualbox.

Можно получить следующую ошибку:

machine does not exist

Решение:

$ minikube delete && minikube start

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

$ minikube status

Если есть необходимость удалить стек, выполните:

$ minikube delete
🔥  Deleting "minikube" in virtualbox ...
💔  The "minikube" cluster has been deleted.

Для помощи, выполняем:

$ minikube --help
Minikube is a CLI tool that provisions and manages single-node Kubernetes clusters optimized for development workflows.

Basic Commands:
  start          Starts a local kubernetes cluster
  status         Gets the status of a local kubernetes cluster
  stop           Stops a running local kubernetes cluster
  delete         Deletes a local kubernetes cluster
  dashboard      Access the kubernetes dashboard running within the minikube cluster

Images Commands:
  docker-env     Sets up docker env variables; similar to '$(docker-machine env)'
  cache          Add or delete an image from the local cache.

Configuration and Management Commands:
  addons         Modify minikube's kubernetes addons
  config         Modify minikube config
  profile        Profile gets or sets the current minikube profile
  update-context Verify the IP address of the running cluster in kubeconfig.

Networking and Connectivity Commands:
  service        Gets the kubernetes URL(s) for the specified service in your local cluster
  tunnel         tunnel makes services of type LoadBalancer accessible on localhost

Advanced Commands:
  mount          Mounts the specified directory into minikube
  ssh            Log into or run a command on a machine with SSH; similar to 'docker-machine ssh'
  kubectl        Run kubectl

Troubleshooting Commands:
  ssh-key        Retrieve the ssh identity key path of the specified cluster
  ip             Retrieves the IP address of the running cluster
  logs           Gets the logs of the running instance, used for debugging minikube, not user code.
  update-check   Print current and latest version number
  version        Print the version of minikube

Other Commands:
  completion     Outputs minikube shell completion for the given shell (bash or zsh)

Use "minikube <command> --help" for more information about a given command.

Или конкретно для какой-то команды:

$ minikube start --help
Starts a local kubernetes cluster

Options:
      --apiserver-ips=[]: A set of apiserver IP Addresses which are used in the generated certificate for kubernetes.
This can be used if you want to make the apiserver available from outside the machine
      --apiserver-name='minikubeCA': The apiserver name which is used in the generated certificate for kubernetes.  This
can be used if you want to make the apiserver available from outside the machine
      --apiserver-names=[]: A set of apiserver names which are used in the generated certificate for kubernetes.  This
can be used if you want to make the apiserver available from outside the machine
      --apiserver-port=8443: The apiserver listening port
      --cache-images=true: If true, cache docker images for the current bootstrapper and load them into the machine.
Always false with --vm-driver=none.
      --container-runtime='docker': The container runtime to be used (docker, crio, containerd).
      --cpus=2: Number of CPUs allocated to the minikube VM.
      --cri-socket='': The cri socket path to be used.
      --disable-driver-mounts=false: Disables the filesystem mounts provided by the hypervisors
      --disk-size='20000mb': Disk size allocated to the minikube VM (format: <number>[<unit>], where unit = b, k, m or
g).
      --dns-domain='cluster.local': The cluster dns domain name used in the kubernetes cluster
      --dns-proxy=false: Enable proxy for NAT DNS requests (virtualbox driver only)
      --docker-env=[]: Environment variables to pass to the Docker daemon. (format: key=value)
      --docker-opt=[]: Specify arbitrary flags to pass to the Docker daemon. (format: key=value)
      --download-only=false: If true, only download and cache files for later use - don't install or start anything.
      --embed-certs=false: if true, will embed the certs in kubeconfig.
      --enable-default-cni=false: Enable the default CNI plugin (/etc/cni/net.d/k8s.conf). Used in conjunction with
"--network-plugin=cni".
      --extra-config=: A set of key=value pairs that describe configuration that may be passed to different components.
		The key should be '.' separated, and the first part before the dot is the component to apply the configuration to.
		Valid components are: kubelet, kubeadm, apiserver, controller-manager, etcd, proxy, scheduler
		Valid kubeadm parameters: ignore-preflight-errors, dry-run, kubeconfig, kubeconfig-dir, node-name, cri-socket,
experimental-upload-certs, certificate-key, rootfs, pod-network-cidr
      --feature-gates='': A set of key=value pairs that describe feature gates for alpha/experimental features.
      --force=false: Force minikube to perform possibly dangerous operations
      --host-dns-resolver=true: Enable host resolver for NAT DNS requests (virtualbox driver only)
      --host-only-cidr='192.168.99.1/24': The CIDR to be used for the minikube VM (virtualbox driver only)
      --hyperkit-vpnkit-sock='': Location of the VPNKit socket used for networking. If empty, disables Hyperkit
VPNKitSock, if 'auto' uses Docker for Mac VPNKit connection, otherwise uses the specified VSock (hyperkit driver only)
      --hyperkit-vsock-ports=[]: List of guest VSock ports that should be exposed as sockets on the host (hyperkit
driver only)
      --hyperv-virtual-switch='': The hyperv virtual switch name. Defaults to first found. (hyperv driver only)
      --image-mirror-country='': Country code of the image mirror to be used. Leave empty to use the global one. For
Chinese mainland users, set it to cn.
      --image-repository='': Alternative image repository to pull docker images from. This can be used when you have
limited access to gcr.io. Set it to "auto" to let minikube decide one for you. For Chinese mainland users, you may use
local gcr.io mirrors such as registry.cn-hangzhou.aliyuncs.com/google_containers
      --insecure-registry=[]: Insecure Docker registries to pass to the Docker daemon.  The default service CIDR range
will automatically be added.
      --interactive=true: Allow user prompts for more information
      --iso-url='https://storage.googleapis.com/minikube/iso/minikube-v1.4.0.iso': Location of the minikube iso.
      --keep-context=false: This will keep the existing kubectl context and will create a minikube context.
      --kubernetes-version='v1.16.0': The kubernetes version that the minikube VM will use (ex: v1.2.3)
      --kvm-gpu=false: Enable experimental NVIDIA GPU support in minikube
      --kvm-hidden=false: Hide the hypervisor signature from the guest in minikube (kvm2 driver only)
      --kvm-network='default': The KVM network name. (kvm2 driver only)
      --kvm-qemu-uri='qemu:///system': The KVM QEMU connection URI. (kvm2 driver only)
      --memory='2000mb': Amount of RAM allocated to the minikube VM (format: <number>[<unit>], where unit = b, k, m or
g).
      --mount=false: This will start the mount daemon and automatically mount files into minikube.
      --mount-string='/Users:/minikube-host': The argument to pass the minikube mount command on start.
      --native-ssh=true: Use native Golang SSH client (default true). Set to 'false' to use the command line 'ssh'
command when accessing the docker machine. Useful for the machine drivers when they will not start with 'Waiting for
SSH'.
      --network-plugin='': The name of the network plugin.
      --nfs-share=[]: Local folders to share with Guest via NFS mounts (hyperkit driver only)
      --nfs-shares-root='/nfsshares': Where to root the NFS Shares, defaults to /nfsshares (hyperkit driver only)
      --no-vtx-check=false: Disable checking for the availability of hardware virtualization before the vm is started
(virtualbox driver only)
      --registry-mirror=[]: Registry mirrors to pass to the Docker daemon
      --service-cluster-ip-range='10.96.0.0/12': The CIDR to be used for service cluster IPs.
      --uuid='': Provide VM UUID to restore MAC address (hyperkit driver only)
      --vm-driver='': Driver is one of: [virtualbox parallels vmwarefusion hyperkit vmware] (defaults to virtualbox)
      --wait=true: Wait until Kubernetes core services are healthy before exiting.
      --wait-timeout=6m0s: max time to wait per Kubernetes core services to be healthy.

Usage:
  minikube start [flags] [options]

Use "minikube start options" for a list of global command-line options (applies to all commands).

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

Давайте проверим, работает ли кластер Kubernetes:

$ kubectl get nodes

Теперь давайте запустим простой пример приложения (в нашем случае nginx):

$ kubectl create deployment nginx --image=nginx

Давайте также проверим, правильно ли настроены pods в Kubernetes:

$ kubectl get pods

Вот и все, статья «Установка minikube в Unix/Linux» завершена.

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

$ docker exec -ti jenkins /bin/bash
 jenkins@6350b7b8729c:/$ su -
 Password:

Как видно с команды выше, я запустил дженкинс. У контейнера имеется пользователь (тоже дженкинс), но я не знаю от него пароль. Решение — это использовать параметр который выставит нужного юзера при старте контейнера:

$ docker exec -it -u your_container_user your_conatainer container_command

Или:

$ docker exec -it --user your_container_user your_conatainer container_command 

Приведу пример с дженкинсом:

$ docker exec -it -u root jenkins /bin/bash

При данной команде, я подключусь к контейнеру как root-юзер.

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

$ sudo -u your_user "docker run -d     --name jenkins     --hostname jenkins.local     -p 8080:8080 -p 50000:50000     --restart always     -v /usr/local/jenkins/data_2:/var/jenkins_home     --dns=10.17.0.3     --dns=10.17.0.4     --dns=1.1.1.1     --dns=74.82.42.42     --add-host=gitlab_local_docker:172.168.0.66     jenkins/jenkins:latest"

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

$ su YOUR_USER 

И потом, можно вот так:

docker run -d \
     --name jenkins \
     --hostname jenkins.local \
     -p 8080:8080 -p 50000:50000 \
     --restart always \
     -v /usr/local/jenkins/data_2:/var/jenkins_home \
     --dns=10.17.0.3 \
     --dns=10.17.0.4 \
     --dns=1.1.1.1 \
     --dns=74.82.42.42 \
     --add-host=gitlab_local_docker:172.168.0.66 \
     jenkins/jenkins:latest 

Вот и все, статья «Запустить Docker контейнер от пользователя в Unix/Linux» завершена.

Установка Helm в Unix/Linux

Helm — это бинарный файл, который управляет развертыванием chart-ов (диаграм) в Kubernetes.  Что такое chart или диаграмма? А это собственно, — упакованная единица вашего программного обеспечения для деплоя в kubernetes. Он содержит все определения ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes (Это что-то подобное как в  Homebrew, Apt dpkg или RPM Yum).

Helm помогает вам управлять приложениями Kubernetes — Helm Charts помогает вам определять, устанавливать и обновлять даже самое сложное приложения в k8s.

Репозиторий (Repo) — это место, где диаграммы (chart-ы) могут хранится и использоваться. Это похоже на архив CPAN Perl или базу данных Fedora пакетов, но для Kubernetes.

Выпуск (Release) представляет собой экземпляр диаграммы, выполняющейся в кластере Kubernetes. Одна диаграмма может быть установлена много раз на один и тот же k8s кластер.

Установка Helm в Unix/Linux

Так как helm нужен для помощи с k8s, то нужно установить Kubernetes. Если еще не сделали, то вот полезные маны:

Установка Kubernetes в Unix/Linux

Установка Kubernetes кластера в Unix/Linux

Я буду использовать minikube (но это не столь важно) для стоих локальных тестов. И так, давайте приступим к установке хелма и посмотрим как можно работать с ним.

-=== СПОСОБ 1 ===-

Можно вытянуть мастер ветку с гита через wget/curl, например:

$ wget https://codeload.github.com/helm/helm/zip/master -O /usr/local/src/helm.zip && unzip /usr/local/src/helm.zip -d /usr/local/src

Или через git:

$ cd /usr/local/src && git clone https://github.com/helm/helm.git

Перейдем в папку:

$ cd helm

И выполняем билд:

$ make bootstrap build

Готово!

-=== СПОСОБ 2 ===-

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

$ curl -s --list-only https://github.com/helm/helm/releases | grep -E "https://storage.googleapis.com/kubernetes-helm/helm-"| grep -E "MacOS|Linux"| cut -d">" -f2| cut -d"=" -f2| cut -d '"' -f2

Покажет примерно вот такое:

https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-darwin-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-arm.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-arm64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-386.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-ppc64le.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-linux-s390x.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-darwin-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-linux-amd64.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-linux-arm.tar.gz
https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-rc.4-linux-arm64.tar.gz

.............

Находим необходимую ссылку и качаем

$ wget https://storage.googleapis.com/kubernetes-helm/helm-v2.11.0-darwin-amd64.tar.gz -O /usr/local/src/helm-v2.11.0-darwin-amd64.tar.gz

Получаем бинарник из архива:

$ tar xfvz /usr/local/src/helm-v2.11.0-darwin-amd64.tar.gz -C /usr/local/src

Перемещаем бинарник:

$ mv darwin-amd64/helm /usr/local/bin/helm && sudo chmod +x /usr/local/bin/helm

Да! Иногда я велосипедю))) Но разве это плохо? xD

Почитав доку с хелмом, нашел их решение по уставновке (ЛОЛка):

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get | bash

Или:

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Можно юзать все кому что удобно.

-=== СПОСОБ 3 ===-

Для Mac OS X имеется установщик через homebrew (Установка homebrew тут):

$ brew install kubernetes-helm kubernetes-cli

Может есть еще другие способы установить данное ПО себе на машину, но думаю этих хватит.

Настройка Helm в Unix/Linux

Для хелма нужно следующее:

• Кластер с кубернетисом (иногда я его буду называть — куб или кубик). Для последней версии Helm рекомендуется использовать последнюю стабильную версию Kubernetes.
• Настройка политик безопасности для кластера и работы с хелмом.
• Вы также должны иметь локальную конфигурацию kubectl.
• Установка и настройка Helm and Tiller (со стороны кластера).

ПРИМЕЧАНИЕ. Kubernetes до 1.6 версии имеет ограниченный или не поддерживаются для управления доступом на основе ролей (RBAC).

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

$ kubectl config current-context
gke_terraform-2018_us-east1-b_test-cc-stage

Или, можно выполнить:

$ kubectl cluster-info
Kubernetes master is running at https://104.196.128.119

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Unable to connect to the server: x509: certificate signed by unknown authority

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

Однако, если ваш кластер подвергается воздействию более крупной сети или если вы шарите  k8s с другими ( я за ПРОД кластеры) вы должны предпринять дополнительные шаги для защиты вашей установки, чтобы предотвратить компрометирование кластера или его данных.

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

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

$ kubectl get nodes

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    master   1d    v1.10.0

Т.к у меня  это первое знакомство и по этому я не буду приводить примеры по защите k8s кластера. Но когда это понадобится (получу больше опыта) — обязательно дополню статью навыми полезностями.

Инициализация Helm и установка Tiller

Как только вы установили Helm, можете инициализировать его CLI (командную строку), а также установить Tiller в кластер Kubernetes:

$ helm init

Вывод:

Creating /Users/captain/.helm
Creating /Users/captain/.helm/repository
Creating /Users/captain/.helm/repository/cache
Creating /Users/captain/.helm/repository/local
Creating /Users/captain/.helm/plugins
Creating /Users/captain/.helm/starters
Creating /Users/captain/.helm/cache/archive
Creating /Users/captain/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /Users/captain/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

PS: Можно инициализировать Helm следующим образом:

$ helm init --output json

По умолчанию helm init обеспечит настройку локального $HELM_HOME, а затем установит Tiller на кластере. Можно отказатся от установки Tiller, для этого используйте:

$ helm init --client-only

Можно использовать не стабильную версию ПО, для этого есть «—canary-image» опция:

$ helm init --canary-image

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

$ helm init --upgrade

По умолчанию helm сохраняет информацию о release в ConfigMaps пространстве имен (т.е там где он запущен). Начиная с Helm версии 2.7.0, теперь есть бета-версия бета-памяти, которая использует Secrets для хранения информации. Это было добавлено для дополнительной защиты в Kubernetes.

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

$ helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'

Данная команда установит Tiller в кластер Kubernetes, который вы видели с помощью:

$ kubectl config current-context

Можно получить все контенты:

$ kubectl config get-contexts
CURRENT   NAME                                          CLUSTER                                       AUTHINFO                                      NAMESPACE
          docker-for-desktop                            docker-for-desktop-cluster                    docker-for-desktop
          gke_terraform-2018_us-east1-b_test-cc-stage   gke_terraform-2018_us-east1-b_test-cc-stage   gke_terraform-2018_us-east1-b_test-cc-stage
*         minikube                                      minikube                                      minikube

Как видно с вывода, у меня юзается миникуб и он активный в данный момент.

Советы:

• СОВЕТ 1. Хотите установить в другой кластер? Используйте флаг «—kube-context».
• СОВЕТ 2. Если вы хотите обновить Tiller, просто запустите «helm init —upgrade».

По умолчанию Tiller устанавливается в кластер контекста kubectl (kubectl config current-context), в пространство имён kube-system, но это можно изменить, используя соответствующие опции и переменные окружения — они описаны в справке (helm init —help).

$ kubectl get all --selector=name=tiller --namespace kube-system

NAME                                 READY   STATUS    RESTARTS   AGE
pod/tiller-deploy-6fd8d857bc-snfsf   1/1     Running   4          1d

NAME                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
service/tiller-deploy   ClusterIP   10.100.44.210   <none>        44134/TCP   1d

NAME                            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/tiller-deploy   1         1         1            1           1d

NAME                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/tiller-deploy-6fd8d857bc   1         1         1       1d

Можно вывести инфу только для tiller-а:

$ kubectl --namespace kube-system get pods | grep tiller

tiller-deploy-6fd8d857bc-snfsf          1/1     Running   4          1d

Для помощи всегда есть:

$ helm -h
The Kubernetes package manager

To begin working with Helm, run the 'helm init' command:

	$ helm init

This will install Tiller to your running Kubernetes cluster.
It will also set up any necessary local configuration.

Common actions from this point include:

- helm search:    search for charts
- helm fetch:     download a chart to your local directory to view
- helm install:   upload the chart to Kubernetes
- helm list:      list releases of charts

Environment:
  $HELM_HOME          set an alternative location for Helm files. By default, these are stored in ~/.helm
  $HELM_HOST          set an alternative Tiller host. The format is host:port
  $HELM_NO_PLUGINS    disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins.
  $TILLER_NAMESPACE   set an alternative Tiller namespace (default "kube-system")
  $KUBECONFIG         set an alternative Kubernetes configuration file (default "~/.kube/config")
  $HELM_TLS_CA_CERT   path to TLS CA certificate used to verify the Helm client and Tiller server certificates (default "$HELM_HOME/ca.pem")
  $HELM_TLS_CERT      path to TLS client certificate file for authenticating to Tiller (default "$HELM_HOME/cert.pem")
  $HELM_TLS_KEY       path to TLS client key file for authenticating to Tiller (default "$HELM_HOME/key.pem")
  $HELM_TLS_VERIFY    enable TLS connection between Helm and Tiller and verify Tiller server certificate (default "false")
  $HELM_TLS_ENABLE    enable TLS connection between Helm and Tiller (default "false")

Usage:
  helm [command]

Available Commands:
  completion  Generate autocompletions script for the specified shell (bash or zsh)
  create      create a new chart with the given name
  delete      given a release name, delete the release from Kubernetes
  dependency  manage a chart's dependencies
  fetch       download a chart from a repository and (optionally) unpack it in local directory
  get         download a named release
  help        Help about any command
  history     fetch release history
  home        displays the location of HELM_HOME
  init        initialize Helm on both client and server
  inspect     inspect a chart
  install     install a chart archive
  lint        examines a chart for possible issues
  list        list releases
  package     package a chart directory into a chart archive
  plugin      add, list, or remove Helm plugins
  repo        add, list, remove, update, and index chart repositories
  reset       uninstalls Tiller from a cluster
  rollback    roll back a release to a previous revision
  search      search for a keyword in charts
  serve       start a local http web server
  status      displays the status of the named release
  template    locally render templates
  test        test a release
  upgrade     upgrade a release
  verify      verify that a chart at the given path has been signed and is valid
  version     print the client/server version information

Flags:
      --debug                           enable verbose output
  -h, --help                            help for helm
      --home string                     location of your Helm config. Overrides $HELM_HOME (default "/Users/captain/.helm")
      --host string                     address of Tiller. Overrides $HELM_HOST
      --kube-context string             name of the kubeconfig context to use
      --kubeconfig string               absolute path to the kubeconfig file to use
      --tiller-connection-timeout int   the duration (in seconds) Helm will wait to establish a connection to tiller (default 300)
      --tiller-namespace string         namespace of Tiller (default "kube-system")

Use "helm [command] --help" for more information about a command.

Перейдем к использованию.

Использование SSL/TLS между Helm и Tiller

Первое что делаем, — это создаем центр сертификации:

$ openssl genrsa -out ./ca.key.pem 4096
Generating RSA private key, 4096 bit long modulus
.......................................++
.............................................................................++
e is 65537 (0x10001)

И потом запускаем:

$ openssl req -key ca.key.pem -new -x509 -days 7300 -sha256 -out ca.cert.pem -extensions v3_ca
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:Ukraine
Locality Name (eg, city) [Default City]:Kiev
Organization Name (eg, company) [Default Company Ltd]:linux-notes
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Tiller
Email Address []:solo.metal@bigmir.net

Идем дальше, генерируем ключ для Tiller:

$ openssl genrsa -out ./tiller.key.pem 4096
Generating RSA private key, 4096 bit long modulus
.......................................++
.......................++
e is 65537 (0x10001)

Идем дальше, генерируем ключ для Helm:

$ openssl genrsa -out ./helm.key.pem 4096
Generating RSA private key, 4096 bit long modulus
..................++
............................................................................++
e is 65537 (0x10001)

Затем нам нужно создать сертификаты из этих ключей:

$ openssl req -key tiller.key.pem -new -sha256 -out tiller.csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:Ukraine
Locality Name (eg, city) [Default City]:Kiev
Organization Name (eg, company) [Default Company Ltd]:linux-notes
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Tiller-server
Email Address []:solo.metal@bigmir.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

PS: Я пароль не устанавливал для ключа. Не вижу смысла, т.к настраиваю для тестового окружения.

И мы повторяем этот шаг для Helm сертификата:

$ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:Ukraine
Locality Name (eg, city) [Default City]:Kiev
Organization Name (eg, company) [Default Company Ltd]:linux-notes
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Helm
Email Address []:solo.metal@bigmir.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Теперь мы подписываем каждую из этих CSR с созданным CA-сертификатом (скорректируйте параметр days в соответствии с вашими требованиями):

$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365
Signature ok
subject=/C=UA/ST=Ukraine/L=Kiev/O=linux-notes/CN=Tiller-server/emailAddress=solo.metal@bigmir.net
Getting CA Private Key

И снова для клиентского сертификата:

$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in helm.csr.pem -out helm.cert.pem  -days 365
Signature ok
subject=/C=UA/ST=Ukraine/L=Kiev/O=linux-notes/CN=Helm/emailAddress=solo.metal@bigmir.net
Getting CA Private Key

На данный момент важными для нас являются следующие файлы:

• CA. Убедитесь, что ключ хранится в секрете: ca.cert.pem и ca.key.pem.
• Файлы Helm клиента: helm.cert.pem и helm.key.pem
• Файлы Tiller сервера: tiller.cert.pem и tiller.key.pem

Т.е структура всех файлов имеет вид:

$ ll
total 72
-rwxrwxrwx  1 captain  staff  2065 Nov  6 10:40 ca.cert.pem
-rwxrwxrwx  1 captain  staff  3247 Nov  6 10:38 ca.key.pem
-rwxrwxrwx  1 captain  staff    17 Nov  6 10:46 ca.srl
-rwxrwxrwx  1 captain  staff  1948 Nov  6 10:46 helm.cert.pem
-rwxrwxrwx  1 captain  staff  1720 Nov  6 10:45 helm.csr.pem
-rwxrwxrwx  1 captain  staff  3243 Nov  6 10:41 helm.key.pem
-rwxrwxrwx  1 captain  staff  1960 Nov  6 10:45 tiller.cert.pem
-rwxrwxrwx  1 captain  staff  1736 Nov  6 10:43 tiller.csr.pem
-rwxrwxrwx  1 captain  staff  3243 Nov  6 10:41 tiller.key.pem

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

$ helm init --tiller-tls \
--tiller-tls-cert ./tiller.cert.pem \
--tiller-tls-key ./tiller.key.pem \
--tiller-tls-verify \
--tls-ca-cert ca.cert.pem \
--dry-run \
--debug

Через минуту или две он должен быть готов. Мы можем проверить Тиллера следующим образом:

$ kubectl -n kube-system get deployment

NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
... other stuff
tiller-deploy   1         1         1            1           2m

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

$ kubectl get pods -n kube-system

На этом этапе вы должны получить ошибку при запуске основных команд Helm:

$ helm ls
Error: transport is closing

Это связано с тем, что ваш Helm клиент не имеет правильного сертификата для аутентификации в Tiller. Tiller теперь работает с TLS. Пришло время настроить Helm клиент для работы с TLS. Выполним проверку:

$ helm ls --tls --tls-ca-cert ca.cert.pem --tls-cert helm.cert.pem --tls-key helm.key.pem

Эта конфигурация отправляет наш клиентский сертификат для установления личности, использует ключ клиента для шифрования и использует CA сертификат для проверки идентификатора удаленного Tiller.

Данная команда, — рабочая, но очень длинная. Чтобы пофиксить все это дело, выполняем:

$ cp ca.cert.pem $(helm home)/ca.pem
$ cp helm.cert.pem $(helm home)/cert.pem
$ cp helm.key.pem $(helm home)/key.pem

После чего, можно смело юзать:

$ helm ls --tls

Как-то так!

Деплой или разворачивания char-тов в Helm

У Helm есть несколько способов установить chart-ы:

1. Найти готовое решение (готовый чарт) и установить его.
2. Создать свой chart и потом задеплоить его.

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

Получаем/обновляем репозиторий со всеми диаграмами(чартами):

$ helm repo update

Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

По умолчанию Helm использует официальный репозиторий чартов Kubernetes. Он содержит тщательно проработанные актуальные чарты для решения множества прикладных задач. Этот репозиторий именуется stable:

$ helm repo list

NAME  	URL
stable	https://kubernetes-charts.storage.googleapis.com
local 	http://127.0.0.1:8879/charts

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

$ helm search grafana

NAME          	CHART VERSION	APP VERSION	DESCRIPTION
stable/grafana	1.17.4       	5.3.2      	The leading tool for querying and visualizing time series...

Ах да, для вывода всех актуальных чартов можно использовать:

$ helm search

Добавить репозиторий с каким-то чартом (пример incubator репозиторий):

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

"incubator" has been added to your repositories

И теперь можно поискать\поставить пакет.

PS: Для удаления репозитория можно выполнить:

$ helm repo remove incubator

Перед тем как устанавливать чарт, можно узнать о нем информацию, а сделать это можно выполнив:

$ helm inspect stable/grafana

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

$ helm inspect values stable/grafana

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

$ helm install --name=grafana stable/grafana

NAME:   grafana
LAST DEPLOYED: Sat Nov  3 21:23:59 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ClusterRole
NAME                 AGE
grafana-clusterrole  1s

==> v1/Service
grafana  1s

==> v1beta2/Deployment
grafana  1s

==> v1/Pod(related)

NAME                      READY  STATUS             RESTARTS  AGE
grafana-5688858b6c-s9vq2  0/1    ContainerCreating  0         1s

==> v1beta1/PodSecurityPolicy

NAME     AGE
grafana  1s

==> v1/Secret
grafana  1s

==> v1/ClusterRoleBinding
grafana-clusterrolebinding  1s

==> v1beta1/Role
grafana  1s

==> v1beta1/RoleBinding
grafana  1s

==> v1/ConfigMap
grafana  1s

==> v1/ServiceAccount
grafana  1s


NOTES:
1. Get your 'admin' user password by running:

   kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

2. The Grafana server can be accessed via port 80 on the following DNS name from within your cluster:

   grafana.default.svc.cluster.local

   Get the Grafana URL to visit by running these commands in the same shell:

     export POD_NAME=$(kubectl get pods --namespace default -l "app=grafana,component=" -o jsonpath="{.items[0].metadata.name}")
     kubectl --namespace default port-forward $POD_NAME 3000

3. Login with the password from step 1 and the username: admin
#################################################################################
######   WARNING: Persistence is disabled!!! You will lose your data when   #####
######            the Grafana pod is terminated.                            #####
#################################################################################

ЗАМЕЧАНИЕ! С вывода что выше, указаны некоторые инструкции, но у меня не заработал форвардинг портов (пришлось гуглить).

Графана запущена в ПОД-е и доступна только в нем, но чтобы она заработала, нужно выполнить форвординг портов:

$ export POD_NAME=$(kubectl get pods --namespace default -l "app=grafana" -o jsonpath="{.items[0].metadata.name}")

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

$ kubectl --namespace default port-forward $POD_NAME 3000

Доступ к графане будет на 127.0.0.1:3000. Логин у нас — admin, а вот пароль получаем:

$ kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

Теперь можете пробовать залогинится и проверить как оно работает. Такой запуск имеет свои недостатки, — после выключения ПОД-а, данные с графана-сервера пропадут. Я пока не гуглил как я могу это исправить, но попозже обязательно найду и добавлю в эту статью! Если кто-то знает как это сделать — просьба описать процесс.

Посмотрим какие сервисы уже установились в системе:

$ minikube service list

|-------------|----------------------|--------------|
|  NAMESPACE  |         NAME         |     URL      |
|-------------|----------------------|--------------|
| default     | grafana              | No node port |
| default     | kubernetes           | No node port |
| kube-system | kube-dns             | No node port |
| kube-system | kubernetes-dashboard | No node port |
| kube-system | tiller-deploy        | No node port |
|-------------|----------------------|--------------|

Смотрим релизы:

$ helm list

NAME   	REVISION	UPDATED                 	STATUS  	CHART         	APP VERSION	NAMESPACE
grafana	1       	Sat Nov  3 21:23:59 2018	DEPLOYED	grafana-1.17.4	5.3.2      	default

Чтобы посмотреть ваши ревизии, заюзайте:

$ helm history grafana

REVISION	UPDATED                 	STATUS  	CHART         	DESCRIPTION
1       	Sat Nov  3 21:23:59 2018	DEPLOYED	grafana-1.17.4	Install complete

У меня только одна ревизия релиза т.к я ничего больше не передеплоивал.

Можно выполнить ролбек (откат к какому-то релизу):

$ helm rollback grafana 1

Rollback was a success! Happy Helming!

В хелме ведется история, ее можно просмотерть:

$ helm history grafana

REVISION	UPDATED                 	STATUS    	CHART         	DESCRIPTION
1       	Sat Nov  3 21:23:59 2018	SUPERSEDED	grafana-1.17.4	Install complete
2       	Sat Nov  3 23:28:31 2018	DEPLOYED  	grafana-1.17.4	Rollback to 1

Давайте заскейлим графану до 3- репликаций:

$ kubectl scale --replicas 3 deployment/grafana

deployment.extensions/grafana scaled

Получаем поды:

$ kubectl get pods

NAME                       READY   STATUS    RESTARTS   AGE
grafana-5688858b6c-btxjv   1/1     Running   0          25s
grafana-5688858b6c-d99kb   1/1     Running   0          2m
grafana-5688858b6c-g46fz   1/1     Running   0          25s

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

$ kubectl delete pod grafana-5688858b6c-btxjv
pod "grafana-5688858b6c-btxjv" deleted

Чекаем:

$ kubectl get pods

NAME                       READY   STATUS    RESTARTS   AGE
grafana-5688858b6c-cz4gx   1/1     Running   0          6s
grafana-5688858b6c-d99kb   1/1     Running   0          3m
grafana-5688858b6c-g46fz   1/1     Running   0          1m

С вывода видно что поды вернулись в нужно состояние (т.к я установил репликацию в 3).

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

$ kubectl get service

Удалить можно следующим образом:

$ kubectl delete service grafana

Можно получить много полезной информации через:

$ kubectl describe svc grafana

Name:              grafana
Namespace:         default
Labels:            app=grafana
                   chart=grafana-1.17.4
                   heritage=Tiller
                   release=grafana
Annotations:       <none>
Selector:          app=grafana,release=grafana
Type:              ClusterIP
IP:                10.105.2.247
Port:              service  80/TCP
TargetPort:        3000/TCP
Endpoints:         172.17.0.6:3000,172.17.0.7:3000,172.17.0.8:3000
Session Affinity:  None
Events:            <none>

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

$ helm delete grafana

release "grafana" deleted

Для полного удаления релиза используется опция —purge:

$ helm delete --purge grafana

Это я примеры приводил для работы с готовыми chart-ами, которые находятся в репозиторие(ях). Пришло время создать что-то свое. Возможно велосипед, а возможно и произведение искуства =D.

Создание своего chart-а для Helm

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

$ mkdir -p ~/Projects/k8s

Собственно в данной папке будут лежать все мои созданные chart-endpoint-ы.

Создадим каркас для одного из них (где endpoints — это имя вашего чарта):

$ helm create endpoints

Это создаст настройку для Helm Chart, которую вам нужно будет отредактировать:

• $ vim endpoints/templates/deployment.yaml
• $ vim endpoints/templates/service.yaml

Теперь можно установить созданную диаграмму на Kubernetes кластер. Допустим, у вас есть Helm Chart (я назвал его endpoints), мы можем установить ее в наш активный кластер Kubernetes с помощью следующей команды:

$ helm install --name endpoints endpoints

Данное действие установит чарт на k8s кластер с нужными параметрами которые описали в настройках (значения по умолчанию). Что делать, если мы хотим изменить одно значение в файле values.yaml? Мы можем легко это сделать с помощью «—set»команды:

$ helm install --name endpoints endpoints \
--set your_key=your_value

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

$ helm install --name endpoints endpoints \
--set your_key=your_value \
--dry-run \
--debug

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

$ helm package endpoints
Successfully packaged chart and saved it to: /Users/captain/Projects/k8s/endpoints-0.1.0.tgz

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

$ helm install ./endpoints-0.1.0.tgz

Вот так вот можно создавать свои чарты.

Установка плагинов в Helm

Для helm-а имеется плагины которые расширяют его функционал. Поставить плагин можно следующим образом:

$ helm plugin install https://github.com/technosophos/helm-template

Установщик позволяет устанавливать плагины и с локальной папки или заархирвированного архива по УРЛу или локальной папке.

Можно писать свои плагины, но если знаешь GO. У меня пока нет времени на его изучение, хотя и хочу!

Работа с Role-based Access Control в Helm

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

Автодополнение команд в Helm

Я нашел команду которая генерирует функции для SH/BASH оболочек. Я придумал следующее решение:

$ helm completion bash >> ~/.bash_helm

После чего, открываем файл:

$ vim ~/.bashrc

И пропишем:

if [ -f $HOME/.bash_helm ]; then
    . $HOME/.bash_helm
fi

Сохраняем и перечитаем файл:

$ . ~/.bashrc

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

$ source <(helm completion bash)

PS:  Для миникуба имеется похожее решение!

Больше полезностей будет после того, как я найду что-то полезное. Вот и все, статья «Установка Helm в Unix/Linux» завершена.

Работа с логами (Logs) в Docker

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

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

Установка Docker на Debian/Ubuntu

Установка Docker на CentOS/RedHat/Fedora

Установка docker-compose в Unix/Linux

Запуск docker контейнеров в Unix/Linux

Установка docker machine в Unix/Linux

Настройка docker swarm кластера в Unix/Linux

Запуск GUI-приложения в Docker

Запустить bash/SSH в контейнере с Docker

Создание base image для docker в Unix/Linux

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

Работа с сетью (Networking) в Docker

Работа с томами (Volumes) в Docker

И так, приступим.

Работа с логами (Logs) в Docker

-=== СПОСОБ 1 ===-

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

$ docker logs $(docker ps -aql)

Version:    v0.4.9
Git commit: c4de4ad0
OS/Arch:    linux/amd64
Built:      Wed Aug 29 12:32:14 2018
time="2018-10-31T10:58:45Z" level=info msg="Controller ready"

Или если задали контейнер_нейм:

$ docker logs vault

-=== СПОСОБ 2 ===-

Логи монтируются на хостевую машину, по этому гегко понять где лежат логи:

$ docker inspect vault | grep -E "LogPath"
        "LogPath": "/var/lib/docker/containers/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b-json.log",

И после чего, выполняем:

$ cat /var/lib/docker/containers/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b/4e65e9b0f1412af155e30d0c50c52933d989c08346d9405e75c5945b53182b3b-json.log

-=== СПОСОБ 3 ===-

Иногда бывает так, что приложенько не умеет выводить логи. Рассмотрим наглядный пример. Запустим контейнер:#

$ docker run -d -P myhttpd:latest
791c65b5aed05a11a40a953779675b5b94d090e691730c5c0bceaa33143fcbc4

Пробуем поулчить логи:

$ docker logs $(docker ps -lq)
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.17. Set the 'ServerName' directive globally to suppress this message

Как видно с вывода, докер не может считать логи с контейнера. Первое что приходит в голову, — это не рабочий контейнер, да? Но пробуем получить данные:

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
my httpd container

Этим самым, видно что контейнер работает, но все еще не может отдавать логи.

Делов в том, что логи для Nginx лежат:

$ docker run nginx ls -l /var/log/nginx
total 0
lrwxrwxrwx 1 root root 11 Oct 2 19:20   access.log  -> /dev/stdout     
lrwxrwxrwx 1 root root 11 Oct 2 19:20   error.log -> /dev/stderr

# docker run httpd cat conf/httpd.conf | egrep '^ *(Error|Custom)Log'
ErrorLog /proc/self/fd/2
   CustomLog /proc/self/fd/1 common

FROM centos
LABEL maintainer="Vitaliy Natarov"
RUN yum install -y httpd web-assets-httpd && yum clean all
RUN echo "logs are sending to stdout" > /var/www/html/index.html

RUN ln -s /dev/stdout /var/log/httpd/access_log && \ 
    ln -s /dev/stderr /var/log/httpd/error_log

EXPOSE 80 
CMD httpd -DFOREGROUND

$ docker build -t myhttpd:2.0 .

$ docker run -d -P myhttpd:2.0
1b0c3a82d0687519ffcd2ee06d345a4d3ad8d475dc0d7710fb279bdd836e5e88

$ docker logs $(docker ps -lq)

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.17. Set the 'ServerName' directive globally to suppress this message

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
logs are sending to stdout

$ docker logs $(docker ps -lq)
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using
172.17.0.18. Set the 'ServerName' directive globally to suppress this message
172.17.0.1 - - [29/Jul/2018:22:07:24 +0000] "GET / HTTP/1.1" 200 19 "-" "curl/7.29.0"

Настройка  Log Driver

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

$ docker run -d -P --name=myhttpd --log-driver=journald myhttpd:2.0 
5748f3078b647c43a335bdc1f8bc7c8d9db31a491e635effd58b31b1429c8ee7

Проверим что вышло:

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
logs are sending to stdout

Получите log-и контейнера через journald ( с указанием CONTAINER_NAME), например:

# journalctl -b CONTAINER_NAME=myhttpd
-- Logs begin at Sat 2018-07-28 19:14:07 BST, end at Sun 2018-07-29 23:19:52 BST. --
Jul 29 23:19:29 localhost.localdomain 5748f3078b64[2806]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.
Jul 29 23:19:50 localhost.localdomain 5748f3078b64[2806]: 172.17.0.1 - - [29/Jul/2018:22:19:50 +0000] "GET / HTTP/1.1" 200 19 "-" "curl/7.29.0"

Запускаем кнтейнер с log-driver-ом и log-tag-ом:

$ docker run -d -P --log-driver=journald \
--log-opt tag=myhttpd \
myhttpd:latest
0555d7a41ab6af098dfea296e2fa7b4f1c6b73424e2156c387930b13bfcefb24

Чекаем:

$ curl localhost:$(docker port $(docker ps -lq) | cut -d: -f2)
   logs are sending to stdout

С такой командой, теперь можно получить логи через указанный тег:

$ journalctl -b CONTAINER_TAG=myhttpd

Поддерживаемые Log Driver-ы:

• none — Логи не доступны для контейнера, и логи самого докера не возвращают никакого вывода.
• json-file- Log-и отформатированы как JSON. Данный драйвер используется по умолчанию в Docker.
• syslog — Записывает логи в syslog. Демон syslog должен быть запущен на самом хосте.
• journald — Записывает логи в journald. Демон journald должен быть запущен на самом хосте.
• gelf — Записывает сообщения в Graylog (GELF) или Logstash.
• fluentd — Записывает сообщения на fluentd (forward input). Демон fluentd должен быть запущен на самом хосте.
• awslogs- Записывает сообщения в Amazon CloudWatch.
• splunk — Записывает сообщения в splunk с помощью сборщика HTTP событий (HTTP Event Collector).
• gcplogs — Записывает сообщения в Google Cloud Platform (GCP).
• logentries — Записывает сообщения в Rapid7 Logentries.

Проверим что используется поумолчанию:

$ docker info --format '{{.LoggingDriver}}'
json-file

Меняем на нужный:

# cat << EOF > /etc/docker/daemon.json {
"log-driver": "journald" }
EOF

Перезапустим сервисы:

# systemctl daemon-reload && systemctl restart docker.service

Проверяем, изменилось ли у нас что-то:

$ docker info --format '{{.LoggingDriver}}'
journald

Можно запустить контейнер:

$ docker run -d -P --name=myweb --log-opt tag=myweb_tag myhttpd:2.0

Проверим логи одним из способов:

$ journalctl -b CONTAINER_NAME=myweb
$ journalctl -b CONTAINER_TAG=myweb_tag

Вот и все, статья «Работа с логами (Logs) в Docker» завершена.

Работа с томами (Volumes) в Docker

Volumes — являются механизмом для сохранения данных, создаваемых и используемых Docker контейнерами (с хостевой машины на контейнер).

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

Установка Docker на Debian/Ubuntu

Установка Docker на CentOS/RedHat/Fedora

Установка docker-compose в Unix/Linux

Запуск docker контейнеров в Unix/Linux

Установка docker machine в Unix/Linux

Настройка docker swarm кластера в Unix/Linux

Запуск GUI-приложения в Docker

Запустить bash/SSH в контейнере с Docker

Создание base image для docker в Unix/Linux

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

Работа с сетью (Networking) в Docker

И так, приступим.

Работа с томами (Volumes) в Docker

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

Создание Volumes в Docker

Чтобы создать Volume, выполните:

$ docker volume create --name http-custom-data
http-custom-data

Проверим что имеется в докере:

$ docker volume ls

Или вывести только необходимый:

$ docker volume ls | grep http-custom-data
local http-custom-data

Получим подробную инфу:

$ docker volume inspect http-custom-data

my custom page from Volume

$ cp index.html /var/lib/docker/volumes/http-custom-data/_data/

$ ls -l /var/lib/docker/volumes/http-custom-data/_data/
total 4
-rw-r--r-- 1 root root 28 Oct 11 20:40 index.html

$ docker run -d -P -v http-custom-data:/usr/share/nginx/html nginx 
b94feb29c143eea7900965706447151e96df86539312bdcea79b42952bae701a

$ docker port $(docker ps -lq)

80/tcp -> 0.0.0.0:32769

# curl 127.0.0.1:32769
my custom page from Volume

$ docker volume create --driver local \ --opt type=tmpfs \
--opt device=tmpfs \
--opt o=size=100m,uid=1000 \
foo

$ docker volume create \
--driver local \ 
--opt type=btrfs \
--opt device=/dev/sda2 \
foo

$ docker volume create \
--driver local \ 
--opt type=nfs \
--opt o=addr=192.168.1.1,rw \
--opt device=:/path/to/dir \
foo

Монтирование Volumes  с хостевой машины в контейнер.

Добавление Volum-ов  в контейнер(ы)  являются хорошим решением т.к при завершении жизни контейнера все ваши данные будут утеряны. Если ваш контейнер генерирует непостоянные данные, рассмотрите возможность использования монтирования tmpfs, чтобы избежать постоянного хранения данных в любом месте и увеличить производительность контейнера, избегая записи на перезаписываемый слой контейнера.

Рассмотрим пример:

$ docker run -d -p 127.0.0.1:8080:80 -v $(pwd):/var/www/html:ro httpd

Или вот еще примеры:

$ docker run --rm -v $(pwd):$(pwd) -w $(pwd) maven:3.3-jdk-8 clean package
$ docker run -d -v /var/log/httpd:/var/log/httpd httpd
$ docker run -d -v /var/log/tomcat:/usr/local/tomcat/logs tomcat
$ docker run -d -v /data:/etc/mongo mongo

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

Ограничения монтирования tmpfs:

• Вы не можете шарить данные монтированием tmpfs между контейнерами.
• Эта функция доступна только в том случае, если вы используете Docker в Linux.

Пример запуска:

$ docker run -d -ti -p127.0.0.1:8282:8200 --name=vault_test --mount type=tmpfs,destination=/tmp vault:0.11.4

Выглядит это так:

Case #1. VOLUME в Dockerfile

Создадим докерфайл выглядит:

FROM nginx
RUN echo "default page" > /usr/share/nginx/html/index.html VOLUME /usr/share/nginx/html/

Соберем:

$ docker build -t nginx_v:1 .
...
Successfully built efdfe29e01fd Successfully tagged nginx_v:1

$ docker run -d -p80:80 nginx_v:1
$ curl localhost
default page

$ docker exec $(docker ps -lq) \
sh -c 'echo changed page > /usr/share/nginx/html/index.html'
$ curl localhost
changed page

$ docker stop $(docker ps -lq)

$ docker inspect $(docker ps -lqa) | jq '.[]|.Mounts'
[
{
"Type": "volume",
"Name": "395c2b4639c0a577ff25b379adc201e77a1cedbc5d50e91150149e1f51191182",
"Destination": "/usr/share/nginx/html", "Driver": "local",
"Mode": "",
"RW": true,
"Source": "/
var/lib/docker/volumes/395c2b4639c0...f51191182/_data",
"Propagation": "" }
]

$ cat /var/lib/docker/volumes/395c2b4639c0a577ff25b379adc201e77a1cedbc5d50e91150149e1f51191182/_data/index.html

changed page

$ docker rm $(docker ps -lqa)

$ cat /var/lib/docker/volumes/395c2b4639c0a577ff25b379adc201e77a1cedbc5d50e91150149e1f51191182/_data/index.html

changed page

$docker run -d -p 80:80 -v /usr/share/nginx/html nginx
$ curl localhost
...
<title>Welcome to nginx!</title>
...

$ docker inspect $(docker ps -lqa) | jq -r '.[]|.Mounts[] | .Source'
/var/lib/docker/volumes/b6400a50ad0a0e8f11fa962cb99e7d2e425ac1654c4e4ea1376ae61a05e5dbc8/_data

$ echo changed > $(docker inspect $(docker ps -lqa) | jq -r '.[]|.Mounts[] | .Source')/index.html
$ curl localhost
changed

$ docker run -d -v /usr/share/nginx/html --name c1 nginx
$ echo changed > $(docker inspect c1 | jq -r '.[]|.Mounts[] | .Source')/index.html

$ docker run --volumes-from c1 busybox cat /usr/share/nginx/html/index.html
changed

Изменить storage driver для docker в Linux

Проверим что имеется:

$ docker info | egrep "(Cgroup|Storage) Driver"
Storage Driver: overlay2
Cgroup Driver: cgroupfs

Можно выполнить настройку:

$ cat << EOF > /etc/docker/daemon.json {
"exec-opts": [ "native.cgroupdriver=systemd"
],
"storage-driver": "devicemapper" }
EOF

# systemctl daemon-reload
# systemctl restart docker.service

# docker info | egrep "(Cgroup|Storage) Driver" 
Storage Driver: devicemapper
Cgroup Driver: systemd

Изменить storage driver для docker в Mac OS X

Проверим что имеется:

$ docker info | egrep "(Cgroup|Storage) Driver"
Storage Driver: overlay2
Cgroup Driver: cgroupfs

Я использую docker edge  и по этому, приведу наглядный пример того, как можно поменять сторедж. Запускаем docker, переходим в «Preferences»:

Переходим во вкладку «Daemon». И во вкладке «Advanced» прописываем нужный сторедж, например:

После добавляения:

{
  "debug" : true,
  "storage-driver" : "overlay2",
  "experimental" : true
}

Жмакаем на «Apply & Restart». Ждем пока докер перезапустится и можно проверить что вышло:

$ docker info | grep -E "Storage Driver"
Storage Driver: overlay2

Как видно с вывода — все работает.

У меня все, статья «Работа с томами (Volumes) в Docker» завершена.

Работа с сетью (Networking) в Docker

Я довольно давно работаю с docker,  не все время, а переодически, но тем-не-менее я проникся докер технологией. Порой не было времени освоить\ познать глубины докера и написать статью для заметок. Сейчас много чего изменилось, у меня появилось желание и время, по этому — я могу рассказать о «Работа с сетью (Networking) в Docker».

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

Установка Docker на Debian/Ubuntu

Установка Docker на CentOS/RedHat/Fedora

Установка docker-compose в Unix/Linux

Запуск docker контейнеров в Unix/Linux

Установка docker machine в Unix/Linux

Настройка docker swarm кластера в Unix/Linux

Запуск GUI-приложения в Docker

Запустить bash/SSH в контейнере с Docker

Создание base image для docker в Unix/Linux

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

И так, приступим.

Работа с сетью (Networking) в Docker

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

• bridge: Мост, — это сетевой драйвер по умолчанию. Бридж сеть используется, когда ваши приложения запускаются в автономных контейнерах, которые должны взаимодействовать между собой (Наглядный пример Nginx + MySQL).
• host:  Хост, — это сетевой драйвер для автономных контейнеров (удаленная сетевая изоляция между контейнером и Docker хостом). Данный драйвер доступен только для docker-swarm с поддержкой Docker 17.06 и выше.
• overlay/overlay2: Оверлей (Наложенная сеть), — это сетевой драйвер для соединения несколько демонов Docker между собой и которые позволяют  docker-swarm службам взаимодействовать друг с другом. Вы также можете использовать оверлейные сети для облегчения связи между docker-swarm и автономным контейнером или между двумя отдельными контейнерами на разных Docker демонах. Эта стратегия устраняет необходимость выполнения маршрутизации на уровне ОС между этими контейнерами.
• macvlan: Маквлан,- это сетевой драйвер, который позволяют назначать MAC-адрес контейнеру, делая его отображаемым как физическое устройство в вашей сети. Docker демон направляет трафик на контейнеры по их MAC-адресам. Использование macvlan драйвера иногда является лучшим выбором при работе с устаревшими приложениями, которые ожидают, что они будут напрямую подключены к физической сети.
• none: Нон,- это сетевой драйвер, который умеет отключать всю сеть для контейнеров. Обычно используется в сочетании с пользовательским сетевым драйвером.
• Network plugins: Вы можете установить и использовать сторонние сетевые плагины с Docker контейнерами. Эти плагины доступны в Docker Store или у сторонних поставщиков услуг.

Где и что лучше использовать?

• Мост (bridge) лучше всего использовать для связи  нескольких контейнеров на одном и том же Docker хосте. Можно юзать docker-compose и выберать даную сеть для такой связки.
• Хост (host) сети лучше всего юзать, когда сетевой стек не должен быть изолирован от хоста Docker, но вы хотите, чтобы другие аспекты контейнера были изолированы.
• Овердейная сеть (overlay/overlay2) или наложение сетей лучше всего заюзать, когда вам нужны контейнеры, работающие на разных Docker хостах для связи, или, когда несколько приложений работают вместе, используя docker-swarm.
• Маквлан (macvlan) сети лучше всего использовать, когда вы переходите с VM/дедикейта  на контейнеры или хотите, чтобы ваши контейнеры выглядели как физические хосты в вашей сети, каждый с уникальным MAC-адресом.
• Сторонние сетевые плагины позволяют интегрировать Docker со специализированными сетевыми стеками.

Просмотреть Network в Docker

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

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
6df045e07b11        bridge              bridge              local
9d45c14e604a        host                host                local
b285e48f2c94        none                null                local

Где:

• NETWORK ID —  При создании сети, ей присваивается ID. Так это собственно индификатор сети.
• NAME — Имя сети. Можно задать произвольное имя.
• DRIVER — Используемый драйвер для созданной сети.
• SCOPE — Где используется.

Если посмотреть на поле «DRIVER»,  то можно понять что я использую стандартную сеть, которую предоставляет сам докер.

Создать Network в Docker

Давайте создадим сеть, самый простой способ это:

$ docker network create bridge-network

c8668b3fc7f6ac9d8694a34d225327f9abb1d195c9757966919ed4adf9b35cea

Или:

$ docker network create --driver=bridge bridge-network

Вы можете создавать bridge, overlay, host, none или кастомный network-инг. По дефолту, — создается мост. Проверяем что вышло:

$ docker network ls

NETWORK ID          NAME                DRIVER              SCOPE
6df045e07b11        bridge              bridge              local
9d45c14e604a        host                host                local
c8668b3fc7f6        bridge-network      bridge              local
b285e48f2c94        none                null                local

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

$ docker network create -d overlay my-multihost-network

Или:

$ docker network create --driver overlay overlay_network

Можно создать macvlan сеть, например:

$ docker network create -d macvlan \
 >   --subnet=172.16.86.0/24 \
 >   --gateway=172.16.86.1 \
 >   -o parent=eth0 \
 >   my-macvlan-net
7ca5727963f953b669da216ddaf42143df54efb31464fa8b46eda9edefa45000

Еще один пример создания сети:

$ docker network create --subnet 10.1.0.0/16 --gateway=10.1.0.1 --ip-range 10.1.4.0/24 --driver=bridge --label=host4networks brifge04
233fa875d361ac26951c0e62d4c406b36e90835eea3a2fba4186df987b3037c9

Проверим созданную сеть на примере, какого-то контейнера:

$ docker run -it --name=test_brifge04 --net brifge04 centos:centos7 /bin/bash

PS: Если нужно, то контейнеру можно выделить статик ИП:

$ docker run -it --name=test_brifge04_2 --net brifge04 --ip=10.1.4.100 centos:centos7 /bin/bash

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

$ docker network create --help

Usage:	docker network create [OPTIONS] NETWORK

Create a network

Options:
      --attachable           Enable manual container attachment
      --aux-address map      Auxiliary IPv4 or IPv6 addresses used by Network driver (default map[])
      --config-from string   The network from which copying the configuration
      --config-only          Create a configuration only network
  -d, --driver string        Driver to manage the Network (default "bridge")
      --gateway strings      IPv4 or IPv6 Gateway for the master subnet
      --ingress              Create swarm routing-mesh network
      --internal             Restrict external access to the network
      --ip-range strings     Allocate container ip from a sub-range
      --ipam-driver string   IP Address Management Driver (default "default")
      --ipam-opt map         Set IPAM driver specific options (default map[])
      --ipv6                 Enable IPv6 networking
      --label list           Set metadata on a network
  -o, --opt map              Set driver specific options (default map[])
      --scope string         Control the network's scope
      --subnet strings       Subnet in CIDR format that represents a network segment

Идем дальше.

Подключить/Отключить контейнер(ы) к/от сети в Docker

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

$ docker network connect YOUR_NETWORK YOUR_CONTAINER

Где:

• YOUR_NETWORK — Сеть.
• YOUR_CONTAINER — Контейнер.

Для отключения служит обратная команда:

$ docker network disconnect YOUR_NETWORK YOUR_CONTAINER

Где:

• YOUR_NETWORK — Сеть.
• YOUR_CONTAINER — Контейнер.

Идем далее.

Инспектор Network в Docker

Можно получить подробную информацию о той или иной сети, например:

$ docker network inspect bridge-network
[
    {
        "Name": "bridge-network",
        "Id": "c8668b3fc7f6ac9d8694a34d225327f9abb1d195c9757966919ed4adf9b35cea",
        "Created": "2018-10-19T08:24:28.511405837Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

Довольно много полезной информации можно получить из данной команды.

Так же, можно получить инфу со следующей команды:

$ docker info

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

$ docker info --format 'table {{.Plugins.Volume}} {{.Plugins.Network}}'
table [local] [bridge host ipvlan macvlan null overlay]

Удаление Network в Docker

Для удаления сети, используйте:

$ docker network rm YOUR_NETWORK

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

$ yes|docker network prune

Если появится хороший материал, обязательно добавлю в данную статью. Вот и все, тема «Работа с сетью (Networking) в Docker» подошла к завершению.

Установка Kubernetes кластера в Unix/Linux

Kubernetes (часто так же используется обозначение «K8s», название образовано от греческого κυβερνήτης, — «кормчий»,»рулевой», по русски — Кубернетес или Кубернетис) — открытое программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Оригинальная версия была разработана компанией Google. Впоследствии Kubernetes был передан под управление Cloud Native Computing Foundation. Предназначение Kubernetes — предоставить «платформу для автоматического развёртывания, масштабирования, управления приложениями на кластерах или отдельных хостах». Кубернетис поддерживает различные технологии контейнеризации, включая Docker, VMWare и ряд других.

Kenernetes используется фондом Wikimedia Foundation, инфраструктура которого мигрировала на это приложение с самостоятельно разработанного ПО для организации кластеров.

Установка Kubernetes кластера в Unix/Linux

Я рассказывал об установке kubernetes-а ранее в моей статье, — Установка Kubernetes в Unix/Linux. По этому — я немного опущу установку ПО и расскажу как можно собрать полноценный кластер с «блэкджеком и куртизанками», т.е — собрать все воедино. Добавлять автоматически ноды, мониторить их и так же — выполнять деплой приложений, скейлинг в зависимости от нужд.

И так дано:

• 192.168.13.219 — Нода kubernetes-master-1 на CentOS 7.
• 192.168.13.230 — Нода kubernetes-worker-1 наDebian 8.
• 192.168.13.147 — Нода kubernetes-worker-2 на Debian 8.

Кластерная диаграмма  кубернетес кластера, выглядит следующим образом:

• Мастер отвечает за управление кластером. Master узлы будут координировать всю деятельность, происходящую в вашем кластере, например, приложения для планирования, сохранение желаемого состояния, масштабирование приложений и обновление апликейщенов.
• Узел (node) представляет собой виртуальную машину или физический компьютер, который используется в качестве рабочего компьютера в кластере Kubernetes. Каждый узел из кластера управляется мастером. На типичном узле вы будете иметь инструменты для обработки операций с контейнерами (например, Docker, rkt) и Kubelet, агента для управления узлом. Кластер Kubernetes, который обрабатывает ПРОД, должен иметь минимум три узла в кластере.

Когда мы развертываем приложения на Kubernetes, мы говорим мастеру, чтобы он запускал контейнеры и планировал их запуск на других нодах. Связь между мстером и воркерами(нодами) осуществляется через API — мастером. Тот же API доступен для пользователей, чтобы облегчить взаимодействие с кластером.

Хватит теории, перейдем к установке и настройке самого кластера!

Установка kubernetes-master-1 на CentOS 7

Установлю хостнейм:

# hostnamectl set-hostname kubernetes-master-1

Это не столь важно, но для примера — будет красиво!

Т.к у меня нет DNS-сервера (я строю кластер локально, на виртуальных машинах), то нужно прописать:

# vim /etc/hosts

Следующее:

192.168.13.219 kubernetes-master-1
192.168.13.233 kubernetes-worker-1
192.168.13.234 kubernetes-worker-2

Это поможет резолвить ноды между собой.

Обновлю ОС:

# yum update -y && yum upgrade -y

Не забываем выключить SELinux,  а то он может наломать вам дров:

# setenforce 0 && sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

Как вы знаете, в centOS 7 имеется firewalld и по этому — стоит пробрасывать правила (но в моем случае — нету смысла) или просто выключить его:

# systemctl stop firewalld && systemctl disable firewalld

Добавим репозиторий с kubernetes:

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

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

# yum install docker kubectl kubeadm etcd ebtables ethtool -y

Добавялем докер-службу в автозагрузку ОС и запускаем сервис:

# systemctl enable docker && systemctl restart docker

Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure net.bridge.bridge-nf-call-iptables is set to 1 in your sysctl config, e.g.

# cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

и применяем:

# sysctl --system

Насчет etcd, я не уверен что нужно сувать его в автозагрузку ОС. Но можно это сделать вот так:

# systemctl enable etcd && systemctl restart etcd

Инициализируем мастер:

# kubeadm init --ignore-preflight-errors=all --pod-network-cidr=10.244.0.0/16

Где:

• kubeadm init — Инициализируем кубернетес.
• —ignore-preflight-errors=all — Скипаю все ошибки (но лучше не использовать этот параметр если не уверены).
• —pod-network-cidr=10.244.0.0/16 — Задаем подсеть для будущего кубо-кластера (не обязательная опция).
• —apiserver-advertise-address=192.168.13.231 — Можно задать данный параметр для установки IP адреса самого API сервера (не обязательная опция).
• —kubernetes-version $(kubeadm version -o short) — Чтобы задать версию кубика (не обязательная опция).
• —token=YOUR_TOKEN — Используется чтобы задать токен (не обязательная опция).

Добавялем кубернетес-службу в автозагрузку ОС и запускаем сервис:

# systemctl enable kubelet

Я не буду добавлять пользователя для кубика, буду использовать — root. Вносим изменения небольшие:

# mkdir -p $HOME/.kube
# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# chown $(id -u):$(id -g) $HOME/.kube/config

Так же, незабываем сохранить команду для добавления нод в мастер, у меня это:

# kubeadm join --token 86669e.c66ab92be6dc5817 192.168.13.219:6443 --discovery-token-ca-cert-hash sha256:f8905cc439b0498eeb3a0de4bf7937640c96cb7063a2bc99f917433a994c4559

Смотрим что вышло:

# kubectl get nodes
NAME                  STATUS     ROLES     AGE       VERSION
kubernetes-master-1   NotReady   master    4m        v1.9.3

PS: Можно получить следующую ошибку:

Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

Решил:

# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && chown $(id -u):$(id -g) $HOME/.kube/config

Как видим, у меня — уже просетапался кубик-мастер нода. Но статус не готов, смотрим что не так:

# kubectl get pods --all-namespaces

NAMESPACE     NAME                                          READY     STATUS    RESTARTS   AGE
kube-system   etcd-kubernetes-master-1                      1/1       Running   0          27m
kube-system   kube-apiserver-kubernetes-master-1            1/1       Running   0          27m
kube-system   kube-controller-manager-kubernetes-master-1   1/1       Running   0          28m
kube-system   kube-dns-6f4fd4bdf-rtkjt                      0/3       Pending   0          28m
kube-system   kube-proxy-vs44m                              1/1       Running   0          28m
kube-system   kube-scheduler-kubernetes-master-1            1/1       Running   0          27m

Такс, нет DNS резолвера, — фиксаем:

# export kubever=$(kubectl version | base64 | tr -d '\n')
# kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
serviceaccount "weave-net" created
clusterrole "weave-net" created
clusterrolebinding "weave-net" created
daemonset "weave-net" created

Различные сети поддерживаются в k8s и зависят от выбора пользователя. Создание сети, занимает определенное время (пару минут точно), через время — проверяем:

[root@kubernetes-master-1 ~]# kubectl get nodes && kubectl  get pods --all-namespaces
NAME                  STATUS    ROLES     AGE       VERSION
kubernetes-master-1   Ready     master    33m       v1.9.3
NAMESPACE     NAME                                          READY     STATUS              RESTARTS   AGE
kube-system   etcd-kubernetes-master-1                      1/1       Running             0          32m
kube-system   kube-apiserver-kubernetes-master-1            1/1       Running             0          32m
kube-system   kube-controller-manager-kubernetes-master-1   1/1       Running             0          32m
kube-system   kube-dns-6f4fd4bdf-rtkjt                      0/3       ContainerCreating   0          32m
kube-system   kube-proxy-vs44m                              1/1       Running             0          32m
kube-system   kube-scheduler-kubernetes-master-1            1/1       Running             0          32m
kube-system   weave-net-pzpxk                               2/2       Running             0          45s
[root@kubernetes-master-1 ~]#

Идем дальше — необходимо установить и добавить воркеры в созданный мастер!

Установка kubernetes-worker-1 на Debian 8

Установлю хостнейм:

# hostname kubernetes-worker-1

Это не столь важно, но для примера — будет красиво!

Т.к у меня нет DNS-сервера (я строю кластер локально, на виртуальных машинах), то нужно прописать:

# vim /etc/hosts

Следующее:

192.168.13.219 kubernetes-master-1
192.168.13.233 kubernetes-worker-1
192.168.13.234 kubernetes-worker-2

Это поможет резолвить ноды между собой.

Ставим нужные зависимости:

# apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common

Устанавливаем докер:

# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
add-apt-repository \
"deb https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \
$(lsb_release -cs) \
stable"

Этой командой, добавляем репку, и для установки — выполняем:

# apt-get update && apt-get install -y docker-ce=$(apt-cache madison docker-ce | grep 17.03 | head -1 | awk '{print $3}')

Добавляем докер в автозагрузку ОС, запускаем его и смотрим статус:

# systemctl start docker && systemctl enable docker && systemctl status docker

Добавляем ключ:

# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

Прописываем репо-лист:

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

Сейчас, ставим кубик:

# apt-get update && apt-get install -y kubelet kubeadm kubectl

Добавляем kubelet в автозагрузку ОС, запускаем его и смотрим статус:

# systemctl start kubelet && systemctl enable kubelet && systemctl status kubelet

Все готово, можно добавлять ноду в кластер:

# kubeadm join --token c4de10.ff1831543e2e223a 192.168.13.219:6443 --discovery-token-ca-cert-hash sha256:f75e564824bb87a906a83f11fabc74b31c759a206dae75401448980e64d0953e

Где:

• kubeadm join — Команда для добавления узлов к мастеру.
• —token c4de10.ff1831543e2e223a — Токен для добавления.
• 192.168.13.219:6443 — Хост и порт от мастер-ноды.
• —discovery-token-ca-cert-hash sha256:f75e564824bb87a906a83f11fabc74b31c759a206dae75401448980e64d0953e — Дискавер токен.
• —discovery-token-unsafe-skip-ca-verification — Можно использовать данную опцию для использывания обхода проверки токена обнаружения. Поскольку этот токен генерируется динамически, мы не могли включить его в действия. При создании ПРОД машин, укажите токен, предоставленный kubeadm init.

Получил ошибку:

CGROUPS_MEMORY: missing
	[WARNING FileExisting-crictl]: crictl not found in system path
[preflight] Some fatal errors occurred:
	[ERROR SystemVerification]: missing cgroups: memory
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`

Фиксим так, для начала — добавляем:

# echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab

Потом, открываем файл:

# vim /etc/default/grub

Находим строку «GRUB_CMDLINE_LINUX» и приводим к виду:

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

Потом, выполняем:

# update-grub && reboot

Немного о cgroups:

Установка cgroups в Unix/Linux

И потом, можно запускать (добавляем воркер к мастеру):

# kubeadm join --token 86669e.c66ab92be6dc5817 192.168.13.219:6443 --discovery-token-ca-cert-hash sha256:f8905cc439b0498eeb3a0de4bf7937640c96cb7063a2bc99f917433a994c4559

На kubernetes-master-1, запускаем:

# kubectl get nodes

Идем дальше — необходимо установить и добавить еще один воркер в созданный мастер!

Установка kubernetes-worker-2 на Debian 8

Аналогичные действия, проделываю и для kubernetes-worker-2. Но только с другим хостнеймом.

Установка kubernetes-worker-n на CenOS 7/Redhat 7

Можно добавлять другие воркеры по аналогии как я описывал ранее для kubernetes-master-1, но без инициализации мастера (что логично, не правдали?).

Деплой Kubernetes кластера в Unix/Linux

Приведу наглядный скриншот того, как выглядит развертывание первого приложения на Kubernetes:

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

Когда все ноды будут добавлены в кластер, должно получится что-то типа:

[root@kubernetes-master-1 ~]# kubectl get nodes
NAME                  STATUS       ROLES     AGE       VERSION
kubernetes-master-1   Ready        master    8m        v1.9.3
kubernetes-worker-1   Ready        <none>    54s       v1.9.3
kubernetes-worker-2   NotReady     <none>    40s       v1.9.3
[root@kubernetes-master-1 ~]#

Как видно что 2-й воркер не успел кодключится еще к кластеру. Через время подключится. Нужно пару минут подождать. Ну, пол работы сделано — осталось научится деплоить, мониторить и может чет еще упустил…

-=== СПОСОБ 1 ===-

Деплоим:

# kubectl create deployment nginx --image=nginx

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

# kubectl get deployments
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     1         1         1            1           41s

Можно получить дополнительную инфу, выполнив:

# kubectl describe deployment nginx

Получаем что-то типа:

Name:                   nginx
Namespace:              default
CreationTimestamp:      Tue, 13 Mar 2018 14:18:29 +0200
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=1
Selector:               app=nginx
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx
    Port:         <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-7d7cbfc4f (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-7d7cbfc4f to 1

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

# kubectl create service nodeport nginx --tcp=80:80

Смотрим статус:

# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        26m
nginx        NodePort    10.103.16.105   <none>        80:32564/TCP   23s

Проверяем работу контейнеров:

# curl kubernetes-worker-1:32564
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cstyle%3E%0A%20%20%20%20body%20%7B%0A%20%20%20%20%20%20%20%20width%3A%2035em%3B%0A%20%20%20%20%20%20%20%20margin%3A%200%20auto%3B%0A%20%20%20%20%20%20%20%20font-family%3A%20Tahoma%2C%20Verdana%2C%20Arial%2C%20sans-serif%3B%0A%20%20%20%20%7D%0A%3C%2Fstyle%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="<style>" title="<style>" />
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

На 2-м воркере:

# curl kubernetes-worker-2:32564

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cstyle%3E%0A%20%20%20%20body%20%7B%0A%20%20%20%20%20%20%20%20width%3A%2035em%3B%0A%20%20%20%20%20%20%20%20margin%3A%200%20auto%3B%0A%20%20%20%20%20%20%20%20font-family%3A%20Tahoma%2C%20Verdana%2C%20Arial%2C%20sans-serif%3B%0A%20%20%20%20%7D%0A%3C%2Fstyle%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="<style>" title="<style>" />
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

На мастере я не запускал воркер, по этому — смысла проверять, — нет.

Можно посмотреть сколько реплик имеется:

[root@kubernetes-master-1 ~]# kubectl get rs

NAME                             DESIRED   CURRENT   READY     AGE
kubernetes-bootcamp-69d869bf78   1         1         1         1d
nginx-7d7cbfc4f                  1         1         1         1d
[root@kubernetes-master-1 ~]#

Чтобы проверить поды, выполняем:

[root@kubernetes-master-1 ~]# kubectl get pods<br>
NAME                                   READY     STATUS    RESTARTS   AGE
kubernetes-bootcamp-69d869bf78-84mvw   1/1       Running   0          1d
nginx-7d7cbfc4f-9s5dd                  1/1       Running   0          1d
[root@kubernetes-master-1 ~]#

Ролбэк Kubernetes кластера в Unix/Linux

Можно выполнять ролбэки:

# kubectl rollout status deployments nginx

Можно проверить хистори всех ролбеков:

[root@kubernetes-master-1 ~]# kubectl rollout history deployment/nginx<br>
deployments "nginx"
REVISION  CHANGE-CAUSE
1         <none>

[root@kubernetes-master-1 ~]#

Теперь я выполню откат к предыдущей версии:

# kubectl rollout undo deployment/nginx

Где:

• —to-revision=2 — С данной опцией, можно задать до какой ревизии делаем откат.

Масштабирование Kubernetes кластера в Unix/Linux

Выполняем масштабирование:

# kubectl scale deployment nginx --replicas=5

deployment "nginx" scaled

Или:

# kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

Проверяем:

# kubectl get deploy

NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1         1         1            1           1d
nginx                 5         5         5            5           1d
[root@kubernetes-master-1 ~]#

Можно выводить много полезной инфы вот так:

# kubectl get deployment,svc,pods,pvc

Все гениальное — просто. Но нужно время чтобы понять.

Мониторинг Kubernetes кластера в Unix/Linux

Дополню когда пойму как можно это сделать автоматически. У меня есть как минимум, 3 способа реализации. Но 1 из них — не очень хорошее решение.

1. Можно заюзать zabbix и просетапать все kubernetes ноды, zabbix-агентами. Это реально будет работать, но как по мне — не ТРУЪ!
2. Можно использовать consul для этого дела — это лучше решение чем заббикс.
3. Так же, можно использовать  prometheus

Но об этом немного позже. Я дополню эту часть, обязательно!

Удаление Kubernetes кластера в Unix/Linux

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

# kubectl delete node your_node_for_delete

Если же нужно удалить вообще все — то обратное действие — установки.

Для удаления деплоймента, используйте:

# kubectl delete deployment nginx

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

Вот и все, статья «Установка Kubernetes кластера в Unix/Linux» завершена.