Kubernetes は世界を征服するでしょう。 いつ、どのようにして?

期待して DevOpsConf ヴィタリー・ハバロフ インタビューされました ドミトリー・ストリャロフ (ディストル)、Flant 社のテクニカル ディレクター兼共同創設者。 Vitaly は、Flant が何をしているのか、Kubernetes、エコシステム開発、サポートについてドミトリーに尋ねました。 なぜ Kubernetes が必要なのか、そしてそもそも Kubernetes が必要なのかについて話し合いました。 また、マイクロサービス、Amazon AWS、DevOps への「幸運に恵まれる」アプローチ、Kubernetes 自体の将来、Kubernetes がなぜ、いつ、どのように世界を席巻するのか、DevOps の見通し、エンジニアがどのような準備をすべきかについても説明します。簡素化とニューラルネットワークによる明るい近未来。

オリジナルインタビュー DevOps Deflop (DevOps に関するロシア語のポッドキャスト) でポッドキャストとして聞いてください。以下はテキスト バージョンです。

ここと以下で彼は質問しています ヴィタリー・ハバロフ Express42のエンジニア。

「フラント」について

- こんにちは、ディマ。 あなたはテクニカルディレクターです」フラント」とその創設者でもあります。 会社が何をしているのか、そしてあなたがその中で何をしているのか教えてください。

ドミトリー：外から見ると、私たちはみんなのために Kubernetes をインストールして、それを使って何かをしている人のように見えます。 しかし、そうではありません。 当社は Linux を扱う会社としてスタートしましたが、非常に長い間、実稼働および高負荷のターンキー プロジェクトのサービスを主な活動としてきました。 通常、私たちはインフラストラクチャ全体をゼロから構築し、その後、長期間にわたってその責任を負います。 したがって、「Flant」がお金を受け取る主な仕事は、 責任を持ってターンキー生産を実施する.




私はテクニカル ディレクターであり、会社の創設者の XNUMX 人として、本番環境のアクセシビリティを高め、運用を簡素化し、管理者の作業を容易にし、開発者の作業をより快適にする方法を見つけるために昼夜を費やしています。 。

Kubernetesについて

— 最近、フラントと彼からのレポートをよく目にします。 物品 Kubernetesについて。 どうやって思いついたのですか？

ドミトリー：これについてはすでに何度も話していますが、繰り返しても構いません。 原因と結果が混同されているため、このトピックを繰り返すのは正しいと思います。

本当にツールが必要でした。 私たちは多くの問題に直面し、苦しみ、さまざまな松葉杖を使ってそれらを克服し、道具の必要性を感じました。 私たちはさまざまな選択肢を検討し、自分たちでバイクを作り、経験を積みました。 徐々に、Docker が登場してすぐに、つまり 2013 年頃に Docker を使い始めるところまで到達しました。 このコンテナが登場した時点で、私たちはすでにコンテナに関して多くの経験を積んでおり、「Docker」の類似物、つまり独自の松葉杖の一部を Python で作成していました。 Docker の登場により、松葉杖を捨てて、コミュニティによってサポートされている信頼性の高いソリューションを使用できるようになりました。

Kubernetes の場合も同様です。 それが勢いを増し始めた頃には、私たちにとってこれはバージョン 1.2 です。私たちはすでに Shell と Chef の両方にたくさんの松葉杖を持っていて、どういうわけか Docker で調整しようとしました。 私たちは Rancher やその他のさまざまなソリューションを真剣に検討していましたが、Kubernetes が登場しました。Kubernetes では、すべてが私たちが実行するものとまったく同じか、それ以上に実装されます。 文句の付けようがありません。

はい、ここにはある種の不完全性があり、そこにもある種の不完全性があります - 多くの不完全性があり、1.2 は一般的にひどいものですが... Kubernetes は建設中の建物のようなものです - プロジェクトを見れば理解できます涼しくなるだろうということ。 建物に基礎と XNUMX 階建ての場合は、まだ入居しない方がよいことは理解できますが、ソフトウェアにはそのような問題はなく、すでに使用できます。

Kubernetes を使用するかどうかを考える瞬間はありませんでした。 私たちはそれが登場するずっと前からそれを待っていて、自分たちで類似品を作成しようとしました。

Kubernetesについて

— Kubernetes自体の開発には直接関わっているのでしょうか？

ドミトリー：平凡です。 むしろ、私たちはエコシステムの発展に参加します。 私たちは一定数のプル リクエストを Prometheus、さまざまなオペレーター、Helm、つまりエコシステムに送信します。 残念ながら、私たちが行っているすべてのことを追跡することはできず、間違っている可能性がありますが、私たちからコアへのプールは単一ではありません。

— 同時に、多くのツールを Kubernetes を中心に開発していますか?

ドミトリー: 戦略は次のとおりです。既存のものすべてにリクエストをプルしていきます。 そこでプル リクエストが受け入れられない場合は、単に自分たちでフォークし、ビルドで受け入れられるまで存続します。 そして、上流に到達したら、上流バージョンに戻ります。

たとえば、Prometheus オペレーターがあり、これを使用してアセンブリの上流との間でおそらくすでに 5 回切り替えを行っています。 何らかの機能が必要で、プル リクエストを送信しました。明日ロールアウトする必要がありますが、アップストリームでリリースされるまで待ちたくないのです。 したがって、私たちは自分たちで組み立て、何らかの理由で必要な機能を備えたアセンブリをすべてのクラスターにロールアウトします。 次に、たとえば、「皆さん、もっと一般的なケースでやろう」という言葉とともに上流の私たちに引き渡し、私たちまたは他の誰かがそれを完成させ、時間が経つと再びマージされます。

私たちは存在するものすべてを開発しようとします。 多くの要素はまだ存在していないか、まだ発明されていない、あるいは発明されたが実装する時間がなかった - 私たちはそれを実行しています。 それは、業界としてのプロセスや自転車製造が好きだからではなく、単にこのツールが必要だからです。 なぜ私たちはこれやあんなことをしたのですか?という質問がよくあります。 答えは簡単です - はい、さらに進んで実際的な問題を解決する必要があり、それをこのトゥーラで解決したからです。

道はいつもこんな感じです。注意深く探して、パンからトロリーバスを作る方法が見つからない場合は、自分たちでパンとトロリーバスを作ります。

フランタツール

— Flant には現在アドオン オペレーター、シェル オペレーター、dapp/werf ツールがあることは知っています。 私の理解では、これは異なる化身でも同じ楽器です。 また、Flaunt にはさらに多くのさまざまなツールがあることも理解しています。 これは本当です？

