🆓 💃🏿 🗃️ 「Dockerはすでに死んでいる」またはあなたがDevopsについて知りたいが、尋ねることを恐れていたものは何でも ✨ 🔛 🚝

最近、7年の経験を持つDevOpsであり、DevOpsエンジニアのサンクトペテルブルクコミュニティの共同創設者であるAlexanderChistyakovがソーシャルネットワークで講演しました。

サーシャはこの分野のトップスピーカーの1人であり、Highload ++、RIT ++、PiterPy、Strikeのメインステージで演奏し、合計で少なくとも100件のレポートを作成しました。先週の月曜日、彼は視聴者からの質問に答え、彼の経験について話しました。

放送の録音とトランスクリプトを共有します。

私の名前はAlexanderChistyakovです。DevOpsエンジニアとして長年働いています。私は長い間、さまざまな企業にDevOpsプラクティスの実装、最新のDevOpsツールの使用、およびインフラストラクチャの編成についてアドバイスを提供してきました。

主に外国企業に相談しました。

人々が日常の練習でKubernetesをどのように使用するか、なぜそれが必要なのか、なぜそれを恐れてはいけないのか、何に注意を払うべきか、そして次に何が起こるのかについて話します。

sysadmin、DevOpsエンジニア、CIO、およびその他のインフラストラクチャマネージャー（およびサポーター）が役立つと思います。

この風景はどのように発展しましたか？ ROM Basicがインストールされているコンピューターを覚えていますが、OSがインストールされていなくてもプログラムを作成することができました。それ以来、橋の下にはたくさんの水が流れてきました。最初は、OS自体はありませんでした（より正確には、アセンブラーで記述されていました）。その後、C言語が登場し、状況は劇的に改善しました。もちろん、今ではOSの概念に精通しています。これは、カスタムアプリケーションを実行し、このコンピューターにあるリソースを管理できるプラットフォームです。または他の人、それが配布されている場合。それでも、ラップトップとデスクトップから高性能コンピューティングクラスターを組み立てることは可能でした。これは、学生が1997年にサンクトペテルブルク工科大学の寮で行ったことです。

その後、10年前にこの記事を読んだと思いますが、Webメールを発明したGoogleは、ユーザーがタブレットや電話から使用できるように、このWebメールを中心にオペレーティングシステムを構築していることがわかりました。これは予想外のことでした。通常、オペレーティングシステムはバイナリを実行するものであり、ブラウザでアプリケーションを見ると、バイナリが存在するかどうかさえわかりません。メールを読んだり、オンラインメッセンジャーでチャットしたり、スライドを描いたり、ドキュメントを一緒に編集したりできます。これは多くの人に適していることがわかりました。

確かに、Googleはあまり一貫性がなく、不要でプロトタイプを超えない多くの製品を作成しました。たとえば、GoogleWaveです。ええと、これはどんな大企業の方針でもあります-会社が存在しなくなるまで、迅速に動き、頻繁に崩壊することです。

それにもかかわらず、大衆の意識の中で、OSは、かつていくつかの基準設定委員会によって承認されて割り当てられたサービスを提供せず、単にユーザーのニーズを満たすプラットフォームとしてのOSの概念にシフトしています。これらのニーズは何ですか？

開発者に何を書いているのかを尋ねるのが通例でした。 C ++スペシャリスト（おそらく、そして今どこかにいる）がいましたが、今では多くのPHPスペシャリスト（彼らは時々自分自身を笑う）と多くのJavaScript開発者がいます。 PHPの知識を持つ人々が切り替えたGoLang言語であるTypescriptが今人気を集めています。 Ruby言語であるPerl言語（おそらくまだ残っていますが、人気が大幅に失われています）がありました。一般に、アプリケーションは何でも書くことができます。あなたが現実の世界に住んでいるなら、あなたはおそらくそれらが何でも書かれているという事実に出くわしたでしょう：Javascript、Rust、C;名前を思い付く-何かがそれに書かれていました。

そして、これをすべて活用する必要があります。このような異種システムでは、第一に、専門家が異なる言語で開発する必要があり、第二に、快適な環境でサービスを開始し、そのライフサイクルを監視できるプラットフォームが必要であることが判明しました。このプラットフォームには特定の契約があり、現代の世界では次のようになっています。コンテナイメージがあります（コンテナ管理システムはどこにでもあります-Dockerですが、良いことは何も言えません。問題については後で説明します）。

人類が特定の進化の過程に沿って動いているという事実にもかかわらず、この過程には収束があります。私たちの業界では、誰かがまだPerlで（mod_perl Apacheの下で）コードを書いていて、誰かがすでにGoLangでマイクロサービスアーキテクチャを書いていることがわかりました。プラットフォームとの契約は非常に重要であり、プラットフォームの内容は非常に重要であり、プラットフォームが人を助けることが非常に重要であることが判明しました。サービスを終了して開始するために手動操作を行うと、非常にコストがかかります。 20のサービスがあるプロジェクトに出くわしましたが、それほど大きなプロジェクトではありませんでした。私は千の異なるサービスを持っている人について聞いたことがあります。 20は通常の量です。また、サービスの各セットは、独自のチームによって独自の言語で開発されており、交換プロトコルによってのみ接続されています。

