Page_c76a3fcf

captain — Wed, 06 Jan 2021 16:24:57 +0000

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, , , , /
    # 2. All other resources:
    # p, , , , 

    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 < 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» завершена.

The post Установка ArgoCD в Unix/Linux first appeared on linux-notes.org.

Page_c76a3fcf

captain — Wed, 25 Dec 2019 17:18:01 +0000

Сделаю себе заметку со списком команд для работы с 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  "_d
:smap  y
:smap  x
:imap  pi
:smap  p
:smap  1> 
:smap  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

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

$ kubectl get pod  -o wide

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

$ kubectl get pod  -o yaml

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

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

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

$ kubectl describe pod

Или:

$ kubectl describe pods

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

$ kubectl describe nodes

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

$ 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

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

$ kubectl delete -f ./pod.json

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

$ kubectl delete pods -l name=myLabel

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

$ kubectl -n  delete pod --all

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

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

Идем дальше.

Работа с Deployments в Kubernetes

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

$ kubectl run  --image= --record

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

$ kubectl get deployments

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

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

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

$ kubectl rollout history deployment/

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

$ kubectl rollout undo deployment/ --to-revision=N

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

$ kubectl rollout status -w deployment/

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

$ kubectl scale deployment/ --replicas=

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

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

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

$ kubectl scale --current-replicas=3 --replicas=4 deployment/

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

$ kubectl scale --replicas=5 rc/ rc/ rc/

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

$ 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            443/TCP   28d

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

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

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

$ kubectl expose deployment/ --port=8080 --type=NodePort

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

$ kubectl delete service -l name=myLabel

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

$ kubectl -n  delete service --all

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

Работа с Volumes в Kubernetes

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

$ kubectl get pv

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

$ kubectl get pvc

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

$ kubectl get pv -n  --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 <





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



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



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



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



Работа с ConfigMaps в Kubernetes



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



$ kubectl create configmap  --from-file=config.js



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



$ kubectl get configmap  -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  --port=2368



Идем дальше.



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



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



$ kubectl get hpa



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



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



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



$ kubectl autoscale deployment  --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 



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



$ kubectl logs -l name= 



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



$ kubectl logs  --previous 



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



$ kubectl logs  -c 



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



$ kubectl logs -l name= yourLabel -c 



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



$ kubectl logs -f 



Запускать 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  -i



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



$ kubectl port-forward  5555:6666



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



$ kubectl exec  -- ls / 



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



$ kubectl exec  -c  -- ls / 



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



$ kubectl top pod  --containers



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



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



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



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



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



$ kubectl cordon 



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



$ kubectl drain 



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



$ kubectl uncordon 



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



$ kubectl top node 



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



$ 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  -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  "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"



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



Вот и все, статья «Команды Kubernetes в Unix/Linux» завершена.
The post Команды Kubernetes в Unix/Linux first appeared on linux-notes.org.



Page_c76a3fcf
captain — Mon, 14 Oct 2019 13:09:07 +0000

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 ' 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  --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: [], 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: [], 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» завершена. 
The post Установка minikube в Unix/Linux first appeared on linux-notes.org.


Page_c76a3fcf
captain — Tue, 06 Nov 2018 08:57:35 +0000
Установка 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           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-ы:

Найти готовое решение (готовый чарт) и установить его.
Создать свой 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:       
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:            

Для удаления релиза можно использовать следующую команду:
$ 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» завершена.
The post Установка Helm в Unix/Linux first appeared on linux-notes.org.


Page_c76a3fcf
captain — Wed, 14 Mar 2018 13:45:32 +0000
Установка 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 < /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 < /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 </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            54s       v1.9.3
kubernetes-worker-2   NotReady         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:         
    Environment:  
    Mounts:       
  Volumes:        
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  
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               443/TCP        26m
nginx        NodePort    10.103.16.105           80:32564/TCP   23s

Проверяем работу контейнеров:
# curl kubernetes-worker-1:32564



Welcome to nginx!
" title="