ドミトリー: GitHub には他にもたくさんあります。 今覚えている限りでは、ステータスマップという、誰もが気に入った Grafana のパネルがあります。 これは、Medium での Kubernetes モニタリングに関するほぼすべての記事で言及されています。 ステータスマップとは何かを簡単に説明することは不可能です。これについては別の記事が必要ですが、Kubernetes では時間の経過とともにステータスを表示する必要があることが多いため、ステータスマップを時間の経過とともに監視するのに非常に役立ちます。 LogHouse もあります。これは、ClickHouse と Kubernetes でログを収集するための黒魔術に基づいたものです。

ユーティリティがたくさん！ 今年は多数の社内ソリューションがリリースされる予定なので、さらに多くのソリューションがリリースされるでしょう。 アドオン オペレーターをベースにした非常に大規模なものの中には、Kubernetes 用のアドオンが多数あります。証明書を管理するツールである sert マネージャーを適切にインストールする方法、多数のアクセサリを備えた Prometheus を正しくインストールする方法など、これらは約 XNUMX 種類あります。データをエクスポートして何かを収集するバイナリに対して、Prometheus には最も素晴らしいグラフィックスとアラートが備わっています。 これらはすべて、クラスターにインストールされる Kubernetes へのアドオンの束にすぎず、シンプルなものからクールで洗練された自動なものに変わり、多くの問題がすでに解決されています。 はい、たくさんやってます。

生態系の発展

「これはこの機器とその使用方法の開発に非常に大きな貢献であるように思えます。」 他に誰がエコシステムの発展に同じ貢献をするだろうか、大まかに見積もることはできますか?

ドミトリー: ロシアでは、私たちの市場で活動している企業の中で、それに匹敵する企業はありません。 もちろん、これは大声での発言です。Mail や Yandex のような大手企業もあり、彼らも Kubernetes を使って何かを行っていますが、彼らですら、私たちよりもはるかに多くのことを行っている全世界の企業の貢献には及びません。 私の記憶が間違っていなければ、80 人のスタッフを抱える Flant と、Kubernetes ごとに 300 人のエンジニアを抱える Red Hat を比較するのは困難です。 比較するのは難しいです。 RnD 部門には私を含めて 6 人がおり、すべての工具をカットしています。 6 人対 300 人の Red Hat エンジニア – 比較するのはどういうわけか難しいです。

- しかし、この 6 人でも、実際的な問題に直面して、コミュニティに解決策を提供するときに、本当に有益で疎外的なことを行うことができるのは、興味深いケースです。 大手テクノロジー企業では、独自の Kubernetes 開発およびサポート チームがあり、原則として同じツールを開発できると理解しています。 これは、開発してコミュニティに提供できるものの一例であり、Kubernetes を使用するコミュニティ全体に推進力を与えます。

ドミトリー：これはおそらくインテグレータの機能、特殊性です。 私たちには多くのプロジェクトがあり、さまざまな状況が見られます。 私たちにとって、付加価値を生み出す主な方法は、これらの事例を分析し、共通点を見つけて、できるだけ安くすることです。 私たちはこれに積極的に取り組んでいます。 ロシアや世界について話すのは難しいですが、社内には Kubernetes に取り組む DevOps エンジニアが約 40 人います。 ロシアには、Kubernetes を理解するスペシャリストをこれほど多く抱えている企業は、たとえあったとしても多くないと思います。

私は DevOps エンジニアという役職についてすべてを理解しています。誰もがすべてを理解しており、DevOps エンジニアを DevOps エンジニアと呼ぶことに慣れています。これについては議論しません。 これら 40 人の素晴らしい DevOps エンジニア全員が毎日問題に直面し、解決しています。私たちはこの経験を分析し、一般化しようとしているだけです。 それが私たちの中に残っている場合、コミュニティのどこかに既製のトゥーラが現れるため、ツールはXNUMX〜XNUMX年で役に立たなくなることを私たちは理解しています。 この経験を内部的に蓄積しても意味はありません。エネルギーと時間を dev/null に消耗するだけです。 そして私たちはそれを全く残念に思っていません。 私たちはすべてを喜んで公開し、人々がそれを使用し、経験を追加できるように、公開、開発、宣伝、宣伝する必要があることを理解しています。そうすれば、すべてが成長し、生き続けます。 そしてXNUMX年経っても楽器はゴミ箱行きになりません。 誰かがあなたのツールを使用していることは明らかであり、XNUMX 年後には誰もがそれを使用しているため、力を注ぎ続けることは残念ではありません。

これは、dapp/werf を使用した当社の大きな戦略の一部です。 いつ作り始めたかは覚えていないのですが、3年くらい前だったような気がします。 当初、それは通常シェル上にありました。 これは非常に優れた概念実証であり、特定の問題のいくつかを解決しました。うまくいきました。 しかし、シェルには問題があり、これ以上拡張することは不可能です。シェルでのプログラミングは別の作業です。 私たちは Ruby で書く習慣があったので、Ruby で何かを作り直し、開発、開発、開発を繰り返し、コミュニティ、つまり「欲しい、欲しくない」を言わない集団が存在するという事実に遭遇しました。 」とルビーに鼻を向けるのですが、面白いですか？ チェックリストの最初の点を満たすためには、これらすべてを Go で記述する必要があることに気付きました。 DevOps ツールは静的バイナリである必要があります。 Go かどうかはそれほど重要ではありませんが、Go で書かれた静的バイナリの方が優れています。

私たちはエネルギーを費やして、dapp を Go で書き直し、それを werf と名付けました。 Dapp はサポートも開発も行われておらず、最新バージョンで実行されていますが、最上位への絶対的なアップグレード パスがあり、それに従うことができます。

dappはなぜ作られたのでしょうか？

— dappが作られた理由と、それが解決する問題を簡単に教えてください。

ドミトリー：最初の理由はアセンブリにあります。 当初、Docker にマルチステージ機能がなかったため、ビルドに大きな問題が発生したため、独自にマルチステージを作成しました。 その後、イメージのクリーニングに関してさらに多くの問題が発生しました。 CI/CD を行う人は、遅かれ早かれ、大量の画像が収集されているため、不要なものを何らかの方法で削除し、必要なものを残す必要があるという問題に直面することになります。

XNUMX 番目の理由は展開です。 はい、Helm はありますが、それは問題の一部しか解決しません。 面白いことに、「Helm は Kubernetes のパッケージ マネージャーです」と書かれています。 まさに「ザ」です。 「パッケージ マネージャー」という言葉もありますが、パッケージ マネージャーに通常期待されるものは何ですか? 「パッケージ マネージャー - パッケージをインストールしてください!」と言います。 そして私たちは彼が「荷物は配達されました」と言うのを期待しています。