アプリケーションの契約がどのように機能するかに関して。「12要素のアプリケーションマニフェスト」があります。これは、使いやすいようにアプリケーションをどのように配置するかについての12のルールです。私は彼が嫌い。特に、環境変数を介して構成を提供する必要があると書かれています。たとえば、Amazonでは、Elastic Beanstalkに渡すことができる環境変数の数がLinuxカーネルの1ページ（4キロバイト）であるという事実に繰り返し遭遇しました。そして、それらは非常に速くオーバーフローします。 80の異なる変数がある場合、81は固執するのが難しいです。さらに、それはフラットな構成スペースです。変数がある場合、それらはアンダースコア付きの大文字で名前を付ける必要があり、それらの間に階層はありません。何が起こっているのか理解するのは難しいです。私はまだこれに対処する方法を理解していません、そして私はそれについて議論する人がいません-愛好家のグループはありません、誰がそのようなアプローチに反対するでしょう。これが突然誰かにも合わない場合-私に書いてください（テレグラムのデメリオレーター）、私は私が一人ではないことを知っています。私は絶対にそれが好きではありません。管理が難しく、階層データを転送するのが困難です。現代のエンジニアの仕事は、変数がどこにあるか、それらが何を意味するか、それらが正しく設定されているかどうか、それらを変更するのがどれほど簡単かを知ることであることがわかりました。古き良き構成ルールの方が良かったと思います。それらが正しく設定されているかどうか、それらを変更するのはどれほど簡単か。古き良き構成ルールの方が良かったと思います。それらが正しく設定されているかどうか、それらを変更するのはどれほど簡単か。古き良き構成ルールの方が良かったと思います。

契約に戻る。 Dockerイメージが必要であることが判明しました。Docker自体が必要になります（Docker自体は貧弱ですが、一部のMicrosoftがそれらを購入し、通常どおりに埋めるか開発することを期待しています）。 Dockerに満足できない場合は、RedHatのスタックを試すことができます。彼については何も言えませんが、バニラのクベルネテスよりはましだと思います。 Red Hatのスタッフは、セキュリティの問題にもっと注意を払っています。通常の権利の分離を使用して、マルチターンインストール、マルチユーザー、マルチクライアントを実行する方法さえ知っています。一般に、権利管理が適切に行われていることを確認します。

セキュリティの問題について詳しく見ていきましょう。 Kubernetesだけでなく、どこでも彼女にとって悪いことです。コンテナのセキュリティとオーケストレーションについて言えば、サーバー側で行われるWebアセンブリに大きな期待を寄せています。また、Webアセンブリアプリケーションの場合、リソース消費を制限することができ、システム呼び出しをRustの特別なコンテナに関連付けることができます。これは、セキュリティの質問に対する良い答えになります。そして、Kubernetesにはセキュリティがありません。

アプリケーションがあるとしましょう。これはDockerイメージであり、12ファクターです。つまり、環境変数から、コンテナー内にマウントするファイルから構成を取得できます。起動できます。内部では自給自足で、構成を介して他のアプリケーションと自動的にリンクすることができます。そして、ログを標準出力に書き込む必要があります。これはおそらく最も悪意のないものです。コンテナがログをファイルに書き込む場合、そこから収集するのは非常に簡単ではありません。 Nginxにパッチが適用され、コンテナの標準出力からログを収集できるようになりましたが、これは許容範囲です（パラメータを介して構成を渡すのとは対照的です）。実際、以前はいくつかのオーケストレーターがいました。Rancher、Marathon Mesos、Nomad。しかし、アンナ・カレニーナの原則が技術システムに関連して言うように、複雑な技術システムも同じように配置されています。

Kubernetesを使用すると、Boeing 737 MAXを使用する航空会社と同じ状況になります。エラーがあるため飛行しませんが、設計が非常に複雑であるため、他には何もありません。 GoLang言語のように、構文があり、その上に何もない場合、YAML形式で制御するのが好きだとは言えません。書き込み内容のチェックも、データタイプもありません。 Kubernetesで構成を適用する前に行うすべてのチェックは基本です。間違った構成を適用しようとすると、問題なく適用され、何がわからない場合があります。間違った設定ファイルを書くのは非常に簡単です。これは大きな問題であり、人々はすでに、Typescriptでさえも、Kotlin言語のDSLとKubernetesを使用してゆっくりと解決し始めています。そのようなプルミプロジェクトがあります、AmazonプロジェクトEKSがあります-それはAmazonにもっと焦点を合わせていますが; PulumiはTerraformであり、Typescriptのみです。未来だと思っているので、まだプルミを試してみたかったです。構成は、強力な静的型付けを使用してプログラミング言語で記述する必要があります。これにより、クラスターを破壊する可能性のある使用前に、少なくともコンパイル時にこれは不可能であると通知されます。

