Update openssl, kubectl, k8s

03.linux/10004.openSSL.md

@@ -31,6 +31,11 @@ openssl req -text -in yourdomain.csr -noout -verify
 openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
 ```
 
+Конвертируем CRT в PFX:
+```
+openssl pkcs12 -export -out new-pfx-cert.pfx -inkey private-key.key -in certificate.crt
+```
+
 Информация о сертификате (для файла *.crt):
 ```
 openssl x509 -in certificate.crt -text -noout

03.linux/10008.kubectl.md

@@ -258,6 +258,9 @@ kubectl delete pods,services -l name=myLabel                              # Уд
 kubectl -n my-ns delete pod,svc --all                                     # Удалить все поды и сервисы в пространстве имен my-ns
 ## Удалить все поды, соответствующие pattern1 или pattern2 в awk
 kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod
+
+kubectl delete all -l some-label=some-value                               # Удалить все поды с меткой some-label=some-value
+kubectl delete pod $(kubectl get pod -o=jsonpath='{.items[?(@.status.phase=="Succeeded")].metadata.name}')  # Удалить все пода со статусом "Succeeded"
 ```
 
 ## Работа с запущенными подами ##
@@ -361,6 +364,7 @@ kubectl api-resources --api-group=extensions # Все ресурсы в API-гр
 
 * [Опции kubectl](https://kubernetes.io/ru/docs/reference/kubectl/kubectl/)
 
+* [13 конфигураций Kubernetes, которые ты должен знать в 2k24](https://habr.com/ru/articles/796753/)
 
 
 

03.linux/dod/k8s/10010.status_k8s.md

@@ -0,0 +1,144 @@
+# Проверка состояния кластера kubernetes
+
+### Оцениваем общее состояние ###
+Проверяем, насколько совпадает версия клиента и сервера, чтобы не получить несовместимость функционала при дальнейшей работе:
+
+```
+kubectl version
+```
+
+Дальше смотрим основные ресурсы нашего кластера:
+
+```
+kubectl cluster-info (обращаем внимание на ip-адрес, порт, состояние корднс в кластере)
+kubectl get cs -A (получаем статус основых компонентов k8s)
+```
+Оценим состояние наших нод и подов, их статус. Выполним команды:
+```
+kubectl get nodes -owide
+kubectl get pods -A -owide
+```
+Здесь обращаем внимание на время жизни и количество рестартов подов: частые рестарты могут свидетельствовать о проблемах в кластере.
+
+Посмотрим на события в кластере за последний час:
+```
+kubectl get events -owide
+```
+В выводе этой команды обращаем внимание на то:
+* какие поды разворачивались и когда, 
+* были ли проблемы с хелсчеками, 
+* не заходил ли oom-киллер и т. п.
+
+При установленном metrics-server также можно посмотреть на его нагрузку в кластере:
+```
+kubectl top nodes
+kubectl top pods -A
+```
+
+Оценив общее состояние кластера, перейдем к просмотру состояния всех компонентов: здесь может вскрыться очень-очень много интересного.
+
+Оцениваем состояние компонентов k8s
+Посмотрим на работу сердца нашего кластера – etcd. Для этого обратимся к логам пода (или юнита):
+```
+kubectl logs -n kube-system etcd-cluster-m1 --follow --tail 1000
+```
+
+Нас интересует:
+
+* не отваливаются ли реплики, 
+* нет ли троттлинга, 
+* время сжатия данных. 
+
+Здесь уже могут вскрыться признаки проблем с производительностью дисков и сети.  
+
+Если компоненты k8s стоят на машинах, можно посмотреть логи юнитов:
+```
+journalctl -u etcd -n 1000 --follow
+```
+
+То же самое делаем и с компонентами kubernetes. Cмотрим:
+* логи kube-apiserver, 
+* kube-scheduler, 
+* kube-controller-manager. 
+
+Не забываем заглянуть и в логи kubelet на самих воркерах.
+
+Скорее всего, на этих этапах уже встретятся ошибки. Тут могут вскрыться и признаки проблем с сетью, средой запуска контейнеров, валидностью сертификатов, частой сменой лидеров шедулера и контроллера k8s и т. п. На этом этапе необходимо оценить их критичность и частоту. 
+
+Изучение работы компонентов может занять какое-то время, но в итоге это поможет лучше понять общее состояние кластера.
+Не упускаем из виду и функционирование сети в самом кластере. У нас в кластерах в качестве CNI используется calico, так что покажу на его примере. 
+Смотрим логи с подов calico. Обращаем внимание на частое изменение маршрутов и пересечения имен. 
+
+```
+kubectl logs -n kube-system calico-kube-controllers-755d84984b-qq9t2 --follow --tail 100
+kubectl logs -n kube-system calico-node-pf6sv --follow --tail 1000
+```
+Также можно поставить утилиту calicoctl и быстренько посмотреть состояние с ее помощью. Запустить ее можно через под или исполняемый файл. Главное – обеспечить аналогичную установленной версию calicoctl. 
+
+Устанавливаем нашу версию в кластере:
+```
+kubectl apply -f https://docs.projectcalico.org/archive/v3.19/manifests/calicoctl.yaml 
+kubectl exec -ti -n kube-system calicoctl -- calicoctl get nodes -o wide
+kubectl exec -ti -n kube-system calicoctl -- calicoctl get bgpPeer -o wide
+```
+Или можем использовать ту же утилиту со своей машины:
+```
+calicoctl get nodes 
+calicoctl get BGPpers
+```
+
+Где-нибудь здесь при желании можно измерить скорость сети между самими подами, к примеру, утилитой iperf. В том числе это касается подов, расположенных на разных машинах.
+
+### Тестирование кластера на соответствие требованиям CNCF ###
+Стандарт CNCF позволяет обеспечить ожидаемое поведение от кластера. 
+Определим, имеет ли наш кластер стандартные настройки. Для этого обратимся к утилите Sonobuoy: мы используем ее для тестирования своих сборок k8s.
+
+На данном этапе могут выясниться недостающие параметры запуска компонентов, функциональные проблемы кластера или невозможность обработать действия в самом кластере.
+
+Важно: определяемся с версией, которая поддерживает релиз нашего кластера. В данном случае скачаем последнюю версию программы
+https://github.com/vmware-tanzu/sonobuoy/releases.
+
+Запустим проверку нашего кластера стандартными тестами:
+```
+sonobuoy run
+```
+Если хотим  ожидать завершения, можно использовать ключ --wait. Проверка кластера занимает около полутора часов.
+
+Смотреть прогресс тестирования можно командой:
+```
+sonobuoy status
+```
+
+По завершении скачиваем архив с отчетом и смотрим ошибки:
+```
+results=$(sonobuoy retrieve)
+sonobuoy results $results
+```
+Вот один из примеров того, с чем столкнулись мы:
+```
+[sig-api-machinery] AdmissionWebhook [Privileged:ClusterAdmin] should be able to deny attaching pod [Conformance]
+[sig-api-machinery] AdmissionWebhook [Privileged:ClusterAdmin] should deny crd creation [Conformance]
+[sig-api-machinery] CustomResourcePublishOpenAPI [Privileged:ClusterAdmin] works for CRD with validation schema [Conformance]
+[sig-api-machinery] CustomResourcePublishOpenAPI [Privileged:ClusterAdmin] works for CRD without validation schema [Conformance]
+[sig-cli] Kubectl client Guestbook application should create and stop a working application  [Conformance]
+[sig-network] DNS should provide DNS for pods for Subdomain [Conformance]
+[sig-network] Ingress API should support creating Ingress API operations [Conformance]
+```
+
+Следующей командой можно более подробно посмотреть на проблемы:
+```
+sonobuoy results $results --mode detailed | jq '. | select(.status == "failed") | .details'
+```
+
+Для соответствия рекомендациям нам пришлось поправить параметры запуска компонентов k8s, внести изменения в настройку ingress и API кластера.
+
+После устранения неисправности, чтобы не ждать прохождения полного теста, можно запустить только конкретный:
+```
+sonobuoy run --e2e-focus "Ingress API should support creating Ingress API operations" --e2e-skip "" --wait
+```
+
+---
+
+* [https://habr.com/ru/companies/dataline/articles/598223/](https://habr.com/ru/companies/dataline/articles/598223/)
+
+