興味深いのは、私たちが「ヘルム、パッケージをインストールしてください」と言うと、彼がインストールしたと答えると、ちょうどインストールを開始したばかりであることがわかります。彼は Kubernetes に「これを起動してください!」と指示し、それが開始したかどうかを指示しました。機能するかどうかに関係なく、Helm はこの問題をまったく解決しません。

Helm は Kubernetes にデータをロードする単なるテキスト プリプロセッサであることがわかりました。

しかし、デプロイメントの一環として、アプリケーションが実稼働用にリリースされたかどうかを知りたいと思いますか? prod にロールアウトされたということは、アプリケーションがそこに移動され、新しいバージョンがデプロイされ、少なくともそこでクラッシュせず、正しく応答することを意味します。 Helm はこの問題をまったく解決しません。 これを解決するには、Kubernetes にロールアウトするコマンドを与え、そこで何が起こっているか (デプロイされているかロールアウトされているか) を監視する必要があるため、多大な労力を費やす必要があります。 また、展開、クリーニング、組み立てに関連するタスクもたくさんあります。

予定

今年は現地開発を開始します。 以前 Vagrant にあったものを実現したいと考えています。「vagrant up」と入力し、仮想マシンをデプロイしました。 Git にプロジェクトがあるところまで進みたいと思います。そこに「werf up」と書きます。すると、このプロジェクトのローカル コピーが表示され、ローカルの mini-Kub にデプロイされ、開発に便利なすべてのディレクトリが接続されます。 。 開発言語に応じてこれの実行方法は異なりますが、それでもローカル開発をマウントされたファイルで簡単に実行できるようにします。

私たちの次のステップは、 開発者の利便性に投資する。 XNUMX つのツールを使用してプロジェクトをローカルに迅速にデプロイするには、プロジェクトを開発して Git にプッシュします。また、パイプラインに応じてステージングまたはテストにロールアウトし、同じツールを使用して運用環境に移行します。 このローカル環境から販売までのインフラの一体性、統一性、再現性は私たちにとって非常に重要なポイントです。 しかし、これはまだ計画されていません。私たちはそれを計画しているところです。

しかし、dapp/werf への道は、最初の Kubernetes の場合と常に同じでした。 私たちは問題に遭遇し、回避策でそれらを解決しました。私たちは、シェルやあらゆるものについて、自分たちでいくつかの解決策を考え出しました。 次に、彼らはこれらの回避策を何らかの形で修正し、一般化してバイナリに統合しようとしました。この場合は、それを共有するだけです。

この物語全体を類推して見る別の方法もあります。

Kubernetes はエンジンを備えた自動車のフレームです。 ドアもガラスもラジオもクリスマスツリーも何もありません。 フレームとエンジンだけ。 そしてHelmがあります - これはハンドルです。 クールです。ステアリングホイールはありますが、ステアリングピン、ステアリングラック、ギアボックス、ホイールも必要で、これらなしではやっていけません。

werf の場合、これは Kubernetes の別のコンポーネントです。 たとえば、werf のアルファ版では、Helm が werf 内でコンパイルされるようになりました。これは、自分たちで行うのに飽きたからです。 これには多くの理由がありますが、なぜヘルム全体とティラーをヴェルフ内にまとめたのかについて詳しく説明します。 RIT++でのレポートにて.

werf はより統合されたコンポーネントになりました。 完成したステアリングホイールとステアリングピンを入手します。私は車があまり得意ではありませんが、これはすでにかなり広範囲の問題を解決する大きなブロックです。 自分でカタログを調べて、ある部品と別の部品を選択し、それらをどのようにねじ込むかを考える必要はありません。 多くの問題を一度に解決する既製のコンバインを入手します。 しかし、その内部は同じオープン ソース コンポーネントから構築されており、アセンブリには Docker を使用し、一部の機能には Helm を使用しており、他にもいくつかのライブラリがあります。 これは、優れた CI/CD を箱から出してすぐに便利に入手できる統合ツールです。

Kubernetes の保守は難しいですか?

— あなたは Kubernetes を使い始めた経験について話しています。これはあなたにとってフレームであり、エンジンであり、ボディ、ハンドル、ペダルのネジ、シートなど、さまざまなものをその上に掛けることができるとのことです。 Kubernetes のサポートはどのくらい難しいですか?という疑問が生じます。 あなたは豊富な経験をお持ちですが、他のすべてから分離して Kubernetes をサポートするためにどのくらいの時間とリソースを費やしていますか?

ドミトリー: これは非常に難しい質問です。答えるには、サポートとは何か、Kubernetes に何を求めているのかを理解する必要があります。 もしかしたら暴露できるかも？

— 私の知る限り、また見ている限り、現在多くのチームが Kubernetes を試したいと考えています。 誰もがそれを利用し、膝の上に置きます。 人々はこのシステムの複雑さを必ずしも理解していないような気がします。

ドミトリー： そのようなものです。

— Kubernetes を最初から導入してインストールし、本番環境に対応させるのはどのくらい難しいですか?

ドミトリー：心臓を移植するのはどれくらい難しいと思いますか？ これが妥協的な質問であることは理解しています。 メスを使ってミスをしないことは、それほど難しいことではありません。 どこを切るか、どこを縫うか教えてもらえれば、手順自体は難しくありません。 すべてがうまくいくことを何度も保証するのは困難です。

Kubernetes をインストールして動作させるのは簡単です。 — インストールされていますが、インストール方法はたくさんあります。 しかし、問題が発生した場合はどうなるでしょうか?

常に疑問が生じます。まだ考慮されていないことは何ですか? 私たちがまだやっていないことは何でしょうか？ どの Linux カーネル パラメータが間違って指定されましたか? 主よ、私たちはそれらについても言及しましたか?! どの Kubernetes コンポーネントが配信され、どのコンポーネントが配信されていないでしょうか? 何千もの疑問が生じ、それらに答えるには、この業界で 15 ～ 20 年を費やす必要があります。

このトピックに関して、「Kubernetes の保守は難しいですか?」という問題の意味を明らかにする可能性のある最近の例があります。 少し前に、私たちは Cilium を Kubernetes のネットワークとして実装するべきかどうかを真剣に検討しました。

Ciliumとは何かについて説明しましょう。 Kubernetes にはネットワーク サブシステムのさまざまな実装があり、その中の XNUMX つである Cilium は非常に優れています。 その意味は何ですか? カーネルでは、少し前にカーネル用のフックを作成できるようになりました。これにより、何らかの形でネットワーク サブシステムやその他のさまざまなサブシステムに侵入し、カーネル内の大きなチャンクをバイパスできるようになります。

