KoolKits-Kubernetes用のOSSデバッグツールキット

KoolKits(K ubernetes t oolkits)は、Kubernetes用の非常に意見が多く、言語固有の、バッテリーを含むデバッグコンテナーイメージです。実際には、これらは、見慣れないシェルでの厳しいデバッグセッション中にスタックした場合に、本番ポッドにインストールしたものです。

背景を簡単に説明するために、これらのコンテナイメージは、インタラクティブなトラブルシューティングのためにエフェメラルコンテナを起動する新しいkubectlデバッグ機能で使用することを目的としていることに注意してください。KoolKitはkubectldebugによってプルされ、ポッド内のコンテナーとしてスピンアップされ、元のコンテナーと同じプロセス名前空間にアクセスする機能を備えています。

通常、本番コンテナはかなりむき出しになっているため、KoolKitを使用すると、本番イメージを最初に作成した人の寛大さ(または不注意)のために残されたものに頼るのではなく、動力工具でトラブルシューティングできます。

各KoolKitのツールは慎重に選択されており、このプロジェクト全体の背後にある動機については、以下で詳しく読むことができます。

良いものを見たいだけなら、GitHubでプロジェクト全体をチェックしてください。

Kubernetesのデバッグは難しい

Kubernetesポッド内で何が起こっているかを理解するのは簡単ではありません。

まず第一に、アプリケーションはもはや単一のエンティティではありません。複数のポッドで構成され、水平スケーリング用に複製され、場合によっては複数のクラスターに分散されます。

さらに、ローカルツール(デバッガーなど)を使用してアプリケーションにアクセスするには、検出やポート転送などの厄介なネットワークの問題に対処する必要があります。これにより、このようなツールの使用が遅くなります。

また、分散システムの世界の最高峰である、実行中のポッドの状態を変更したり、完全に停止したりすると(ブレークポイントを設定する場合など)、システムの他の部分でカスケード障害が発生し、既存の問題が悪化する可能性があります。

KoolKitsの背後にある動機

Lightrunは、Kubernetesを念頭に置いて構築されました。複数のポッド、複数のクラスター、さらには複数のクラウドで作業します。適切なツールを使用してパンチを詰めることは、トラブルシューティング開発者にとって大きな力の源であることを早い段階で理解しました。そして、何らかの形でコミュニティに還元する方法を見つけることができると考えました。それが、私たちがアイデアを思いついた方法です。 KoolKitsの場合。

KoolKitsが非常に役立つ理由を説明するために、少し深く掘り下げてみましょう。

小さなコンテナイメージを作成する必要があるという、よく知られているKubernetesのベストプラクティスがあります。これは、いくつかの異なる理由で理にかなっています。

  1. イメージを構築すると、消費するリソースが少なくなります(別名CI時間)
  2. 画像をプルするのにかかる時間は短くなります(とにかく多くの侵入にお金を払いたい人はいますか?)
  3. スタッフが少ないということは、操作なしのロギングでさえ安全ではなくなった世界で、セキュリティの脆弱性にさらされる表面積が少なくなることを意味します

あまり重労働をせずにそこにたどり着くのに役立つツールもたくさんあります。

  1. AlpineLinuxのベースイメージは非常に小さい
  2. DistroLess Dockerイメージはさらに一歩進んで、ランタイム以外のすべてを削除します
  3. Dockerマルチステージビルドは、シンの最終的な本番イメージの作成に役立ちます

これらのコンテナ内で何が起こっているかをデバッグしようとすると、問題が発生します。小さな本番イメージを使用することで、アプリケーションの問題に頭を悩ませるときに非常に貴重な大量のツールを放棄することになります。

KoolKitを使用することで、高品質のツールを損なうことなく、小さな本番イメージのメリットを享受できます。各KoolKitには、Linuxベースのより一般的なツールのセットに加えて、それが表す特定のランタイム用に厳選されたツールが含まれています。システム。

PS KoolKitsは、kubespynetshootに触発されました。

考慮事項

これらの画像の作成中に行った決定はかなり多くあります。考慮したいくつかの事項を以下に示します。

画像のサイズ

KoolKits Dockerイメージは実行される傾向があります、ええと、かなり大きいです。