したがって、現時点ではオーケストレーターは1人だけです。何人かのMATAユーザーが残っていることを知っています。私は彼らの手を振っています。他の誰もDockerSwarmを使用していないことを願っています-それに関する私の経験はかなり否定的でした。それ以外の可能性があると思いますが、理由はわかりません。 Docker Swarmがこれ以上開発されることはないと思いますし、それをリリースする人々が今それを使って何かをするつもりはないと思います。資本主義;あなたがお金を稼がなければ、開発に費やすものは何もありません-そして彼らの会社は過去2年間、スタートアップにとって「死の谷」にありました：誰も彼らにお金を与えたくないのです。誰が購入するかについて入札することができます。マイクロソフトは興味がありませんでした。 Dockerが生き残った場合、Microfocusがそれを行うかもしれません。

Kubernetesが1つしか残っていないので、それについて話しましょう。彼の5つのバイナリのペンタグラムが付いた美しい写真があります。 Kubernetesは非常に単純で、5つのバイナリしかないと書かれています。しかし、私は、システムがコンパイルされるバイナリの数と、システムのコアを構成するサービスの数で、システムの複雑さを測定することにはほど遠いです。バイナリがいくつあるかは関係ありません。重要なのは、Kubernetesが実行できることと、内部でどのように機能するかです。

彼は何ができる？あなたが仕事で何をしたかを5歳の子供に説明する必要があると想像してみてください。そして今、Ansibleでプレイブックと役割を書き込もうとしたお父さんは、ホスト上のNginxと、tv-ansible以外に登録されていないコンテナのセットに基づいて、青緑色の展開を実行できるようになりました。あなた自身のKubernetesを作る時が来ました。それはうまく機能しません、それは十分にテストされていません、私はそれをよく理解していません、私はすべての境界条件を知りません、それは同じマシン内で機能します、しかしそれは私のものです！」私はこれを何度も不当に見ました-私はそれを2、3回見ただけで、2回このようなものを書くことに参加しました。遅かれ早かれ、これに参加する人は、4回目はあってはならないことに気づきます。それは私の車の友達のようなものですかつてVAZ-2101を復元した人は、電源ウィンドウを取り付け、群れで内部を修理し、金属で塗装しました。独自のオーケストレーターを作成するのはこのようなものです。一度試してみることもできますが、愛好家だけでなく、すべての人におすすめする準備はできていません。したがって、ライフサイクル管理、コンテナ状態管理はKubernetesのタスクです。

彼は、リソースがあるノードでコンテナが実行されていることを確認でき、デッドコンテナを再起動できます。コンテナが起動しない場合、新しい展開がある場合にトラフィックがそのコンテナに移動しないことを確認できます。また、KubernetesがOSであると言うことから始めました。 OSがある場所には、パッケージマネージャーが必要です。 Kubernetesが始まったとき、オブジェクトの説明は不可欠でした。ステートフルセットとコードの説明は直接機能する説明であり、[???の状態を作成するには、その上に何かを追加する必要があります。 18：52-グリッチの記録]。実際、Ansibleや他の同様の構成管理システムとの根本的な違いは、Kubernetesでは、どうなるかではなく、何が起こるかを説明していることです。あなたは自然に説明しますあなたが持っているオブジェクトとそれらが持っているプロパティ。オブジェクトは、サービス、デプロイメント、デーモンセット、ステートフルセットです。標準で作成できるオブジェクトに加えて、Kubernetesで記述および作成できるカスタムオブジェクトもあるのは興味深いことです。とても便利です。また、sysadminsおよびdevopsエンジニアのランクが大幅に低下します。

Kubernetesはいつ死ぬのですか？

良い質問。「死ぬ」という言葉の意味によって異なります。これがDockerです-1年前にサンクトペテルブルクでの会議に集まり、円卓会議があり、私たちは一緒に決定しました（私たちは業界であるため、そこには資格のある過半数がいたと思います、そして私たちは皆のために話す余裕がありました）すでに死んだ。どうして？カンファレンスではDockerについての話はありませんでしたが、それほど古いものではありませんでした。誰も彼について何も言わなかった。Kubernetesについて、次のステップについて話しました。たとえば、Kube Flowは、演算子の使用について、Kubernetesベースの配置方法について話しました。Docker以外のもの。これは死です-あなたが生きているように見えるほどひどいのに、誰もあなたのところに来ないとき。

Dockerはすでに死んでいます。Kubernetesが死ぬと-5年待ちましょう。死ぬことはなく、誰もがそれを手に入れるでしょう-それはTeslaの中、あなたの電話の中、どこにでもあり、誰もそれについて話すことに興味がありません。これは死だと思います。たぶん5年後ではなく、3年後です。もう1つの質問は、それを置き換えるものです。おそらくDevOpsの世界からではなく、誰もが話題にする大音量の新しいテクノロジーです。今、彼らは会話を続けるためだけでもKubernetesについて話します、そしてそれは大丈夫です-それはファッショナブルです。

Dockerの何が問題になっていますか？

