# .bash_aliases
alias k=kubectl
alias kcd='kubectl config set-context $(kubectl config current-context) --namespace'
alias kcdc="kubectl config view -o jsonpath='{.contexts[].context.namespace}' && echo ''"

Тестирование

Скорость сети

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

Алгоритм проверки: (1) в кластере запускаем под iperf в режиме сервера (2) на клиенте запускаем iperf в режиме клиента.

Для запуска iperf в кластере используем helm-схему https://www.datree.io/helm-chart/iperf3-eugenmayer. Схема создает деплоймент iperf3 и сервис типа NodePort. Это позволяет выполнить проверку скорости с любым узлом кластера в заданной зоне доступности.

helm repo add eugen https://eugenmayer.github.io/helm-charts/
helm install my-iperf3 eugen/iperf3 --version 0.2.0

На стороне клиента устанавливаем iperf3 через пакетный менеджер и запускаем проверку в направлении сервера.

sudo apt install iperf3
iperf3 -c <NODE>:<PORT>
# где NODE - ip-адрес узла кластера
#     PORT - номер порта, который был открыт сервисов iperf3

В примерах используется iperf3 (не iperf). Необходимо использовать одинаковую версию на стороне сервера и клиента, иначе работать не будет.

Kubernetes API

Swagger UI

# --- запускаем прокси
kubectl proxy
# Starting to serve on 127.0.0.1:8001

# --- выгружаем описание API в файлик, напр.
http :8001/openapi/v2 > tmp/k8s-swagger.json

# --- запускаем swagger ui и прокидываем ему этот файл
docker run --rm -it \
    -p 80:8080 \
    -v ~/tmp:/opt/specs \
    -e SWAGGER_JSON=/opt/specs/k8s-swagger.json \
    swaggerapi/swagger-ui
# идем на localhost

Книга рецептов

Конфигурирование сохранения сессий в службах

Лукша. Kubernetes в действии Раздел 5.1.1

# Пример службы с настроенной сохранностью сессий сеанса ClientIP
# Это заставляет служебный прокси перенаправлять все запросы,
# исходящие от того же клиентского IP-адреса на тот же модуль.
# kubectl explain svc.spec.sessionAffinity
apiVersion: v1
  kind: Service
  spec:
    sessionAffinity: ClientIP
...

Создание службы для внешнего сервиса

Лукша. Kubernetes в действии Раздел 5.2.2

Шаг 1. Создание сервиса без селектора модулей

# external-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  ports:
    - port: 80

Шаг 2. Создание ресурса конечных точек для службы

# external-service-endpoints.yaml
apiVersion: v1
kind: Endpoints
metadata:
  # Имя объекта Endpoints должно совпадать с именем службы
  name: external-service
subsets:
  # IP-адреса конечных точек, на которые служба будет перенаправлять подключения
  - addresses:
    - ip: 11.11.11.11
    - ip: 22.22.22.22
  ports:
    - port: 80

TLS and Ingress

Лукша. Kubernetes в действии Раздел 5.4.4

NodePort drawbacks

Some NodePort drawbacks to consider for production environments are:

The scale will be limited by the “nodePort” range number, because only one service per port can be configured.
By default, port range is limited in the rage 30000–32767. High ports usage could be problematic, from security perspective.
By design, NodePort bypasses almost all network security in Kubernetes.
If external load-balancer is in use, the service “Heath Check” will be toward the Node IP, instead directly to the Pod one, which is a poor monitoring solution.
More complex to troubleshoot connectivity issues.

Troubleshooting

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

прежде всего убедитесь, что вы подключаетесь к кластерному IP-адресу службы изнутри кластера, а не извне;

не тратьте времени на пингование IP-адреса службы, чтобы выяснить, доступна ли служба (напомню, что кластерный IP-адрес службы – это виртуальный IP-адрес, и его пингование не сработает);

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

для того чтобы убедиться, что модуль является частью службы, проинспектируйте соответствующий объект Endpoints с помощью команды kubectl get endpoints;

если вы пытаетесь получить доступ к службе через ее полное доменное имя или его часть (например, myservice.mynamespace.svc.cluster.local или myservice.mynamespace ) и это не работает, посмотрите, сможете ли вы обратиться к нему, используя ее кластерный IP-адрес вместо полного доменного имени;

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

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

если вы не можете получить доступ к своему приложению даже через IP-адрес модуля, убедитесь, что ваше приложение не открыто своими портами только к localhost-адресу.

calico

calico/node is not ready: BIRD is not ready: BGP not established with 10.0.0.1

source

The calico/node container may report an “unready” status in Kubernetes with this message. In most cases, this means a particular peer is unreachable in the cluster. Users should ensure BGP connectivity between the two peers is allowed in their environment.

This can also occur when inactive Node resources are configured when using node-to-node mesh. Resolve cases like this by decomissioning the stale nodes.

Lastly this can occur when BGP connections to non-mesh peers go down. If this is a common occurance in your BGP topology, you can disable BIRD readiness checks. See node readiness for more information.## minikube

kubectl

Failed to create pod sandbox

При запуске пода получаем постоянный ContainerCreating

В описании пода постоянно вываливается ошибка:

kubectl describe pod XXX
...
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "xxx" network for pod "xxx": networkPlugin cni failed to set up pod "xxx" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/

Подобная ошибка упоминается здесь

Необходимо установить корректный --pod-network-cidr при инициализации кластера. Если кластер уже запущен, то, по всей видимости, его надо сбросить. На всех узлах кластера выполнить:

sudo kubeadm reset
sudo rm /etc/cni/net.d/*

Далее выполняем:

# --- master
kubeadm init --apiserver-advertise-address=MASTER_IP_OR_HOSTNAME --pod-network-cidr=10.244.0.0/16
# --- nodes
sudo kubeadm join ...
# ... other cluster operations ...

the server could not find the requested resource

После запуска модуля, до него нельзя достучаться.

k get pods
# NAME           READY   STATUS    RESTARTS   AGE
# kubia-manual   1/1     Running   0          20m

k logs kubia-manual
# Error from server (NotFound): the server could not find the requested resource ( pods/log kubia-manual)

k port-forward kubia-manual 8080:8080
# error: error upgrading connection: unable to upgrade connection: pod does not exist

Если запуск кластера осуществляется в Vagrant и VirtualBox, то причиной может быть то, что при запуске используется некорректный eth-интерфейс (см. ссылку). Необходимо для каждого узла задать явно ip-адрес:

# /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
...
Environment="KUBELET_EXTRA_ARGS=--node-ip={{ node_ip }}"