Linux カーネルには歴史的に、ip ルート、オーバーフィルター、ブリッジ、および 15 年、20 年、30 年前のさまざまな古いコンポーネントが含まれています。 一般的に、それらは機能し、すべてが素晴らしいですが、今ではコンテナが積み上げられ、15個のレンガが積み重なった塔のように見え、その上に片足で立っています - 奇妙な感覚です。 このシステムは、体内の付録のように、歴史的にさまざまなニュアンスを伴いながら発展してきました。 たとえば、状況によってはパフォーマンスの問題が発生することがあります。

素晴らしい BPF とカーネル用のフックを作成する機能があり、彼らはカーネル用に独自のフックを作成しました。 パッケージは Linux カーネルに入り、入力時に直接取り出され、ブリッジや TCP、IP スタックを使用せずに、必要に応じて自動的に処理されます。つまり、Linux カーネルに記述されているすべての内容をバイパスして、吐き出します。それを容器の中に出します。

どうしたの？ 非常にクールなパフォーマンス、クールな機能 - とにかくクールです! しかし、これを見ると、各マシンには Kubernetes API に接続するプログラムがあり、この API から受け取ったデータに基づいて C コードを生成し、バイナリをコンパイルしてカーネルにロードし、これらのフックが機能することがわかります。カーネル空間内。

何か問題が発生した場合はどうなりますか? 我々は知りません。 これを理解するには、このコードをすべて読み、ロジックをすべて理解する必要がありますが、それがどれほど難しいかは驚くべきことです。 しかしその一方で、これらのブリッジ、ネット フィルター、IP ルーティングも存在します。私はそれらのソース コードを読んだことがありませんし、当社で働く 40 人のエンジニアも読んでいません。 一部の部分を理解している人は少ないかもしれません。

違いは何ですか? Linux カーネルである ip rout があり、新しいツールがあることがわかりました。それがどのような違いを生むのか、私たちはどちらかを理解していません。 しかし、私たちは新しいものを使用することを恐れています - なぜでしょうか? なぜなら、ツールが 30 年前のものであれば、30 年の間にすべてのバグが発見され、すべての間違いが踏まれているため、すべてを知る必要はありません。ブラック ボックスのように機能し、常に機能します。 どの診断ドライバーをどの場所に差し込むべきか、どの時点でどの tcpdump を実行すべきかは誰もが知っています。 誰もが診断ユーティリティについてはよく知っており、この一連のコンポーネントが Linux カーネルでどのように機能するか、つまり動作方法ではなく、使用方法を理解しています。

そして、素晴らしくクールな Cilium は 30 歳ではなく、まだ老化していません。 Kubernetes にも同じ問題があります。 Cilium は完璧にインストールされており、Kubernetes も完璧にインストールされていますが、本番環境で何か問題が発生した場合、危機的な状況で何が問題だったのかをすぐに理解できますか?

Kubernetes を保守するのは難しいかというと、いいえ、それは非常に簡単ですが、はい、信じられないほど難しいです。 Kubernetes は単独でも優れた機能を発揮しますが、さまざまなニュアンスがあります。

「ラッキー」アプローチについて

— こういったニュアンスがほぼ確実に現れる企業はあるのでしょうか？ Yandex が突然すべてのサービスを Kubernetes に移行すると、そこには大きな負荷が発生します。

ドミトリー: いいえ、これは負荷についての話ではなく、最も単純なことについての話です。 たとえば、Kubernetes があり、そこにアプリケーションをデプロイしました。 それが機能していることをどうやって知ることができますか? アプリケーションがクラッシュしていないことを理解するための既製のツールはまったくありません。 アラートを送信する既製のシステムはなく、これらのアラートと各スケジュールを構成する必要があります。 そして、Kubernetes を更新しています。

Ubuntu 16.04を使用しています。 これは古いバージョンであると言えますが、LTS であるためまだ使用されています。 systemd というものがありますが、そのニュアンスは C グループをクリーンアップしないということです。 Kubernetes はポッドを起動し、C グループを作成し、その後ポッドを削除します。そしてどういうわけか、申し訳ありませんが詳細は覚えていません。systemd スライスが残っていることがわかりました。 これは、時間の経過とともに、どの車も大幅に速度を落とし始めるという事実につながります。 これは高負荷に関する質問でもありません。 たとえば、永続的なポッドが起動された場合、ポッドを常に生成する Cron ジョブがある場合、Ubuntu 16.04 を搭載したマシンは 16 週間後に速度が低下し始めます。 多数の C グループが作成されているため、負荷平均は常に高くなります。 これは、単に Ubuntu XNUMX と Kubernetes をその上にインストールする人が直面する問題です。

彼が何らかの方法で systemd などを更新したとしましょう。しかし、4.16 までの Linux カーネルではさらにおかしなことになります。C グループを削除すると、それらはカーネル内に漏洩し、実際には削除されません。 したがって、このマシンで 15 か月間作業を続けると、炉床のメモリ統計を確認できなくなります。 ファイルを取り出し、プログラム内でローリングすると、XNUMX つのファイルが XNUMX 秒間ローリングされます。これは、カーネルが内部の XNUMX 万個の C グループをカウントするのに非常に長い時間がかかるためです。これらのグループは削除されているように見えますが、違います。リークしています。 。

こんな小さなものがまだあちこちにたくさんあります。 これは、巨大企業が非常に大きな負荷の下で時々直面する可能性がある問題ではありません。いや、それは日常的な問題です。 人々は何ヶ月もこのように生活することができます。Kubernetes をインストールし、アプリケーションをデプロイしました。それは機能しているようです。 多くの人にとって、これは普通のことです。 彼らは、このアプリケーションが何らかの理由でクラッシュすることさえ知りませんし、アラートも受け取りませんが、彼らにとってはこれが標準です。 以前は監視なしで仮想マシンを使用していましたが、現在は監視なしで Kubernetes に移行しています。その違いは何でしょうか?

問題は、私たちが氷の上を歩くとき、事前に測定しない限りその厚さを知ることはできないということです。 多くの人は歩いたことがあるので、心配することはありません。

私の観点からすると、システムを運用する上での微妙な違いと複雑さは、問題を解決するのに十分な氷の厚さを確保することにあります。 これが私たちが話していることです。

IT 業界では、「運が良ければ」というアプローチが多すぎるように思えます。 多くの人は幸運を期待してソフトウェアをインストールし、ソフトウェア ライブラリを使用します。 一般に、多くの人は幸運です。 おそらくそれが機能する理由です。

— 私の悲観的な評価によると、次のようになります。リスクが高く、アプリケーションが動作する必要がある場合、Flaunt、おそらく Red Hat からのサポートが必要になるか、準備ができている Kubernetes 専用の社内チームが必要になります。それをやり遂げるために。

ドミトリー：客観的にはそうなんです。 小規模なチームで Kubernetes の話に独力で取り組むことには、多くのリスクが伴います。