すべて。これは、すべてを管理するための単一のバイナリです。これは、システムで起動する必要があるサービスです。これは、ソケットを介して制御される部分でもあります。これは、私が思うに、誰もレビューしていないコードがたくさんある製品です。これは、概して、企業の資金がない製品です。レッドハットには非常に賢い人々がいます。私は彼らをとても尊敬しています。平均的なエンジニアであれば、今後5年間の展望を定義する可能性があるため、彼らが何をしているかを確認する必要があります。さて、RedHatはDockerを完全に捨てました。彼らは彼がいない方向に動いています。これまでのところ、彼らはこれを最後まで行うことはできませんが、彼らは近くにあり、遅かれ早かれ彼らはDockerを終了するでしょう。彼は、私がリストしたすべてのものに加えて、巨大な攻撃領域を持っています。そこにはセキュリティがありません。その上で発生したCVEはそれほど多くありませんが、それらを見ると、安全性が最前線にない他のプロジェクトと同様に、それは残りのベースで処理されます。これが法律です。セキュリティは長く、高価で、退屈で、開発者を制限し、人生を非常に複雑にします。安全を正しく行うことは大変な作業であり、あなたはそれに対してお金を払わなければなりません。セキュリティの専門家と話すと、資格に関係なく、Dockerについての恐ろしい話や悪いことについての話をたくさん聞くことができます。それらは、一部はDocker自体、一部はそれを操作する人々に関連していますが、Docker自体は人々を助け、内部でいくつかのセキュリティチェックを実行する可能性があります。たとえば、明示的に指示されない限り、ルートからコンテナ内のプロセスを開始しないでください。開発者を制限し、人生を非常に困難にします。安全を正しく行うことは大変な作業であり、あなたはそれに対してお金を払わなければなりません。セキュリティの専門家と話すと、資格に関係なく、Dockerについての恐ろしい話や悪いことについての話をたくさん聞くことができます。それらは部分的にDocker自体、部分的にそれを操作する人々と接続されていますが、Docker自体は人々を助け、それ自体の内部でいくつかのセキュリティチェックを実行することができます。たとえば、明示的に指示されない限り、ルートからコンテナ内のプロセスを開始しないでください。開発者を制限し、人生を非常に困難にします。安全を正しく行うことは大変な作業であり、あなたはそれに対してお金を払わなければなりません。セキュリティの専門家と話すと、資格に関係なく、Dockerについての恐ろしい話や悪いことについての話をたくさん聞くことができます。それらは、一部はDocker自体、一部はそれを操作する人々に関連していますが、Docker自体は人々を助け、内部でいくつかのセキュリティチェックを実行する可能性があります。たとえば、明示的に指示されない限り、ルートからコンテナ内のプロセスを開始しないでください。部分的に-それを悪用する人々と一緒ですが、Docker自体が人々を助け、それ自体の内部でいくつかのセキュリティチェックを実行する可能性があります。たとえば、明示的に指示されない限り、ルートからコンテナ内のプロセスを開始しないでください。部分的に-それを悪用する人々と一緒ですが、Docker自体が人々を助け、それ自体の内部でいくつかのセキュリティチェックを実行する可能性があります。たとえば、明示的に指示されない限り、ルートからコンテナ内のプロセスを開始しないでください。

状態を保存する方法は？Kubernetesでデータベースをホストできますか？

DBA、またはこのデータベースをKubernetesに配置することを決定する前に、このデータベースのインフラストラクチャの責任者に尋ねると、その人は「いいえ」と答えます。多くの円卓会議で、Kubernetesにはデータベースがあってはならないと言われると思います。それは難しく、信頼性が低く、管理方法が明確ではありません。

KubernetesのDBを代表できると思います。それはどれくらい信頼できますか？さて、見てください。私たちは分散システムを扱っています。データベースをクラスターに配置するときは、フォールトトレランスの要件があることを理解する必要があります。このような要件がある場合、Kubernetes内に配置するのはデータベースクラスターである可能性があります。現代の世界で、通常のデータベースクラスターを作成する方法を知っている人は何人いますか？多くのデータベースがクラスタリング機能を提供していますか？ここから、データベースを従来のリレーショナルと非リレーショナルに分割し始めます。それらの違いは、後者が何らかの形でSQLをサポートしていないということではありません。違いは、非リレーショナルデータベースは、元々データベースが分散されるように作成されているため、クラスターでの作業にはるかに適していることです。したがって、一部のMongoDBまたはCassandraで、Kubernetesでホスティングを行いたい場合、私はあなたを思いとどまらせることはできませんが、次に何が起こるかについて非常に良い考えを持っている必要があります。データがどこにあるか、障害と回復が発生した場合に何が起こるか、バックアップがどのように行われるか、回復ポイントがどこにあるか、回復にかかる時間をよく理解する必要があります。これらの質問はKubernetesには関係ありません。それらは、基本的に従来のデータベースに基づいたクラスターソリューションの運用方法と関係があります。 NoSQLソリューションを使用すると簡単になり、すぐにクラウドに対応します。復元ポイントはどこにあり、復元にかかる時間はどこですか。これらの質問はKubernetesには関係ありません。それらは、基本的に従来のデータベースに基づいたクラスターソリューションの運用方法と関係があります。 NoSQLソリューションを使用すると簡単になり、すぐにクラウドに対応します。復元ポイントはどこにあり、復元にかかる時間はどこですか。これらの質問はKubernetesには関係ありません。これらは、基本的に従来のデータベースに基づくクラスターソリューションの運用方法と関係があります。 NoSQLソリューションを使用すると簡単になり、すぐにクラウドに対応します。

