New Ways to Find Latency in Linux Using Tracing

Ftrace is the official tracer of the Linux kernel.
It originated from the real-time patch (now known as PREEMPT_RT), as developing an operating system for real-time use requires deep insight and transparency of the happenings of the kernel.

Not only was tracing useful for debugging, but it was critical for finding areas in the kernel that was causing unbounded latency. It's no wonder why the ftrace infrastructure has a lot of tooling for seeking out latency.

Ftrace was introduced into mainline Linux in 2008, and several talks have been done on how to utilize its tracing features. But a lot has happened in the past few years that makes the tooling for finding latency much simpler. Other talks at P99 will discuss the new ftrace tracers "osnoise" and "timerlat", but this talk will focus more on the new flexible and dynamic aspects of ftrace that facilitates finding latency issues which are more specific to your needs. Some of this work may still be in a proof of concept stage, but this talk will give you the advantage of knowing what tools will be available to you in the coming year.

FREE Intro to Kubeflow: Fundamentals Training and Certification Prep
Thursday, January 27, 2022
6:00 PM to 7:30 PM MSK

For whom is the “Introduction to Kubeflow” training and certification series for?

Data scientists, machine learning developers, DevOps engineers and infrastructure operators who have little or no experience with Kubeflow and want to build their knowledge step-by-step, plus test their knowledge and earn certificates along the way.

In this free course we'll be covering the following topics:

* The Basics
* Machine Learning Workflows
* Components
* Tools and Add-ons
* Distributions
* Community
* Course Review
* Next Steps

Debug Istio please? What is Isteyo?

Пожаловались, что не работает один endpoint на при обращении в UI к API.
А также не получают никаких ошибок в системе логирования.
Получают ошибку 503 при изменении количества товаров.

По ошибке с присланного скриншота сразу предположил, что запрос до API не доходит, так как это похоже на ошибку на сетевом уровне, а не прикладном.
А значит проблема, предположительно, в Istio. Но я вообще ничего не знаю про Istio... Ладно, поехали!

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

curl -X 'POST' \
  'https://backend.xxx.yyy/api/products/b789f971-a5a9-49a2-bda1-bc6a3d7bd21e/items/' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{"id": "b789f971-a5a9-49a2-bda1-bc6a3d7bd21e","num": 1}'

Все работает! А почему не работает из браузера? Оказывается, чтобы избежать конфигурации CORS, в контейнере с UI работает Node.js сервер, который проксирует запросы в API 🤦‍♂️ Но это тема отдельного поста.

Итого: не работает в сценарии, когда в сессии браузера выполняется POST запрос сам на себя через интернет и получает ошибку 503.

Подключимся к istio-proxy контейнеру: k port-forward frontend 15000:15000
Включим debug-логи: curl -XPOST http://127.0.0.1:15000/logging?level=debug

Выполним парочку запросов, получив ошибку 503, и запомним id в HTTP запросе, чтобы легче было искать место в логах, так как логи траффика довольно обширные. Выгрузим логи в файл для более удобного поиска: k logs frontend -c istio-proxy > /tmp/logs.txt

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

{
    "level": "debug",
    "time": "2022-01-26T18:29:47.345924Z",
    "scope": "envoy client",
    "msg": "[C28620] Error dispatching received data: http/1.1 protocol error: both 'Content-Length' and 'Transfer-Encoding' are set."
}

Погуглив, предлагается решение:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: allow-chunked-length-filter
  namespace: istio-system
spec:
  configPatches:
  - applyTo: CLUSTER
    match:
      context: ANY
    patch:
      operation: MERGE
      value:
        http_protocol_options:
          allow_chunked_length: true

Мой первый коммит в Open Source в kubeflow / pipelines

Не мог выполнить сборку Container image из Dockerfile через Kubeflow pipelines, используя gcr.io/kaniko-project/executor:debug: постоянно возникала ошибка на попытке сменить права на файл

bash
...
INFO[0056] USER bentoml                                 
INFO[0056] cmd: USER                                    
INFO[0056] No files changed in this command, skipping snapshotting. 
INFO[0056] RUN chmod +x ./docker-entrypoint.sh          
INFO[0056] cmd: /bin/sh                                 
INFO[0056] args: [-c chmod +x ./docker-entrypoint.sh]   
INFO[0056] util.Lookup returned: &{Uid:1034 Gid:1034 Username:bentoml Name: HomeDir:/home/bentoml} 
INFO[0056] performing slow lookup of group ids for bentoml 
INFO[0056] Running: [/bin/sh -c chmod +x ./docker-entrypoint.sh] 
error building image: error building stage: failed to execute command: starting command: fork/exec /bin/sh: permission denied
F0121 10:26:36.836271      21 main.go:50] Failed to execute component: exit status 1
Error: exit status 1

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

python
   # swap some lines in dockerfile
    with open(output_tar_path + '/Dockerfile', 'r') as f:
        s = f.readlines()
    df = pd.DataFrame({'Text': s})
    df.Text = df.Text.str.strip()
    first_lines = df.Text.str.contains('USER bentoml')
    second_lines = df.Text.str.contains('RUN chmod') & df.Text.str.contains('./docker-entrypoint.sh')
    df.Text.loc[first_lines], df.Text.loc[second_lines] = df.Text[second_lines].tolist(), df.Text[first_lines].tolist()
    with open(output_tar_path + '/Dockerfile', 'w') as f:
        f.writelines('\n'.join(df.Text.tolist()))

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

Теперь осталось дождаться, пока фиксы будут выпущены вместе с новыми версиями BentoML и Kubeflow pipelines.

Пришлось поменять context: ANY на context: SIDECAR_INBOUND, так перестали работать readiness probes на контейнере с istio-proxy

k describe <POD>

Warning  Unhealthy  5m28s (x13 over 5m52s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 503

k logs <POD> -c istio-proxy

{"level":"warn","time":"2022-01-27T17:01:39.820683Z","msg":"Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 1 rejected; lds updates: 1 successful, 0 rejected"}

EnvoyFilter позволяет управлять конфигурацией получаемой от Istio Pilot.
Выяснилось, что контекст ANY отвечает за роутинг не только на стороне sidecar, но и gateways.
Для корректной работы фронтенда достаточно оказалось SIDECAR_INBOUND, чтобы не аффектило istio-proxy

Пришел коллега, говорит: “выпустили публичные сертификаты с wildcard, давай поменяем в Kubernetes секреты”. Мы поправили kubectl edit secret, а также я обновил сертификаты в Vault, чтобы при деплое обратно не перезаписалось, так как я создание секретов добавил в пайплайн деплоя.
Затем решили обновить сертификат для одного сервиса. После обновления все сломалось, постоянные редиректы с ошибкой 500 о невалидности сертификатов.
Я подумал, вдруг это проблема с сертификатом Ingress Nginx, заменил там тоже и везде все разъезалось.
Как я уже разобрался после, единственный правильный сертификат, с которым все работало в исходной конфигурации, был на Ingress Nginx, который я удалил, не сохранив, будучи уверенным, что он не пригодится.

В итоге оказалось, что в CRT нужно класть целиком цепочку сертификатов в формате

-----BEGIN CERTIFICATE-----
#Your GlobalSign SSL Certificate#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#GlobalSign Intermediate Certificate#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#GlobalSign Root Certificate#
-----END CERTIFICATE-----

https://fastgood.cheap/

Как научить ребенка (заказчика) воспринимать сроки, качество и ресурсы

там это, 🍯 сняли документальное (!) кино про кубурнетис , аж в двух частях:
- https://youtu.be/BE77h7dmoQU
- https://youtu.be/318elIq37PE

из рабочего чата