コンテナは必要ですか?

— ロシアで Kubernetes がどの程度普及しているか教えていただけますか?

ドミトリー: 私はこのデータを持っていませんし、他の人がそれを持っているかどうかもわかりません。 私たちは「Kubernetes、Kubernetes」と言いますが、この問題には別の見方もあります。 また、コンテナーがどの程度普及しているかはわかりませんが、インターネット上のレポートから、コンテナーの 70% が Kubernetes によってオーケストレーションされているという数字はわかります。 これは、世界中のかなり大規模なサンプルの信頼できる情報源でした。

次に別の質問ですが、コンテナは必要ですか? 私の個人的な感覚と Flant 社の全体的な立場は、Kubernetes が事実上の標準であるということです。

Kubernetes 以外には何も存在しません。

これは、インフラストラクチャ管理の分野における絶対的な変革です。 絶対的なものだけです。Ansible、Chef、仮想マシン、Terraform は不要です。 私は昔の集団農法について話しているのではありません。 Kubernetes は絶対的な変革者です、そして今はこうなるしかありません。

これを理解するのに数年かかる人もいれば、数十年かかる人もいるのは明らかです。 Kubernetes とこの新しい外観以外に何も存在しないことは間違いありません。オペレーティング システムに損傷を与えることはなくなりましたが、 コードとしてのインフラストラクチャ、コードだけでなく、宣言的に記述されたインフラストラクチャである yml も使用します。 これからもずっとそうな気がする。

— つまり、まだ Kubernetes に切り替えていない企業は、間違いなく Kubernetes に切り替えるか、忘れ去られたままになるでしょう。 正しく理解しましたか？

ドミトリー：これも完全に真実ではありません。 たとえば、DNS サーバーを実行するタスクがある場合、FreeBSD 4.10 上で実行でき、20 年間は完全に動作します。 ただ働くだけです。 おそらく20年以内に何かを一度更新する必要があるでしょう。 私たちが立ち上げた形式のソフトウェアについて話していて、実際に何年もアップデートや変更を加えずに動作するのであれば、当然、Kubernetes は存在しません。 彼はそこには必要ありません。

CI/CD に関連するすべて - 継続的デリバリーが必要な場合、バージョンを更新する必要がある場合、アクティブな変更を行う必要がある場合、フォールト トレランスを構築する必要がある場合 - Kubernetes のみ。

マイクロサービスについて

- ここで少し不協和音があります。 Kubernetes を使用するには、外部または内部のサポートが必要です。これが最初のポイントです。 第二に、私たちが開発を始めたばかりのとき、私たちは小規模なスタートアップであり、まだ何も持っていません。Kubernetes またはマイクロサービス アーキテクチャ一般の開発は複雑になる可能性があり、必ずしも経済的に正当化されるとは限りません。 あなたの意見に興味があります。スタートアップ企業はすぐにゼロから Kubernetes 用の作成を開始する必要があるのでしょうか、それともモノリスを作成した後、Kubernetes のみを使用できるのでしょうか?

ドミトリー: クールな質問です。 マイクロサービスについて話します 「マイクロサービス: サイズは重要です。」 顕微鏡を使って釘を打とうとしている人に何度も遭遇しました。 このアプローチ自体は正しく、私たち自身も社内ソフトウェアをこのように設計しています。 ただし、これを行う場合は、自分が何をしているのかを明確に理解する必要があります。 マイクロサービスに関して私が最も嫌いな言葉は「マイクロ」です。 歴史的には、この言葉はそこから生まれましたが、どういうわけか人々はマイクロをマイクロメートルのように、XNUMXミリメートル未満の非常に小さいものだと考えています。 これは間違っています。

たとえば、300 人が書いたモノリスがあり、開発に参加した全員がそこに問題があることを理解しており、それを小さな部分に分割する必要があるとします。約 10 個の部分にそれぞれ 30 人が作成します。最小バージョンで。 これは重要であり、必要であり、クールです。 しかし、非常にクールで才能のある 3 人が膝の上で 60 個のマイクロサービスを書いたスタートアップが私たちのところに来ると、私はいつも Corvalol を探します。

これはすでに何千回も話されているように思えます - 私たちは何らかの形で分散モノリスを手に入れました。 これは経済的に正当化されるものではなく、一般にすべてにおいて非常に困難です。 私はこれを何度も見たので本当に傷ついたので、それについて話し続けます。

最初の質問に対しては、Kubernetes は何が壊れるのか、機能しないのかが明確ではないため、使用するのが怖いという事実と、Kubernetes ではすべてが機能することは明らかであるという事実の間に矛盾があります。そして、Kubernetes 以外は何も存在しません。 答え - 得られる利益の量と、解決できるタスクの量を比較検討する。 これはスケールの片側にあります。 一方で、ダウンタイムや応答時間の低下、可用性レベルの低下、つまりパフォーマンス指標の低下に関連するリスクもあります。

つまり、私たちは迅速に行動し、Kubernetes によって多くのことをより速く、より適切に実行できるようになります。あるいは、信頼性が高く実績のあるソリューションを使用しますが、行動ははるかに遅くなります。 これはすべての企業が選択しなければならないことです。 それはジャングルの中の小道と考えることができます。初めて歩くと、ヘビ、トラ、または狂ったアナグマに出会うことができ、10回歩くと、その道を歩いたことになります。枝がなくなり歩きやすくなります。 毎回道が広くなります。 その後はアスファルト道路になり、その後は美しい大通りになります。

Kubernetes は立ち止まっていません。 再質問: Kubernetes は 4 ～ 5 つのバイナリである一方で、エコシステム全体です。 これは、私たちのマシンに搭載されているオペレーティング システムです。 これは何ですか？ Ubuntu か Curios か? これは Linux カーネルであり、追加コンポーネントの束です。 これらすべてがここにあり、一匹の毒蛇が道路から投げ捨てられ、そこに柵が建てられました。 Kubernetes は非常に迅速かつ動的に開発されており、リスクの量と未知の量は毎月減少しており、それに応じてこれらのスケールのバランスが再調整されています。

スタートアップは何をすべきかという質問に答えると、私はこう言います。Flaunt に来て、150 万ルーブルを支払って、簡単なターンキー DevOps サービスを受けてください。 開発者が数人の小規模なスタートアップの場合は、これでうまくいきます。 問題の解決方法を学び、現時点で給与を支払う必要がある独自の DevOps を雇う代わりに、すべての問題に対するターンキー ソリューションを得ることができます。 はい、いくつかの欠点があります。 私たちはアウトソーサーとして、そこまで関与して変化に迅速に対応することはできません。 しかし、私たちには多くの専門知識とすぐに使える実践方法があります。 私たちは、どのような状況であっても、すぐに問題を解決し、Kubernetes を復活させることを保証します。