KoolKitsは、一度ダウンロードして、クラスターのDockerレジストリーに保持し、その後、コンテナーとしてオンデマンドですぐにスピンアップすることを目的としています。それらは絶え間なく引っ張ることを意図しておらず、そしてそれらはグッズを詰め込むことを意図しているので、これは私たちが耐えることをいとわない副作用です。

Ubuntuベースイメージの使用

本当にスリムなイメージを作成するのが難しい理由の1つは、各KoolKitのベースとして完全なUbuntu20.04システムを使用することを決定したためです。これは主に、クラスター内でローカルにデバッグするのと同じ環境を複製したいという私たちの願望から来ました。

たとえば、これは、作業に慣れている通常のUbuntuパッケージに代わるAlpineの代替品をいじり回さないことを意味します。実際、これは、各KoolKitにAlpineバージョンがないツールを含める方法があることを意味します。

言語バージョンマネージャーの使用

各KoolKitは、言語固有のディストリビューションに依存する代わりに、(可能な限り)言語バージョンマネージャーを使用します。これは、古いランタイムバージョンを簡単にインストールできるようにするため、および必要に応じてランタイムバージョン間で自由に交換できるようにするため(たとえば、特定のランタイムバージョンにのみ存在する特定のバージョンのツールを取得するため)に行われます。

利用可能なKoolKits

リポジトリ内の各フォルダーには、KoolKitの背後にあるDockerfileとデバッグイメージの簡単な説明が含まれています。実際の人々は実際のシェルを必要とするため、すべてのKoolKitsはubuntu:20.04ベースイメージに基づいています。

利用可能なKoolKitsのリスト:

  1. koolkit-jvm – AdoptOpenJDK 17.0.2および関連ツール(バージョン管理を容易にするためのjabbaおよびMaven 3.8.4を含む)
  2. koolkit-node –ノード16.13.1および関連ツール(バージョン管理を容易にするためのnvmを含む)
  3. koolkit-python – Python 3.10.2および関連ツール(バージョン管理を容易にするためのpyenvを含む)

実際に自分でビルドする必要はないことに注意してください。すべてのKoolKitsはDockerHubで公開されており、無料で利用できます。

KoolKitsが登場

このストーリーは、もともとhttps://talktotheduck.dev/introducing-koolkits-oss-debugging-toolkits-for-kubernetesで公開されました

#koolkits #kubernetes 

What is GEEK

Buddha Community

KoolKits-Kubernetes用のOSSデバッグツールキット

KoolKits-Kubernetes用のOSSデバッグツールキット

KoolKits(K ubernetes t oolkits)は、Kubernetes用の非常に意見が多く、言語固有の、バッテリーを含むデバッグコンテナーイメージです。実際には、これらは、見慣れないシェルでの厳しいデバッグセッション中にスタックした場合に、本番ポッドにインストールしたものです。

背景を簡単に説明するために、これらのコンテナイメージは、インタラクティブなトラブルシューティングのためにエフェメラルコンテナを起動する新しいkubectlデバッグ機能で使用することを目的としていることに注意してください。KoolKitはkubectldebugによってプルされ、ポッド内のコンテナーとしてスピンアップされ、元のコンテナーと同じプロセス名前空間にアクセスする機能を備えています。

通常、本番コンテナはかなりむき出しになっているため、KoolKitを使用すると、本番イメージを最初に作成した人の寛大さ(または不注意)のために残されたものに頼るのではなく、動力工具でトラブルシューティングできます。

各KoolKitのツールは慎重に選択されており、このプロジェクト全体の背後にある動機については、以下で詳しく読むことができます。

良いものを見たいだけなら、GitHubでプロジェクト全体をチェックしてください。

Kubernetesのデバッグは難しい

Kubernetesポッド内で何が起こっているかを理解するのは簡単ではありません。

まず第一に、アプリケーションはもはや単一のエンティティではありません。複数のポッドで構成され、水平スケーリング用に複製され、場合によっては複数のクラスターに分散されます。

さらに、ローカルツール(デバッガーなど)を使用してアプリケーションにアクセスするには、検出やポート転送などの厄介なネットワークの問題に対処する必要があります。これにより、このようなツールの使用が遅くなります。

