Не проходят пробы после включения Istio Ambient

 Возился с переносом наработок по Istio Ambient из GKE (Google Kubernetes Engine) в EKS (Elastic Kubernetes Service) и столкнулся с "отваливающимися" проверками готовности подов в Knative сервисах после включения пространства имён в ambient mesh.

Новый под стартует, но через 30 секунд у него отваливается readiness check без каких либо сообщений в логе пода. Проверил логи ztunnel, но ничего интересного не увидел. Для верности почитал Platform-Specific Prerequisites для EKS но описанный там случай не подходил для моего кластера.

Попробовал искать в сообщениях об ошибках в Istio, но ничего подходящего не нашлось. Потом вспомнил про kubernetes network policy которая есть в этом неймспейсе и после её удаления проверки стали проходить нормально.

Стал искать целенаправленно и натнулся на раздел Ambient, health probes, and Kubernetes NetworkPolicy в документации Istio Ambient и стало ясно чего не хватает.

Пропадают чаты и каналы в Teams

 Сегодня заметил что в настольной версии Teams (версия 25185.410.3812.8024) стал пропадать список чатов и каналов на вкладке "Chat".

 Есть только "Recent", но отсутствуют "Chats" и "Teams and Channels". В браузерной версии это выглядит так

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

Ошибки при установке Istio в GKE

 Если вы ставите Istio в ambient режиме в GKE (Google Kubernetes Engine) кластер и не прочли Platform-Specific Prerequisites, то при установке CNI node agent вы столкнётесь с двумя ошибками.

Первая не даст установить Helm релиз (в событиях будет ошибка):

LAST SEEN   TYPE      REASON                    OBJECT                           MESSAGE
3s          Warning   FailedCreate              daemonset/istio-cni-node         Error creating: insufficient quota to match these scopes: [{PriorityClass In [system-node-critical system-cluster-critical]}]

Это связано с тем что по-умолчанию разрешает использовать priorityClassName: system-node-critical только в пространстве имён "kube-system". Чтобы разрешить использовать его в "istio-system" нужно создать ResourceQuota в соответствующем пространстве имён

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gcp-critical-pods
  namespace: istio-system
spec:
  hard:
    pods: 1000
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
      - system-node-critical

Вторая проблема проявляется как постоянный перезапуск пода istio-cni и в логах будет подсказка как это чинить:

2025-08-15T14:03:48.272826Z     info    controllers     starting        controller=repair pods
2025-08-15T14:03:48.357825Z     info    cni-agent       initialization complete, watching node CNI dir
2025-08-15T14:03:48.358220Z     error   cni-agent       failed file copy of /opt/cni/bin/istio-cni to /host/opt/cni/bin: open /host/opt/cni/bin/istio-cni.tmp.2135482355: read-only file system
2025-08-15T14:03:48.358243Z     warn    hint: some Kubernetes environments require customization of the CNI directory. Ensure you properly set global.platform=<name> during installation
2025-08-15T14:03:48.358311Z     error   cni-agent       installer failed: copy binaries: open /host/opt/cni/bin/istio-cni.tmp.2135482355: read-only file system
2025-08-15T14:03:48.369141Z     info    cni-agent       terminating, but parent DS istio-cni-node is still present, this is an upgrade, leaving plugin in place
2025-08-15T14:03:48.369180Z     info    cni-agent       Ambient node agent shutting down - is upgrade shutdown? true

Для исправления достаточно задать --set global.platform=gke при установке Helm релиза.

Проверка измерений сопротивления в домашних условиях

 Это продолжение точные резисторы для калибровки и неожиданная цена за простую плату - собрал набор сопротивлений (0,1 Ом, 1 Ом, 10 Ом, 100 Ом, 1 кОм, 10 кОм, 100 кОм, 1 МОм, 10 МОм) которыми можно проверить точность показаний сопротивления у измерительных приборов в домашних условиях.

Использованы тонкоплёночные SMD сопротивления от Yageo с точностью 0,1% и ТКС ±25ppm.  Для всех номиналов кроме 1 МОм и 10 МОм итоговая мощность 1,25 Вт.

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

В качестве эталонного измерительного прибора выступил настольный мультиметр Agilent U3402A с использованием четырёхпроводной схемы измерений. В этом режиме его точность измерения сопротивления выше любого другого из моих приборов, но при измерении сопротивлений выше 100 кОм рекомендованы экранированные провода которых у меня нет.

Микрометр 0-25 мм

 Пополнил свой список измерительных инструментов микрометром 0-25 мм с ценой деления 0,01 мм (10 микрон). Этот инструмент был выпущен в 1974 году московским заводом "Калибр" и находится в хорошем состоянии.

Брал его чтобы проверить сечение многожильного провода, но по итогу оказалось что продавец неверно указал информацию о количестве и диаметре жил (в описании товара было указано 7 жил по 0,26 мм, а на самом деле там 12 жил по 0,19 мм).

Микрометр пришёл мне отрегулированным и уверенно становится на ноль если вращать за храповик. На случай если хочется проверить точность микрометра, но нет концевых мер длины, то можно проверить используя щупы для регулировки клапанов (обычно в наборе щупы 0,05 мм - 1 мм).

Wildcard SSL сертификат

Понадобилось сгенерировать wildcard SSL сертификат и раскладывать его по пространствам имён в Kubernetes кластере. Этот сертификат будет использоваться в тестах которые выполняются для набора приложений на каждый запрос на слияние.

В cert-manager настроен ClusterIssuer LE с валидацией через DNS01. Выпуск wildcard сертификата у Let's Encrypt поддерживается только через DNS валидацию и протокол ACMEv2. В примере использован сервис Cloud DNS от Google Cloud Platform.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    email: certificates@example.com
    privateKeySecretRef:
      name: letsencrypt-production
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        cloudDNS:
          project: GCP_PROJECT_ID

Манифест для wildcard сертификата (сам сертификат и ключ будут созданы в пространстве имён cert-manager)

Привилегии приложений в контейнерах

Хорошей практикой является принцип наименьших привилегий (давать только те права которые нужны для выполнения задачи). На практике разработчики зачастую идут путём наименьшего сопротивления и копируют "рецепты" из интернета.

Далее несколько частых случаев с которыми мне доводится сталкиваться и варианты их решения.

Прослушивание портов ниже 1024

Если программа требует повышения привилегий для прослушивания портов 80 и 443 (или любых других до 1024), то можно изменить конфигурацию для прослушивания портов выше 1024 (например 8080 и 8443), а на балансировщике сделать преобразование портов. Если переназначение портов невозможно, то можно воспользоваться Linux capabilities и выдать только CAP_NET_BIND_SERVICE вместо выдачи прав пользователя root.