10 人のチームを運営に専任できる規模までのスタートアップや既存の企業にアウトソーシングすることを強くお勧めします。そうしないと意味がありません。 これをアウトソーシングすることは間違いなく合理的です。

アマゾンとグーグルについて

— Amazon や Google のソリューションのホストはアウトソースとして考慮できますか?

ドミトリー: はい、もちろん、これにより多くの問題が解決されます。 しかし、やはりニュアンスがあります。 まだ使い方を理解する必要があります。 たとえば、Amazon AWS の作業には細かい作業がたくさんあります。ロード バランサーをウォームアップする必要があるか、「皆さん、トラフィックを受信しますので、ロード バランサーをウォームアップしてください!」というリクエストを事前に作成する必要があります。 こういったニュアンスを知っておく必要があります。

これを専門とする人に頼ると、典型的な問題はほぼすべて解決されます。 現在、エンジニアは 40 名ですが、年末までにおそらく 60 名になるでしょう。私たちは間違いなくこれらすべてに遭遇しました。 何かのプロジェクトでまたこの問題に遭遇したとしても、すぐにお互いに質問して解決方法を知っています。

おそらく答えは、「もちろん、ホストされたストーリーにより、ある部分が簡単になる」です。 問題は、これらのホスティング業者を信頼する準備ができているかどうか、そして彼らが問題を解決してくれるかどうかです。 アマゾンとグーグルは好調だ。 すべてのケースにおいて、まさにそうです。 これ以上ポジティブな経験はありません。 私たちが扱おうとした他のクラウドはすべて、Ager やロシアにあるすべてのもの、さまざまな実装でのあらゆる種類の OpenStack (ヘッドスター、オーバーエイジなど) など、多くの問題を引き起こします。 それらはすべて、解決したくない問題を引き起こします。

したがって、答えは「はい」ですが、実際には、成熟したホスト型ソリューションはそれほど多くありません。

Kubernetes が必要なのは誰ですか?

— それでも、Kubernetes を必要とするのは誰でしょうか? すでに Kubernetes に切り替える必要があるのは誰ですか。Kubernetes 専用の典型的な Flaunt クライアントは誰ですか?

ドミトリー: これは興味深い質問です。なぜなら、現在、Kubernetes の影響で、多くの人が私たちのところに来ます。「みなさん、あなたが Kubernetes をやっているのは知っています。私たちのためにやってください!」 私たちは彼らにこう答えます。「皆さん、私たちは Kubernetes をやっているわけではありません。私たちは prod とそれに関連するあらゆることをやっているのです。」 なぜなら、現時点では、すべての CI/CD とこのストーリー全体を実行せずに製品を作成することはまったく不可能だからです。 開発に開発があり、その後に搾取に搾取が行われるという区分から誰もが離れてきました。

私たちのクライアントはさまざまなことを期待していますが、誰もが何らかの問題を抱えているという良い奇跡を待っています。 — Kubernetes がそれらを解決します。 人々は奇跡を信じます。 彼らは心の中では奇跡など起こらないと理解していますが、心の中では期待しています - もしこの Kubernetes がすべてを解決してくれるとしたら、彼らはそれについてたくさん話します。 突然彼は今、くしゃみをしました！ -そして特効薬、くしゃみ！ — そして稼働率は 100% であり、すべての開発者は本番環境に導入されたものを 50 回リリースできますが、クラッシュすることはありません。 一般的に、奇跡です！

そのような人が私たちのところに来ると、私たちはこう言います。「申し訳ありませんが、奇跡などというものはありません。」 健康になるためには、よく食べて運動する必要があります。 信頼性の高い製品を実現するには、信頼性の高い製造が必要です。 便利な CI/CD を作成するには、次のようにする必要があります。 やらなければならない作業はたくさんあります。

誰が Kubernetes を必要とするかという質問への答え - Kubernetes を必要とする人はいません。

Kubernetes が必要であると誤解している人もいます。 人々は、インフラストラクチャのすべての問題やアプリケーションの実行の問題について考えたり、勉強したり、興味を抱いたりするのをやめる必要があり、深く必要としています。 彼らは、アプリケーションが動作し、デプロイされるだけであることを望んでいます。 彼らにとって、Kubernetes は、「私たちはそこに横たわっていた」とか、「ロールアウトできない」とか、その他の話を聞かなくなるという希望です。

通常はテクニカルディレクターが来てくれます。 彼らは彼に XNUMX つのことを尋ねます。XNUMX つは機能を提供すること、もう XNUMX つは安定性を提供することです。 ぜひ自分自身で引き受けて実行することをお勧めします。 特効薬、というか特効薬は、こうした問題について考えて時間を無駄にするのをやめるということです。 この問題を解決してくれる特別な人がいます。

私たちや他の誰かが Kubernetes を必要とするという表現は正しくありません。

Kubernetes は遊んだりいじったりできる非常に興味深いおもちゃなので、管理者には本当に必要です。 正直に言うと、誰もがおもちゃが大好きです。 私たちは皆、どこかの子供であり、新しいものを見ると、それをプレイしたくなります。 たとえば、政権内でこれを推奨されない人もいる。なぜなら、彼らはすでに十分にプレーしており、もう単純にプレーしたくないほど疲れているからである。 しかし、これは誰にも完全に失われるわけではありません。 たとえば、システム管理や DevOps の分野のおもちゃに長い間飽きていたとしても、私はそのおもちゃがまだ大好きで、新しいおもちゃをいくつか購入します。 人は皆、何らかの形で、何らかのおもちゃを欲しがります。

プロダクションをいじる必要はありません。 私が絶対にやらないことを推奨していること、そして今私が目にしているものはすべて、「ああ、新しいおもちゃだ!」というものです。 — 彼らは走ってそれを買いに行き、買って、「今すぐ学校に持っていって、友達全員に見せましょう。」 こんなことはしないでください。 申し訳ありませんが、私の子供たちは成長したばかりで、私は常に子供たちの中に何かを見て、自分自身の中でそれに気づき、それを他の人に一般化します。

最終的な答えは、「Kubernetes は必要ない」です。 問題を解決する必要があります。

達成できることは次のとおりです。

• プロッドは落ちません。
• たとえ彼が落ちようとしても、私たちはそれを事前に知っており、その中に何かを入れることができます。
• ビジネスに必要なスピードで変更でき、便利に変更できるため、何の問題も発生しません。

実際のニーズは XNUMX つあります。信頼性と展開のダイナミズム/柔軟性です。 現在、世界を楽にするためのソフトなど、どのような種類の IT プロジェクトに取り組んでいて、これを理解している人は誰でも、これらのニーズを解決する必要があります。 適切なアプローチ、適切な理解、十分な経験を備えた Kubernetes を使用すると、問題を解決できます。