しかし、それでも疑問が生じます-なぜデータベースをKubernetesに置くのですか？プロバイダーが提供する管理ソリューションであるサービスを利用できます。 AmazonからRDSを取得し、Googleから管理対象データベースを取得することもできます。そして、このデータベースの地理的に分散したクラスターでさえ、Amazonの場合、これはAuroraであり、インストールして使用することができます。ただし、地理的に分散したベースのクラスターをインストールする場合は、ドキュメントを注意深く読んでください。単一のノードを持つAuroraクラスターに出くわしました—それらは2つの領域に分割されていませんでした。さらに、2番目の領域はまったく必要ありませんでした。一般に、人々は頭の中で非常に奇妙なことを持っています。彼らは、主なことは製品を選択することであると信じています。そうすれば、それはそれ自体を提供し、期待どおりに機能します。番号。リレーショナルデータベースは、通常のクラスターでもまったく機能する準備ができていませんでした。地理的に分散していることは言うまでもありません。したがって、それらに基づいて複雑なことをしている場合は、ドキュメントを確認してください。

基本的に、私はKubernetes内でデータベースを操作した経験があります。何も悪いことはありませんでした。ノードの落下に関連するいくつかのクラッシュがありました。別のノードへの移動は正常に機能しました。すべてが管理されています。私があなたを喜ばせず、毎秒何千ものリクエストがあったと言うことができない唯一のこと。

中規模または小規模のソリューションがある場合（ロシアの平均的なソリューションは、レンタのような大規模な報道機関にほぼ対応します）、データベースへの複雑なクエリが多数あるべきではありません。ベースが失敗した場合、おそらく何か間違ったことをしているので、それについて考える必要があります。不用意にスケールアップしないでください。非クラスター化ソリューションをクラスターに移動することには利点がありますが、多くの欠点もあります。特に、PatroniまたはStalloneに基づくpostgresクラスターを使用する場合はそうです。多くの境界条件があります。私はそれらに出くわしていませんが、DataEgretの同僚がそれがどのように発生するかについて喜んで教えてくれます。考えずにベースをクラスターに転送しようとするとどうなるかについて、AlexeiLesovskyによる素晴らしいレポートがあります。

1秒あたり約数千のリクエスト。 DBインスタンスが1つしかない場合でも、1秒あたり数千のリクエストでそれを調整してもスケールアップします。遅かれ早かれ、あなたは問題にぶつかるでしょう。重い負荷が計画されている場合は、水平スケーリングオプションを検討する方がよいように思われます。データベースで最大のテーブルを見つけ、そこに何があるかを確認し、それを非リレーショナルストレージに移動できるかどうかを検討します。リレーショナルデータベースに通常保存しているものを保存しない方法を考えてください。たとえば、システムへのアクセスログはたくさんあり、通常はキー値ストレージにアクセスするのと同じパターンに従ってアクセスします。 ..。では、Cassandraにログを書き込んでみませんか？これは建築家への質問です。 Kubernetesで小さくてあまり忙しくないベースインスタンスを維持することは非常に重要ですオペレーターの魔法がそれに責任を持ち始めるからです。

基本的に、KubernetesがOSおよびプラットフォームとして何であるかを見ると、これは自分で行うコンストラクターです。状態をディスクに保存したり、テレメトリを整理したり、監視したり、警告したりする機能など、マイクロサービスアーキテクチャを構築するためのすべてがあります。これは、KubernetesパッケージマネージャーのHelmによって行われます。インターネット上には、公開されているオープンソースのヘルムチャートが多数あります。プロジェクトのインフラストラクチャを強化する最も簡単な方法は、アプリケーション、サービスを配置するHelm Chartを使用することです。このサービスが、Redisデータベース、PostgreSQL、Patroniの場合は、何でもかまいません。構成を開始し、この構成を適用します。それは完全に宣言的です。予見できるものは何でも、ヘルムチャートの作者は通常提供します。アプリケーションはHelmでもリリースするのが最適です。3番目のヘルムにはクラスター側のサービスは含まれていません。 2番目のサービスには、クラスター管理者からのサービスが常に機能しており、名前空間ごとにリリースを配布する必要がありましたが、3番目のHelmはこのセキュリティホールを閉じました。

Helmは、GoLangテンプレート構文に基づくそのようなテンプレートエンジンです。それは非平面構造である変数のリストを取ります（神に感謝します、それは階層的です-YAMLで書かれています）。 Helmを使用すると、これらの変数はHelmテンプレートの適切な場所に配置され、すべてをいくつかの名前名に適用し、そこでコード、サービスを起動し、役割を作成します。意識を取り戻さずにヘルムチャートを書くことができる足場ジェネレーターがあります。私が気に入らないのは、Helm自体のGoLangテンプレートブランチと条件付きブランチの構文を知る必要があることだけです。それらは、接頭辞表記を使用して、lispの原則に従って作成されます。他の誰かがそれを好きなのは良いことですが、それは毎回頭を切り替えます。さて、私たちはそれを乗り越えます。

