Kubernetesに移行するための6つのヒント

Kubernetes

Kubernetesが支配的な位置を占め続けているので、
あなたはKubernetesに切り替えることを検討しているかもしれません。
では、どこから始めたら良いのでしょうか?

ここにKubernetesへの移行を始め、
時間を節約するための、
6つの有益なヒントをお伝えします。
何を避けるべきか、そしてどのようにして可能性を最大限に引き出すかを見出しましょう。

新しいアーキテクチャのアプローチがますます普及するにつれて、
既存のアプリケーションを使用している企業は、
古いコードを書き直すことに躍起になっています。
モノリシックなサービスを、一連のマイクロサービスやサーバーレス機能に変えられるということは、
正に見事であり、Kubernetesが大流行しているのも頷けます。

この記事には、コンテナに移行するときに時間、お金、および頭脳を節約するのに役立つ一連のヒントがあります。
それは私たち自身の経験と、パートナーの経験に基づいています。

サーバーに過剰なコストを掛けない

Kubernetesが管理システムに追加の性能を必要とするにもかかわらず、
アプリケーションのために最高級のサーバーを購入する必要はありません。
最近行われたプロジェクトの1つ(ソーシャル/人事プラットフォーム)では、

平均以下のサーバー構成を購入するようお客様にアドバイスしました。
その結果、CPU負荷は約5%、メモリ負荷は平均10%でした。
そして私達にはまだアプリケーションをオートスケールするオプションがありました。

もちろん、もっと[サーバーの]性能を上げても大丈夫です。
しかし、それは予算を最大限に活用することではありません。

Session persistence load balancerを使用しない

4つのエレベーターがある建物があると想像してください。
そのうちの2つは1階にあり、開いています。
人々は荷造りしており、それらのエレベーターは負荷が高い状態です。
それらは追加の重量を処理することはできません。
数秒後、3番目と4番目のエレベーターがドアを開けています。

関連資料:  次のレベルのKubernetesネイティブJavaフレームワーク – QuarkusはJavaをsubatomicレベルで提供します。

入ってきたばかりの新しい人たちは新しいエレベーターに行きますが、
最初の2人の人たちはエレベーターがpersistence(≒固定性/永続性)の為、
この機会を利用できません。
エレベーターの負荷を分散させるためのスペースはたくさんありますが、
persistenceがこの機会の利用を許可しません。
エレベーターのpersistenceが無い間、
人々はエレベーター間に広がることができて、
快適に上がることができます。

サーバーとセッションのpersistenceについても同じことが言えます。
この状態を server persistenceと呼ぶことができます。

一時ファイルにpersistent storage

を使用しない

ほとんどのアプリケーションは少なくともある種の一時的なデータ(例えばサムネイル)を必要とします。
このデータは、負荷を減らすためにインスタンス間で共有する必要があります。
単にpersistent(≒永続的な/固定性のある)ストレージスペースを追加購入してすべてのノードにマウントすることで、
この問題を解決したケースがいくつかあります。

ですが、より安い方法があります!
(とにかくそれは一時的なデータです)インメモリー フォルダを作成し、
各ノード上に存在するポッド間でデータを共有することができます。
0ドルでも同じ機能性があります。

Google Cloudでログを無効にする

現時点では、Google Cloudのログシステムは期待どおりに機能していません。
そのため、Google Cloudを使用している場合は、ログを無効にして、
必要なログ用に別のサービスを使用してください。
さもなければ、たくさんのゴミ情報のメッセージを受け取るでしょう。

これは必要とするログを見つけることを複雑にするだけでなく、
余分な費用がかかるでしょう。

複数のクラスターを作成する代わりにCDNを使用する

フロントエンドの負荷が高いがバックエンドの負荷がそれほど大きくない場合は、
ユーザーがデータにすばやくアクセスできるように、
世界中にノードクラスタを作成することがあります。
これも機能しますが、より費用対効果の高い方法があります。

ユーザーがデータにすばやくアクセスできるように、
世界中にノードクラスタを作成することがあります。
これも機能しますが、より費用対効果の高い方法があります。

1つだけのクラスタを作成してCDN(たとえばCloudflareなど)を使用すると、
同じことを無料で(または、選択したプロバイダによっては少なくとも安価に)行うことができ、
品質が維持され、場合によってはパフォーマンスが向上します。

Kubernetesではなくアプリケーションで設定する

Kubernetesへの移行を開始すると、アプリに多くの弱点とボトルネックを発見する可能性があります。
DevOpsの人たちに非常にカスタマイズされた設定を作成させるのは魅力的かもしれませんが、
それは間違ったやり方です。
アプリケーションの問題を対処してください。
そうしないと、Kubernetesを使用しても何も得られません。

関連項目:  IoT用のKubernetesは、k3sでこれまでよりも軽量になります

この記事のポイント2に戻りましょう。
アプリケーションがSession persistence load balancerを使用する必要があり、それが無くては機能しない場合は、
Kubernetesコンテナーを使用して実行することを試すことができます。
そうすることにより、あなたはチームが最新かつ流行のアプローチを使用していることを自慢することができます。
しかし、それから有意義な利益を得ることはありません。

結論

Googleは、重い負荷とゼロダウンタイムのロールアウトの処理において豊富な経験を持っています。
Kubernetesは、それが優れた「すぐに使える」/「独創的な」解決策であることを示しています。
しかし、その可能性を最大限に引き出すには、忍耐強く、進んで学習し、
そして推奨されるベストプラクティスにアプリケーションを適応させる必要があります。

Kubernetesは信頼できる環境を構築するのに役立ちますが、
プロジェクトの費用対効果を最適化するための独自の方法を見つけるのはあなた次第です。

元記事:https://jaxenter.com/kubernetes-transition-tips-156557.html

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です