サーバーレスについて

— もう少し将来に目を向けると、展開の速度とアプリケーションの変更の速度により、インフラストラクチャの問題を解決しようとすると、サーバーレスなどの新しいソリューションが登場します。 この方向に可能性を感じますか?また、Kubernetes や同様のソリューションに対して危険性を感じますか?

ドミトリー: ここでもう一度言っておきますが、私は先を見て「こうなるだろう！」と言う予言者ではありません。 私も同じことをしただけなのに。 自分の足元を見ると、そこにはたくさんの問題が見えてきます。たとえば、コンピューター内でのトランジスタの動作などです。 面白いですよね？ CPU にいくつかのバグが発生しています。

サーバーレスを非常に信頼性が高く、安価で、効率的かつ便利にし、すべてのエコシステムの問題を解決します。 ここで私は、人類に耐障害性をもたらすために第二の惑星が必要であるというイーロン・マスクの意見に同意します。 彼が何を言っているのかは分かりませんが、私自身は火星に飛ぶ準備ができていないし、それは明日にもならないことは理解しています。

サーバーレスでは、これがイデオロギー的に正しいことであることは明らかです。人類にとっての耐障害性と同様、惑星が XNUMX つある方が XNUMX つよりも優れています。 しかし、今それをどうやって行うか？ 遠征を XNUMX つ派遣しても、それに集中すれば問題ありません。 数回の遠征隊を派遣し、数千人を定住させることも現実的だと思います。 しかし、それを完全にフォールトトレラントにして、人類の半分がそこに住むことは、今では不可能であり、検討されていないように思えます。

サーバーレスの 2019 対 2030 は素晴らしいものですが、2019 年の問題とはほど遠いです。 XNUMX 年が近づいています - それを見て生きましょう。 私たちが生きることに疑いはありません、私たちは間違いなく生きます（寝る前に繰り返します）が、今は他の問題を解決する必要があります。 それはおとぎ話のポニーの虹を信じるようなものです。 はい、事件の数パーセントは解決され、それらは完全に解決されますが、主観的には、サーバーレスは虹です...私にとって、このトピックはあまりにも遠いものであり、あまりにも理解できません。 話す準備ができていません。 XNUMX 年では、サーバーレスで単一のアプリケーションを作成することはできません。

Kubernetesはどのように進化するか

— 私たちがこの潜在的に素晴らしい遠い未来に向かって進む中で、Kubernetes とその周りのエコシステムはどのように発展すると思いますか?

ドミトリー：これについてはよく考えましたが、明確な答えがあります。 XNUMX つ目はステートフルです。結局のところ、ステートレスの方が簡単です。 Kubernetes は当初、これにさらに投資し、すべてはそこから始まりました。 ステートレスは Kubernetes でほぼ完璧に機能し、文句の付けようがありません。 まだまだ問題というかニュアンスがたくさんあります。 そこにあるものはすべて私たちにとってすでにうまく機能していますが、それは私たちなのです。 これがすべての人に効果をもたらすには、少なくともあと数年はかかるだろう。 これは計算された指標ではなく、私の頭の感覚です。

つまり、すべてのアプリケーションがステータスを保存し、ステートレス アプリケーションが存在しないため、ステートフルは非常に強力に開発されるはずであり、今後も開発されるでしょう。 これは幻想であり、常に何らかのデータベースとその他のものが必要になります。 ステートフルとは、可能な限りすべてを修正し、すべてのバグを修正し、現在直面しているすべての問題を改善することです。これを導入と呼びましょう。

未知のレベル、未解決の問題のレベル、何かに遭遇する確率のレベルは大幅に低下します。 これは重要な話です。 そして演算子 - 簡単なサービスを取得するための管理ロジック、制御ロジックの成文化に関連するすべて: MySQL 簡単サービス、RabbitMQ 簡単サービス、Memcache 簡単サービス - 一般に、動作を保証する必要があるこれらすべてのコンポーネントボックス。 これは、データベースは欲しいけど管理したくない、あるいは Kubernetes は欲しいけど管理したくないという悩みを解決するだけです。

このオペレーター開発のストーリーは、何らかの形で今後数年間で重要になるでしょう。

使いやすさは大幅に向上するはずです。ボックスはますます黒くなり、ますます信頼性が高まり、ますますシンプルなノブが追加されます。

私はかつて YouTube の「Saturday Night Live」で 80 年代のアイザック・アシモフの古いインタビューを聞いたことがあります。Urgant のような番組ですが、ただ興味深いだけです。 彼らは彼にコンピュータの将来について尋ねました。 未来はラジオと同じようにシンプルさの中にあると彼は言いました。 ラジオ受信機はもともと複雑なものでした。 波をキャッチするには、15 分間ノブを回し、串を回し、すべてがどのように機能するかを理解し、電波送信の物理学を理解する必要がありました。 その結果、ラジオにはノブが XNUMX つだけ残りました。

2019年の今、どんなラジオがあるでしょうか？ 車内では、ラジオ受信機がすべての電波と放送局の名前を検出します。 プロセスの物理的性質は 100 年間変わっていませんが、使いやすさは変わりました。 今だけでなく、すでに 1980 年にアジモフのインタビューがあったとき、誰もがラジオを使用しており、それがどのように機能するかなど誰も考えていませんでした。 それは常にうまくいきました - それは当然のことです。

するとアジモフは、それはコンピュータでも同じだろうと言いました。 使いやすさが高まります。 1980 年には、コンピューターのボタンを押すために訓練を受ける必要がありましたが、将来はそうではありません。

Kubernetes とインフラストラクチャによって、使いやすさも大幅に向上すると感じています。 私の意見では、これは明らかです - それは表面上にあります。

エンジニアはどうすればいいのでしょうか？

――では、Kubernetesを支えるエンジニアやシステム管理者はどうなるのでしょうか？

ドミトリー: 1C の出現後、会計士はどうなりましたか? ほぼ同じ。 これまでは紙に基づいて計算していましたが、現在はプログラムに組み込まれています。 労働生産性は桁違いに向上しましたが、労働自体がなくなったわけではありません。 以前は電球をねじ込むのに 10 人のエンジニアが必要でしたが、今では XNUMX 人で十分です。

ソフトウェアの量とタスクの数は、新しい DevOps が登場して効率が向上するよりも速い速度で増加しているように思えます。 現在、市場では特定の品薄状態が発生しており、それは長期にわたって続くでしょう。 その後、すべてはある種の正常な状態に戻り、作業の効率が向上し、サーバーレスがますます増え、ニューロンが Kubernetes に接続され、必要に応じてすべてのリソースが正確に選択され、一般的にはすべてを自分で行う必要があります。その人はただ立ち去り、干渉しません。