次に何が起こるかについて少し説明します。私はすでにオペレーターに似ていました。これらは、Kubernetesクラスター内に存在し、別のより大きなアプリケーションのライフサイクルを管理するサービスです。十分に難しい。オペレーターは、シリコンホームサイトの信頼性エンジニアと考えることができます。確かに将来、人々はますます多くのオペレーターを書くでしょう。なぜなら、誰もNagiosのスケジュールに従い、停止に気づき、手動のアクションをとる第1サポートレベルの人々の変更を維持したくないからです。オペレーターは、どのシステム状態が可能であるかを理解しています。それは州の機械です。これで、GoLang言語などで記述された人間の知識の集中がコンパイルされ、クラスターに入れられ、多くの作業が実行されます。ノードの追加または削除、再構成、落ちたノードの上昇の確認、データが目的のコードにドッキングするようにします。一般に、その下にインストールされているもののライフサイクルを管理します。オペレーターは文字通りすべてのものになりました。 Rook演算子を使用して、sevをKubernetesクラスターに直接配置するという事実を楽しんでいます。私はこれがどのように起こっているかを見て、とても嬉しく思います。もっと多くのオペレーターが必要だと思います。私たち全員がそれらのテストに参加する必要があります。他人のオペレーターを修正するために費やす時間は、人類への贈り物です。同じ仕事を何度も繰り返す必要はもうありません。あなたはこの仕事をリポジトリに疎外された形で置くことができます、そしてそれからスマートなプログラムがあなたのためにそれをします-それは幸福ではありませんか？オペレーターは文字通りすべてのものになりました。 Rook演算子を使用して、sevをKubernetesクラスターに直接配置することで楽しんでいます。私はこれがどのように起こっているかを見ました、そして私はとても幸せです、そして私はより多くのオペレーターが必要であると思います、そして私たちは皆彼らのテストに参加するべきです。他人のオペレーターを修正するために費やす時間は、人類への贈り物です。同じ仕事を何度も繰り返す必要はもうありません。あなたはこの仕事をリポジトリに疎外された形で置くことができます、そしてそれからスマートなプログラムがあなたのためにそれをします-それは幸福ではありませんか？オペレーターは文字通りすべてのものになりました。 Rook演算子を使用して、sevをKubernetesクラスターに直接配置するという事実を楽しんでいます。私はこれがどのように起こっているかを見て、非常に満足しています。より多くのオペレーターが必要であり、私たち全員がそれらのテストに参加する必要があると思います。他人のオペレーターを修正するために費やす時間は、人類への贈り物です。同じ仕事を何度も繰り返す必要はもうありません。あなたはこの仕事をリポジトリに疎外された形で置くことができます、そしてそれからスマートなプログラムがあなたのためにそれをします-それは幸福ではありませんか？他人のオペレーターの修正に費やすのは人類への贈り物です。同じ仕事を何度も繰り返す必要はもうありません。あなたはこの仕事をリポジトリに疎外された形で置くことができます、そしてそれからスマートなプログラムがあなたのためにそれをします-それは幸福ではありませんか？他人のオペレーターの修正に費やすのは人類への贈り物です。同じ仕事を何度も繰り返す必要はもうありません。あなたはこの仕事をリポジトリに疎外された形で置くことができます、そしてそれからスマートなプログラムがあなたのためにそれをします-それは幸福ではありませんか？

私はRedHatの本をダウンロードしました-彼らはそれを無料で配布します-Kubernetesオペレーターがどのように働くかそしてあなた自身を書く方法について、私はあなたが彼らのウェブサイトに行ってそれもダウンロードすることをお勧めします、本はとても面白いです。全部読んだら、オペレーターを一緒に分析できるかもしれません。

誰が群れをサポートしますか？Docker Inc以外に？

誰も。そしてDockerInc。すでに半分に引き裂かれ、半分はどこかで売られました。私は彼らに何が起こっているのかを追跡しません。かつて彼らは製品をモビと呼んでいましたが、それはオープンソースバージョンでした。つまり、オープンバージョンではありませんでした。そして、何かが権利を持って売られましたが、何かは売られませんでした。私にとって、それは「患者が死ぬ前に汗を流した」ように見えます-人々は何とかして投資されたお金を引き出そうとしています。一般的に、誰もそれをサポートしていません。

マスター/スレーブ

できます。マスター/スレーブがリレーショナルデータベースでの動作を停止すると、世界はそこで終了します。Kubernetesは、データベースの操作を一切妨害しません。それがもたらす唯一のものは、必要に応じて無効にすることができるさまざまなヘルスチェックと、原則として、状態管理です。無効にしないことをお勧めします。データベースを管理するオペレーターは、その状態を確認する必要があります。

レッドハットの本の名前は何ですか？

KubernetesOperatorsはそれと呼ばれています。そこにアヒルが描かれています。O'Reillyの本は、表紙を再設計しました。かなりの数の本がRedHatと共同で出版されています。Red Hatには、無料でダウンロードできるKubernetesの本が3〜4冊あります。たとえば、Kubernetes Patterns、gRPCなどです。gRPCプロトコルは、Kubernetesに直接関連していませんが、マイクロサービス間でデータを交換するために多くの人に使用されています。さらに、Envoyなどの次世代ロードバランサーでも使用されます。

SRAとは何ですか？