また、分散システムの世界の最高峰である、実行中のポッドの状態を変更したり、完全に停止したりすると(ブレークポイントを設定する場合など)、システムの他の部分でカスケード障害が発生し、既存の問題が悪化する可能性があります。

KoolKitsの背後にある動機

Lightrunは、Kubernetesを念頭に置いて構築されました。複数のポッド、複数のクラスター、さらには複数のクラウドで作業します。適切なツールを使用してパンチを詰めることは、トラブルシューティング開発者にとって大きな力の源であることを早い段階で理解しました。そして、何らかの形でコミュニティに還元する方法を見つけることができると考えました。それが、私たちがアイデアを思いついた方法です。 KoolKitsの場合。

KoolKitsが非常に役立つ理由を説明するために、少し深く掘り下げてみましょう。

小さなコンテナイメージを作成する必要があるという、よく知られているKubernetesのベストプラクティスがあります。これは、いくつかの異なる理由で理にかなっています。

  1. イメージを構築すると、消費するリソースが少なくなります(別名CI時間)
  2. 画像をプルするのにかかる時間は短くなります(とにかく多くの侵入にお金を払いたい人はいますか?)
  3. スタッフが少ないということは、操作なしのロギングでさえ安全ではなくなった世界で、セキュリティの脆弱性にさらされる表面積が少なくなることを意味します

あまり重労働をせずにそこにたどり着くのに役立つツールもたくさんあります。

  1. AlpineLinuxのベースイメージは非常に小さい
  2. DistroLess Dockerイメージはさらに一歩進んで、ランタイム以外のすべてを削除します
  3. Dockerマルチステージビルドは、シンの最終的な本番イメージの作成に役立ちます

これらのコンテナ内で何が起こっているかをデバッグしようとすると、問題が発生します。小さな本番イメージを使用することで、アプリケーションの問題に頭を悩ませるときに非常に貴重な大量のツールを放棄することになります。

KoolKitを使用することで、高品質のツールを損なうことなく、小さな本番イメージのメリットを享受できます。各KoolKitには、Linuxベースのより一般的なツールのセットに加えて、それが表す特定のランタイム用に厳選されたツールが含まれています。システム。

PS KoolKitsは、kubespynetshootに触発されました。

考慮事項

これらの画像の作成中に行った決定はかなり多くあります。考慮したいくつかの事項を以下に示します。

画像のサイズ

KoolKits Dockerイメージは実行される傾向があります、ええと、かなり大きいです。

KoolKitsは、一度ダウンロードして、クラスターのDockerレジストリーに保持し、その後、コンテナーとしてオンデマンドですぐにスピンアップすることを目的としています。それらは絶え間なく引っ張ることを意図しておらず、そしてそれらはグッズを詰め込むことを意図しているので、これは私たちが耐えることをいとわない副作用です。

Ubuntuベースイメージの使用

本当にスリムなイメージを作成するのが難しい理由の1つは、各KoolKitのベースとして完全なUbuntu20.04システムを使用することを決定したためです。これは主に、クラスター内でローカルにデバッグするのと同じ環境を複製したいという私たちの願望から来ました。

たとえば、これは、作業に慣れている通常のUbuntuパッケージに代わるAlpineの代替品をいじり回さないことを意味します。実際、これは、各KoolKitにAlpineバージョンがないツールを含める方法があることを意味します。

言語バージョンマネージャーの使用

各KoolKitは、言語固有のディストリビューションに依存する代わりに、(可能な限り)言語バージョンマネージャーを使用します。これは、古いランタイムバージョンを簡単にインストールできるようにするため、および必要に応じてランタイムバージョン間で自由に交換できるようにするため(たとえば、特定のランタイムバージョンにのみ存在する特定のバージョンのツールを取得するため)に行われます。

利用可能なKoolKits

リポジトリ内の各フォルダーには、KoolKitの背後にあるDockerfileとデバッグイメージの簡単な説明が含まれています。実際の人々は実際のシェルを必要とするため、すべてのKoolKitsはubuntu:20.04ベースイメージに基づいています。