しかし、それでも誰かが決断を下す必要があるでしょう。 この人の資格や専門性のレベルが高いことは明らかです。 現在、経理部門では、手が疲れないように 10 人の従業員が帳簿を付ける必要はありません。 それは単純に必要ありません。 多くの文書は、電子文書管理システムによって自動的にスキャンされ、認識されます。 すでにはるかに優れたスキルと十分な理解を備えた、賢明な主任会計士が XNUMX 人いれば十分です。

一般に、これはすべての業界で採用されている方法です。 車も同じで、以前は車には整備士とドライバーが XNUMX 人いました。 今日、車の運転は、私たち全員が毎日参加する単純なプロセスです。 誰も車が複雑なものだとは思っていません。

DevOps やシステム エンジニアリングはどこにも行きません。高度な作業と効率が向上します。

――実際に仕事が増えるという興味深い話も聞きました。

ドミトリー：もちろん、百パーセントですよ！ なぜなら、私たちが作成するソフトウェアの量は常に増加しているからです。 ソフトウェアで解決できる問題の数は増え続けています。 仕事の量は増えています。 現在、DevOps市場はひどく過熱しています。 これは給与の期待値からもわかります。 良い意味で、詳細は省きますが、Xが欲しい後輩、1,5Xが欲しい中堅、2Xが欲しい先輩がいるはずです。 そして今、モスクワの DevOps 給与市場を見ると、後輩は X から 3 倍を望み、上級者は X から 3 倍を望んでいます。

どれくらいの費用がかかるのか誰も知りません。 給与水準はあなたの自信によって測られます。正直に言うと、市場はひどく過熱しています。

もちろん、この状況はすぐに変わります。ある程度の飽和が起こるはずです。 これはソフトウェア開発には当てはまりません。誰もが開発者を必要とし、誰もが優れた開発者を必要としているにもかかわらず、市場は誰に何の価値があるかを理解しています。業界は落ち着いています。 最近の DevOps ではそうではありません。

— 聞いたところによると、現在のシステム管理者はあまり心配する必要はないが、スキルを向上させて、明日はより多くの仕事が発生するが、より高度な資格が必要になるという事実に備える時期が来ているという結論に達しました。

ドミトリー： 百パーセント。 一般に、私たちは 2019 年に生きており、人生のルールは次のとおりです。 生涯学習 – 私たちは生涯を通して学びます。 今では誰もがすでにこのことを知っており、感じているように思えますが、知るだけでは十分ではなく、それをしなければなりません。 私たちは毎日変化しなければなりません。 そうしないと、遅かれ早かれ、私たちはこの職業から追い出されてしまうでしょう。

180 度の急カーブに備えてください。 私は、何かが根本的に変わるか、何か新しいものが発明される可能性を排除しません。それは起こります。 ホップ！ - そして私たちは今、違う行動をとります。 心配しないように備えておくことが重要です。 明日、私がやることすべてが不必要であることが判明するかもしれません-何も、私はこれまでずっと勉強してきたので、何か他のことを学ぶ準備ができています。 問題じゃない。 雇用の安定を恐れる必要はありませんが、常に新しいことを学ぶ準備をしておく必要があります。

願いとXNUMX分間の宣伝

-何か願いはありますか？

ドミトリー：はい、いくつかお願いがあります。

最初で商業的な - 購読する YouTube。 読者の皆様、YouTube にアクセスしてチャンネル登録してください。 約 XNUMX か月以内に、ビデオ サービスの積極的な拡張を開始します。Kubernetes に関するオープンで多様な教育コンテンツが多数用意されます。実践的な内容から、実験室に至るまで、深い基礎的な理論的な内容や、大学での Kubernetes の使用方法に至るまでです。原則とパターンのレベル。

XNUMX番目の商業的な願い - に行く GitHubの 私たちがそれを食べているので、星を付けます。 星をくれないと、食べるものがなくなってしまいます。 コンピュータゲームにおけるマナのようなものです。 私たちは何かをします、私たちはします、私たちは試みます、誰かがこれはひどい自転車だと言ったり、誰かがすべてが完全に間違っていると言ったりしますが、私たちは継続し、完全に正直に行動します。 私たちは問題を発見し、それを解決し、経験を共有します。 したがって、私たちに星を与えてください。それはあなたから消えることはありませんが、私たちが彼らを食べているので、それは私たちにやって来ます。

第三に、重要な、そしてもはや商業的な願いではありません - おとぎ話を信じるのをやめる。 あなたたちはプロフェッショナルです。 DevOps は非常に真剣で責任のある職業です。 職場で遊ぶのはやめましょう。 クリックしてみてください。そうすれば理解できるでしょう。 あなたが病院に来て、そこで医師があなたを実験していると想像してください。 これが誰かを不快にさせるかもしれないことは理解していますが、おそらくこれはあなたに関するものではなく、他の誰かに関するものです。 他の人にもやめるよう伝えてください。 これは私たち全員の生活を本当に台無しにします。多くの人が、運用、管理者、DevOps を、また何かを壊した奴らとして扱い始めます。 これは、ほとんどの場合、私たちが遊びに行ったという事実によって「壊れた」ものであり、これがどのようなものであり、それがどのようなものであるかを冷静に意識して見なかったという事実が原因です。

これは、実験してはいけないという意味ではありません。 私たちは実験する必要があります、私たちは自分たちでそれを行います。 正直に言うと、私たち自身も時々ゲームをします。もちろん、これは非常に悪いことですが、人間は私たちにとって異質なものではありません。 2019 年は、ゲームの本番ではなく、真剣でよく考え抜かれた実験の年であると宣言しましょう。 おそらくそうでしょう。

- どうもありがとうございます！

ドミトリー: ヴィタリーさん、お時間とインタビューに応じていただきありがとうございました。 読者の皆様、突然ここまでたどり着きましたが、誠にありがとうございます。 少なくともいくつかの考えをお届けできれば幸いです。

インタビューの中で、ドミトリーはワーフの問題について触れた。 これはほぼすべての問題を解決する万能のスイスナイフです。 しかし、必ずしもそうではありませんでした。 の上 DevOpsConf  お祭りで RIT++ Dmitry Stolyarov がこのツールについて詳しく説明します。 報告書の中で 「werf は Kubernetes の CI/CD 用ツールです」 Kubernetes の問題と隠されたニュアンス、これらの問題を解決するためのオプション、現在の werf 実装の詳細など、すべてが含まれます。 27 月 28 日と XNUMX 日にご参加ください。完璧なツールを作成します。

出所： habr.com