これは、分散システムで発生する変更の時間枠を理解しているような人です。大まかに言えば、彼はあなたが今月どのくらい横になっていたか、どれだけ多くのことができるか、あなたがリリースの許可を与えることができるかどうかを理解しています。 24時間年中無休で機能する必要がある産業用アプリケーションのバックアップ、リカバリプラン、災害リカバリの問題、インフラストラクチャのメンテナンスの問題からキーを管理します。アプリケーションメトリックには、アプリケーションの状態とビジネス状態のメトリックがあります。つまり、待ち時間、場所、および要求の数です。それらの同じ4つの金の信号。さらに、SRAは、これらのメトリックに基づいて、システムを戦闘準備に戻すための措置を講じることができます。彼はこれを行う方法について計画を立てています。何らかの理由で、これは従来のDevOpsからは必要ありません。これは、開発者がアプリケーションをリリースするのに役立ち、通常はどこかにロールアウトするのに役立ちます。また、SRAは、さまざまな側からの要求の流れにも抵抗します。

私はセキュリティについて話すことを約束しました。ご存知のように、これはKubernetesではかなり若いトピックです。私は非常に基本的なことしか知りません。たとえば、ルートからサービスでアプリケーションを実行しないでください。これが発生するとすぐに、名前名、スーパーユーザー権限のすべてにアクセスでき、ホストシステムのコアを壊そうとする可能性があります。おそらくそれはうまくいくでしょう（そしてルートから他の操作を実行します）。ハッカーにそのようなヒントを与えないでください。可能であれば、ユーザーにできるだけ少ない権限を与え、ユーザー入力を適切に処理します。 Kubernetesのセキュリティについて話す場合、現在の閉回路のどこかでそれを取り除く必要があるように思われます。または、本当にセキュリティの問題に取り組みたい場合は、Ciliumプロジェクトを確認する必要があります。彼はサージプロテクターの使い方を知っています、BPFベースのネットワークトラフィックの差別化-これはiptablesよりもうまく機能します。これが未来です。カリフォルニア以外では誰も実際に使用していないように思えますが、すでに開始できます。他のプロジェクトがあるかもしれませんが、私はそれを疑っています。一般的に、人類には働く手がほとんどありません。

したがって、セキュリティについて特別なことは何も言いません。 Kubernetesのマウントされたテナンシーにはさまざまなオプションがありますが、鉛筆を持って座って、人々が何をしたか、どのような脆弱性を閉じたか、それが理にかなっているかどうか、脅威モデルに適用できるかどうかを把握する必要があります。ちなみに、脅威モデルがどのように構築されているかについての説明を探して、自分で構築することから始めることをお勧めします。多かれ少なかれ正式な方法があります。描いて見てみると、洞察が生まれ、現在の状況で何が必要で何が不要かがわかるでしょう。たぶん、すべてのKubernetesを閉ループに追い込むのに十分でしょう。ちなみに、これは正しい決定です。私はこれに出くわしました、そしてそれは不可解です。時計にパスを提示するだけでシステムにアクセスでき、内部にインターネットがなく、交換が特別なゲートウェイを経由する場合、DMZにあり、異常に記述されているために破損するのは困難です。これは、十分に保護されたシステムです。技術的な手段でこれを行う方法-まあ、あなたはソリューションの現在の市場を監視する必要があります。それは大きく変化しており、セキュリティはホットなトピックです。なりたいと思っているプレイヤーはたくさんいますが、嘘をついているプレイヤーとそうでないプレイヤーはどれですか？私は言うとは思いません。レッドハットは嘘をついていない可能性が高いですが、誰よりも進んでいるわけではありません。まだはっきりしていないので、あなたはただ研究をする必要があります（そして私も）。まだはっきりしていないので、あなたはただ研究をする必要があります（そして私も）。まだはっきりしていないので、あなたはただ研究をする必要があります（そして私も）。

Kubernetesクラスターが他に何を持っているべきかについて話しましょう。そこに無料でアプリケーションをインストールする機会があり、データベースをそこに保存することを恐れないので。ちなみに、Managed Kubernetesを使用している場合は、データベースをどこに保存するかについては疑問の余地はありません。ManagedKubernetesをホストするクラウドから、何らかの形（多くの場合、ブロックデバイスの形式）で障害耐性のあるストレージが持ち込まれます。このストレージのディスクをクラスターに安全に配置し、スナップショットを使用して一貫性のあるバックアップを作成できます。スナップショットはバックアップではないことを忘れないでください。スナップショットをどこかにコピーする必要もあります。これは明らかですが、忘れられないように、明白なことを繰り返すのは良いことです。