利用可能なKoolKitsのリスト:

  1. koolkit-jvm – AdoptOpenJDK 17.0.2および関連ツール(バージョン管理を容易にするためのjabbaおよびMaven 3.8.4を含む)
  2. koolkit-node –ノード16.13.1および関連ツール(バージョン管理を容易にするためのnvmを含む)
  3. koolkit-python – Python 3.10.2および関連ツール(バージョン管理を容易にするためのpyenvを含む)

実際に自分でビルドする必要はないことに注意してください。すべてのKoolKitsはDockerHubで公開されており、無料で利用できます。

KoolKitsが登場

このストーリーは、もともとhttps://talktotheduck.dev/introducing-koolkits-oss-debugging-toolkits-for-kubernetesで公開されました

#koolkits #kubernetes 

KoolKits - OSS Debugging Toolkits for Kubernetes

KoolKits (Kubernetes toolkits) are highly-opinionated, language-specific, batteries-included debug container images for Kubernetes. In practice, they’re what you would’ve installed on your production pods if you were stuck during a tough debug session in an unfamiliar shell.

To briefly give some background, note that these container images are intended for use with the new kubectl debug feature, which spins up Ephemeral containers for interactive troubleshooting. A KoolKit will be pulled by kubectl debug, spun up as a container in your pod, and have the ability to access the same process namespace as your original container.

Since production containers are usually rather bare, using a KoolKit enables you to troubleshoot with power tools instead of relying on what was left behind due to the generosity (or carelessness) of whoever originally built the production image.

The tools in each KoolKit were carefully selected, and you can read more about the motivation behind this entire project below.

If you just want to take a look at the good stuff, feel free to check out the full project on GitHub.

Debugging Kubernetes is Hard

It’s not trivial to understand what’s going on inside a Kubernetes pod.

First of all, your application is not a single entity anymore – it is comprised of multiple pods, replicated for horizontal scaling, and sometimes even scattered across multiple clusters.

Furthermore, to access your application with local tools (like debuggers) you need to deal with pesky networking issues like discovery and port forwarding, which slows down the use of such tools.

And, the crown jewel of the distributed systems world-altering the state of or completely halting the running pod (e.g. when placing a breakpoint) might cause cascading failures in other parts of your system, which will exacerbate the existing problem.

The Motivation Behind KoolKits

Lightrun was built with Kubernetes in mind – we work across multiple pods, multiple clusters, and even multiple clouds. We understood early on that packing a punch by using the right tools is a great source of power for the troubleshooting developer – and we figured we’d find a way to give back to the community somehow – and that’s how we came up with the idea for KoolKits.

Let’s dive deep for a second to explain why KoolKits can be pretty useful:

There’s a well-known Kubernetes best practice that states that one should build small container images. This makes sense for a few different reasons:

  1. Building the image will consume less resources (aka CI hours)
  2. Pulling the image will take less time (who wants to pay for so much ingress anyways?)
  3. Less stuff means less surface area exposed to security vulnerabilities, in a world where even no-op logging isn’t safe anymore

There’s also a lot of tooling in existence that helps you get there without doing too much heavy lifting:

  1. Alpine Linux base images are super small
  2. DistroLess Docker images go a step further and remove everything but the runtime
  3. Docker multi-stage builds help create thin final production images

The problem starts when you’re trying to debug what’s happening inside those containers. By using a small production image you’re forsaking a large amount of tools that are invaluable when wrapping your head around a problem in your application.

By using a KoolKit, you’re allowing yourself the benefits of a small production image without compromising on quality tools – each KoolKit contains hand-picked tools for the specific runtime it represents, in addition to a more generic set of tooling for Linux-based systems.

P.S. KoolKits was inspired by kubespy and netshoot.

Considerations

There’s quite a few decisions we made during the construction of these images – some things we took into consideration are listed below.

Size of Images

KoolKits Docker images tend to run, uhm, rather large.

KoolKits are intended to be downloaded once, kept in the cluster’s Docker registry, and then spun up immediately on demand as containers. Since they’re not intended for constant pulling, and since they’re intended to be packed with goodies, this is a side effect we’re willing to endure.

Using Ubuntu base images

Part of the reason it’s hard to create a really slim image is due to our decision to go with a full Ubuntu 20.04 system as the basis for each KoolKit. This mainly came from our desire to replicate the same environment you would debug with locally inside your clusters.