マイクロサービスアーキテクチャプラットフォームを使用している場合は、追跡可能で監視可能にすることが非常に重要です。これにより、リクエストがどこにあり、どこで時間を浪費しているのかなどを理解できます。このようなプラットフォームを構築するのは大変な作業です。 Prometheusが必要になります。これはCloudNative Computing Foundationプロジェクトであるため、必要になります。 Kubernetesを監視するために特別に設計されています。膨大な数のエクスポーター、メトリクスコレクターが含まれています。一部のアプリケーションには、すべてのダッシュボードがネイティブに含まれています。アプリケーションにそれらが含まれていない場合、長寿命のPrometheusダッシュボードアプリケーションに接続するのに20分かかります。どういうわけか誰もそれを付けませんが。私の経験では、これは人々が製品をクラウドに保管しているためです。 Amazon CloudWatch、Google StackDriver、そこに同じ方法でメトリックを送信できますが、コストがかかります。つまり、人々がまだインフラストラクチャにお金を払っている場合、彼らはそれに接続されている監視ツールにお金を払っています。それでも、Prometheusは、メトリックを取得する場所が複数ある場合、クラウドが1つの場所にない場合、ハイブリッドである場合、オンプレミスマシンがあり、一元化されたインフラストラクチャが必要な場合に非常に便利です。次に、プロメテウスがあなたの選択です。オンプレミスマシンがあり、一元化されたインフラストラクチャが必要な場合。次に、プロメテウスがあなたの選択です。オンプレミスマシンがあり、一元化されたインフラストラクチャが必要な場合。次に、プロメテウスがあなたの選択です。

他に何か要りますか？ Prometheusがある場所には、AlertManagerも必要であることは明らかです。また、リクエストのある種の分散トレースも必要です。 Kubernetesでこれを行う方法-まあ、イェーガー、ジプキン、または現在一番上にあるもののようないくつかの製品を取ります。また、トレースを保存するためのCassandra、それらをレンダリングするためのGrafana。私の知る限り、この機能は最近Grafanaに登場しましたが、これは実装しない理由ではありません。つまり、アプリケーションが[glitches 49:14]（持っている？）環境を手動で組み立てることができます。このランタイムまでに、分散トレースの構築、視覚化に適したカウンターとその他のメトリックの両方があります。アプリケーションはどこでどのくらいの時間を費やしますか？

それについて話すことはそれを示すことよりも不便ですが、今私に示すことは何もありません。私は今私の研究室にこれのどれも持っていません。いつか私はおそらく準備をします。

伝えたいことはすべて言ったと思います。主な規定をもう一度繰り返します。

1つ目：Kubernetesを使用すると、Ansible Engine Xで1つのコンテナを別のコンテナにフェイルセーフに交換するメカニズムを作成する必要がなくなります。2つ

目：Kubernetesはどこにも消えません。「死ぬ」ことはできますが、使用をやめることはできなくなり、市場のほとんどを獲得しました。「Kubernetesはいつ死ぬのか」という質問に対して、「WordPressはいつ死ぬのか」という質問をしたいと思います。そして、彼はまだ生きていなければなりません。順序を設定しましょう。最初にWP、次にKubernetesです。

だからKubernetesは私たちと一緒です。興味深いのは彼ではありませんが、一番上に巻かれているサービスは興味深いものです。これらはオペレーターとカスタムリソース定義です。「PostgreSQLクラスター」と呼ばれる独自のリソースを取得および作成する機能は、1つのYAMLフットクロスでそれを記述し、クラスターにスローします。

他に何が起こりますか？ GoLangやTypeScriptなどの静的に型付けされたプログラミング言語をすべて管理する機能もあります。そして、私はKotlinを本当に信じています-多くのクールなDSLがすでにKotlinに書かれています。そして、もっと書かれるでしょう。

有料のヘルムチャート、オンプレミスで起動できる有料のアプリケーション、一部のライセンスされたアプリケーションもサブスクリプションで提供されます。さまざまなサービスの統合があります-実際、それはすでに存在します。たとえば、DataDogはすでにKubernetesと統合されています。また、監視アラート市場に登場する新しい人たちも、明らかな理由でKubernetesと統合されます。クラウド製品は、何らかの方法でKubernetesを通過することはありません。これは、誰もが目指すプラットフォームです。

しかし、これはすべて、Kubernetesが優れていることを意味するものではなく、これ以上優れたものはありません。以前の状態と比較します-Amazonソリューション：ECS、ElasticBeanstalkを使用します。それらに出くわした人々は、私の古い類推では、あることは737 MAXだけでなく、電気テープとプラスチックで作られた737MAXであることを知っています。したがって、主要なプレーヤー（Amazon、Microsoft Azure、Google）はすべてすでにKubernetesにあり、おそらくYandexとMail.ruもありますが、私はそれらをフォローしていません。これはとても一般的な未来です。これまでのところ誰もが同意するような悪い、しかし「十分に良い」共通の未来。それはすべてさらに変化しているのですか、あなたはレッドハットに尋ねなければなりません-彼らは私より賢いです。

JavaはKubernetesについてどのように感じていますか？

結構です。

PCでどのOSを使用していますか？

どちらもmacOS上にあります。

DevOpsスペシャリストは現在積極的に採用されていますか？

はい、彼らは常に遠隔地で積極的に撮影されましたが、今では同じ方法で積極的に撮影されています。状況は根本的に変わらないと思います。一般的に、私は削除されていない作業を考慮していません。すべての優れた企業がサンクトペテルブルクにオフィスを持っているわけではありません。もちろん、距離はあります、そして現在の出来事はそれが可能であることを人々に示しました。それをより快適にする人の数は増えるだけです。「多くの人が試してオフィスに戻った」と言われていますが、オフィスに戻るにはお金がかかります。お金も選択肢もありません。現在、多くの企業が節約しています。

「Dockerはすでに死んでいる」またはあなたがDevopsについて知りたいが、尋ねることを恐れていたものは何でも