For example, this means no messing around with Alpine alternatives to normal Ubuntu packages you’re used to working with. Actually, this means we have a way of including tools that have no Alpine versions in each KoolKit.

Using language version managers

Each KoolKit uses (wherever possible) a language version manager instead of relying on language-specific distros. This is done to allow you to install older runtime versions easily, and in order to allow you to swap between runtime versions at will (for example, to get specific versions of tooling that only exist for specific runtime versions), as need be.

Available KoolKits

Each of the folders in the repo contains the Dockerfile behind the KoolKit and a short explanation of the debug image. All KoolKits are based on the ubuntu:20.04 base image, since real people need real shells.

The list of available KoolKits:

  1. koolkit-jvm – AdoptOpenJDK 17.0.2 & related tooling (including jabba for easy version management and Maven 3.8.4)
  2. koolkit-node – Node 16.13.1 & related tooling (including nvm for easy version management)
  3. koolkit-python – Python 3.10.2 & related tooling (including pyenv for easy version management)

Note that you don’t actually have to build them yourselves – all KoolKits are hosted publicly on Docker Hub and available free of charge.

KoolKits Coming up

This story was originally published at https://talktotheduck.dev/introducing-koolkits-oss-debugging-toolkits-for-kubernetes

#koolkits #kubernetes 

Diego  Elizondo

Diego Elizondo

1654622400

KoolKits: Kits De Herramientas De Depuración De OSS Para Kubernetes

Los KoolKits ( k ubernetes toolkits ) son imágenes de contenedores de depuración para Kubernetes, altamente opinadas, específicas del idioma y con baterías incluidas. En la práctica, son lo que habría instalado en sus módulos de producción si estuviera atrapado durante una sesión de depuración difícil en un shell desconocido.

Para brindar información breve, tenga en cuenta que estas imágenes de contenedores están diseñadas para usarse con la nueva función de depuración de kubectl , que activa contenedores efímeros para la solución de problemas interactiva. La depuración de kubectl extraerá un KoolKit, lo girará como un contenedor en su pod y tendrá la capacidad de acceder al mismo espacio de nombres de proceso que su contenedor original.

Dado que los contenedores de producción suelen estar bastante vacíos, el uso de un KoolKit le permite solucionar problemas con herramientas eléctricas en lugar de confiar en lo que quedó atrás debido a la generosidad (o descuido) de quien creó originalmente la imagen de producción.

Las herramientas en cada KoolKit fueron cuidadosamente seleccionadas, y puedes leer más sobre la motivación detrás de todo este proyecto a continuación .

Si solo desea echar un vistazo a las cosas buenas, no dude en consultar el proyecto completo en GitHub .

Depurar Kubernetes es difícil

No es trivial entender lo que sucede dentro de un pod de Kubernetes.

En primer lugar, su aplicación ya no es una sola entidad: se compone de múltiples pods, replicados para escalamiento horizontal y, a veces, incluso dispersos en múltiples clústeres.

Además, para acceder a su aplicación con herramientas locales (como depuradores), debe lidiar con molestos problemas de red como el descubrimiento y el reenvío de puertos, lo que ralentiza el uso de dichas herramientas.

Y, la joya de la corona del mundo de los sistemas distribuidos: alterar el estado o detener por completo el pod en ejecución (por ejemplo, al colocar un punto de interrupción) podría causar fallas en cascada en otras partes de su sistema, lo que exacerbará el problema existente.

La motivación detrás de KoolKits

Lightrun se creó teniendo en cuenta a Kubernetes: trabajamos en varios pods, varios clústeres e incluso varias nubes. Comprendimos desde el principio que dar un golpe al usar las herramientas adecuadas es una gran fuente de poder para el desarrollador que soluciona problemas, y pensamos que encontraríamos una manera de retribuir a la comunidad de alguna manera, y así fue como se nos ocurrió la idea. para KoolKits.

Profundicemos por un segundo para explicar por qué KoolKits puede ser bastante útil:

Hay una práctica recomendada muy conocida de Kubernetes que establece que se deben crear imágenes de contenedores pequeños. Esto tiene sentido por algunas razones diferentes:

  1. Construir la imagen consumirá menos recursos (también conocido como horas de CI)
  2. Extraer la imagen llevará menos tiempo (¿quién quiere pagar tanto ingreso de todos modos?)
  3. Menos cosas significa menos superficie expuesta a vulnerabilidades de seguridad, en un mundo donde incluso el registro sin operaciones ya no es seguro

También existe una gran cantidad de herramientas que lo ayudan a llegar allí sin hacer demasiado trabajo pesado:

  1. Las imágenes base de Alpine Linux son muy pequeñas
  2. Las imágenes de DistroLess Docker van un paso más allá y eliminan todo menos el tiempo de ejecución
  3. Las compilaciones de varias etapas de Docker ayudan a crear imágenes finas de producción final

El problema comienza cuando intenta depurar lo que sucede dentro de esos contenedores. Al usar una imagen de producción pequeña, está renunciando a una gran cantidad de herramientas que son invaluables cuando se trata de un problema en su aplicación.

Al usar un KoolKit, se está permitiendo los beneficios de una pequeña imagen de producción sin comprometer la calidad de las herramientas: cada KoolKit contiene herramientas cuidadosamente seleccionadas para el tiempo de ejecución específico que representa, además de un conjunto más genérico de herramientas para sistemas basados ​​en Linux. sistemas

PS KoolKits se inspiró en kubespy y netshoot .

Consideraciones

Hay bastantes decisiones que tomamos durante la construcción de estas imágenes; algunas cosas que tomamos en consideración se enumeran a continuación.

Tamaño de las imágenes

Las imágenes de KoolKits Docker tienden a ejecutarse, uhm, bastante grandes .

Los KoolKits están destinados a descargarse una vez, guardarse en el registro de Docker del clúster y luego activarse inmediatamente bajo demanda como contenedores. Dado que no están diseñados para tirar constantemente, y dado que están destinados a estar repletos de golosinas, este es un efecto secundario que estamos dispuestos a soportar.

Uso de imágenes base de Ubuntu

Parte de la razón por la que es difícil crear una imagen realmente delgada se debe a nuestra decisión de usar un sistema Ubuntu 20.04 completo como base para cada KoolKit. Esto provino principalmente de nuestro deseo de replicar el mismo entorno con el que depuraría localmente dentro de sus clústeres.

Por ejemplo, esto significa que no tendrá que jugar con las alternativas de Alpine a los paquetes normales de Ubuntu con los que está acostumbrado a trabajar. En realidad, esto significa que tenemos una forma de incluir herramientas que no tienen versiones de Alpine en cada KoolKit.

Uso de administradores de versiones de idioma

Cada KoolKit usa (siempre que sea posible) un administrador de versiones de idioma en lugar de depender de distribuciones específicas del idioma. Esto se hace para permitirle instalar fácilmente versiones de tiempo de ejecución anteriores y para permitirle cambiar entre versiones de tiempo de ejecución a voluntad (por ejemplo, para obtener versiones específicas de herramientas que solo existen para versiones de tiempo de ejecución específicas), según sea necesario.

KoolKits disponibles

Cada una de las carpetas del repositorio contiene el Dockerfile detrás de KoolKit y una breve explicación de la imagen de depuración. Todos los KoolKits se basan en la imagen base de ubuntu:20.04 , ya que las personas reales necesitan shells reales.

La lista de KoolKits disponibles:

  1. koolkit-jvm : AdoptOpenJDK 17.0.2 y herramientas relacionadas (incluido jabba para una fácil gestión de versiones y Maven 3.8.4)
  2. koolkit-node : nodo 16.13.1 y herramientas relacionadas (incluido nvm para una fácil gestión de versiones)
  3. koolkit-python : Python 3.10.2 y herramientas relacionadas (incluido pyenv para una fácil gestión de versiones)

Tenga en cuenta que en realidad no tiene que crearlos usted mismo: todos los KoolKits están alojados públicamente en Docker Hub y están disponibles de forma gratuita.

Próximamente KoolKits

Esta historia se publicó originalmente en https://talktotheduck.dev/introducing-koolkits-oss-debugging-toolkits-for-kubernetes

#koolkits #kubernetes