10 以上の Redis コンテナ化技術の比較: K8S は万能薬ではない

[[408127]]

張錦濤

クラウドネイティブテクノロジーの専門家

• DevOpsの実践・実装を担当し、コンテナ化技術の導入や運用保守自動化の推進などを行う。

• 彼は数多くの有名なオープンソース プロジェクトに参加しており、Docker、Kubernetes、および関連するエコシステムに関する広範な制作実務経験と詳細なソース コード研究を持っています。

本日共有する内容は、以下の 4 つの側面に分かれています。

• 1. 起源

• 2. 各種コンテナ化技術の導入

• 3. Redisの紹介

• 4. Redisコンテナ化ソリューションの比較

1. 起源

まず、今日このトピックをシェアする理由についてお話ししましょう。私と友人たちは Redis 技術交流グループを組織し、約 6 年間運営してきました。ある日、グループ内の友人が次のような質問をしました。

彼は、Redis online が Docker を使用してインストールされているかどうかを全員に尋ねました。 Docker がホストのネットワーク モードを使用し、ディスクがローカル マウント モードを使用するソリューションはどうでしょうか?今日の共有の後、誰もがこのソリューションをより明確に理解し、評価できるようになると信じているため、現時点ではここではこのソリューションについて議論しません。

2. 各種コンテナ化技術の導入

1. Chroot と jail

コンテナ化技術に関しては、実は非常に長い歴史があります。現在私たちが使用しているコンテナ化技術、いわゆるk8sやクラウドネイティブの概念は近年になって普及し始めたばかりですが、実のところ、コンテナ化技術の開発は非常に早い時期に始まりました。たとえば、最も古いものは chroot から来ています。誰でも chroot を使用したことがあるか、聞いたことがあるかもしれません。 1979 年に Unix から生まれました。その主な機能は、プロセスとサブプロセスを変更することです。

chroot を使用するとどのような効果が得られますか? chroot を使用してディレクトリを追加し、プロセスを開始します。プロセスが認識する / は、通常 / ディレクトリと呼ばれます。この / は、先ほど指定したフォルダー、または先ほど指定したパスになります。このようにして、オペレーティング システム上の一部のファイルや、権限やセキュリティに関連するものを効果的に保護できます。

2000年に、刑務所と呼ばれる新しい技術が登場しました。実際、サンドボックス環境のプロトタイプとなるサンドボックスはすでに存在していました。 jail を使用すると、プロセスまたは作成された環境に独立したネットワーク インターフェイスと IP アドレスを持たせることができます。 jail の使用について言及すると、必ず問題が思い浮かびます。つまり、独立したネットワーク インターフェイスと IP アドレスがある場合、元のソケットを送信できないということです。通常、元のソケットとより頻繁に接触するコマンドは、私たちが使用する Ping コマンドです。デフォルトでは、raw ソケットの使用は許可されませんが、独自のネットワーク インターフェイスと IP アドレスがあり、一般的に使用される仮想マシンのように見えます。

2. Linux VServer と OpenVZ

そして 2001 年に、Linux コミュニティに Linux VServer と呼ばれる新しいテクノロジーが登場しました。 Linux VServer は lvs と略されることもありますが、これは実際には通常使用される 4 層プロキシ lvs とは異なります。これは実際には Linux カーネルのパッチであり、Linux カーネルを変更する必要があります。変更が完了したら、システムレベルの仮想化をサポートできるようになります。同時に、Linux VServer を使用すると、システム コールを共有でき、シミュレーションのオーバーヘッドがないため、よく使用されるシステム コールの一部とシステム コールの一部の機能を共有できます。

2005 年に、OpenVZ という新しいテクノロジーが登場しました。 OpenVZ は実際には Linux VServer と多くの共通点があります。これはカーネルへのパッチでもあります。これら 2 つのテクノロジ間の最大の相違点は、Linux に多くのパッチが適用され、多くの新機能が追加されたことです。しかし、2005 年には、これらすべてが Linux トランクに統合されませんでした。さらに、OpenVZ を使用すると、各プロセスが独自の /proc または /sys を持つことができます。

実際、たとえば Linux では、プロセスを開始すると、そのプロセス関連の情報が /proc/self の下に表示されることは誰もが知っています。独自の独立した /proc があれば、実際に他のプロセスから分離する効果が得られます。

もう 1 つの注目すべき機能は、独立したユーザーとグループがあることです。つまり、独立したユーザーまたは独立したグループを持つことができ、これらはシステム内の他のユーザーまたはグループから独立できます。

第二に、OpenVZ は商業的に使用されています。多くの海外ホストとさまざまな VPS が OpenVZ テクノロジー ソリューションを使用しています。

3. 名前空間と cgroup

2002 年までに、新しいテクノロジは名前空間になりました。 Linux には、プロセス グループ内の特定のリソースを分離できる名前空間と呼ばれる新しいテクノロジがあります。通常使用する名前空間には、PID、net など多くの種類があり、同じ名前空間の下にいないと、他のプロセスの特定のリソースを確認できないためです。

2013 年には、ユーザー名前空間という新しい名前空間機能が作成されました。実際、ユーザー名前空間がある場合、それは前述の OpenVZ によって実装された独立したユーザーとグループの機能に似ています。

通常、名前空間操作には 3 つの種類があります。

1) クローン

サブプロセスが配置される名前空間を指定できます。

2) 共有解除

他のプロセスとは共有されません。 unshare に -net を追加すると、独自のネットまたはネットワーク名前空間を共有せず、他のプロセスから独立できます。

3) セトゥン

プロセスの名前空間を設定します。

2008 年に、cgroup が Linux カーネルに導入されました。 CPU、メモリ、ディスク、ネットワークなどのプロセス グループのリソース使用状況を分離するために使用できます。 2013 年にユーザー名前空間と統合され、再設計された後、よりモダンになりました。現在よく利用しているDocker関連の機能は、実はこの頃から生まれたものなのです。したがって、cgroup と名前空間は、最新のコンテナ テクノロジーの基礎を形成します。

4. LXC と CloudFoundry

2008 年に LXC という新しい技術が登場しました。これを Linux Container (以下、LXC) とも呼びます。上記では Linux VServer や OpenVZ など多くのコンテナ化技術について言及しましたが、これらはすべてパッチを通じて実装されており、LXC はアップストリーム Linux カーネルと直接連携できる最初のコンテナ化技術です。

LXC は特権コンテナをサポートしているため、マシン上で uid マッピング、gid マッピング、マッピングを行うことができ、root ユーザーとして起動する必要がないため非常に便利です。この方法により、攻撃対象領域を大幅に削減できます。 LXC でサポートされているより一般的な操作は、コンテナを起動するために使用できる LXC-start と、コンテナに入るために使用できる LXC-attach です。

2011年までに、CloudFoundryが登場し始めました。実際には、LXC と Warden のテクノロジを組み合わせて使用​​しました。現時点で言及しなければならないのは、その技術アーキテクチャは CS モデル、つまりクライアントとサーバーが存在し、Warden コンテナーには通常 2 つのレイヤーがあるということです。 1 つのレイヤーは読み取り専用 OS (読み取り専用オペレーティング システム ファイル システム) であり、もう 1 つのレイヤーはアプリケーションとその依存関係用の非永続的な読み取り/書き込みレイヤー (これら 2 つのレイヤーの組み合わせ) です。

これまでに説明したテクノロジのほとんどは、特定のマシン、つまり単一のマシンを対象としています。 CloudFoundry の最大の違いは、複数のコンピューター間でコンテナ クラスターを管理できることです。これは、実際には最新のコンテナ テクノロジーの関連機能がすでに備わっています。

5. LMCTFY と systemd-nspawn

2013 年、Google は LMCTFY と呼ばれる独自のコンテナ化ソリューションをオープンソース化しました。このソリューションは、CPU、メモリ、デバイスの分離をサポートできます。また、サブコンテナをサポートしているため、アプリケーションは現在コンテナ内にあることを認識できます。また、自分自身で子コンテナを作成することもできますが、2013 年の開発後、これらの技術を継続的に開発するために自分自身に頼ることは孤独な戦いに等しく、開発には常に限界があることが徐々に判明したため、抽象化と移植に主なエネルギーを集中し、そのコア機能を libcontainer に移植しました。 Libcontainer はその後 Docker のランタイムの中核となり、Docker によって OCI に寄贈され、runC へと発展しました。この部分については後ほど詳しく説明します。

サーバーには PID 1 のプロセスが必要であることは誰もが知っています。これはサーバーの初期プロセスであり、デーモン プロセスです。最新のオペレーティング システムでは、ほとんどの人が systemd を使用します。 Systemd は、systemd-nspawn と呼ばれるコンテナ化されたソリューションも提供します。このテクノロジーは、systemd 関連のツール チェーンと組み合わせることができます。

通常使用する systemctl に加えて、systemd にはマシンの管理に使用できる systemd machine ctl もあります。このマシンは、コンテナの管理に関連するインターフェースと、仮想マシンの管理に関連するインターフェースの 2 つの主要なインターフェースをサポートしています。

一般的に言えば、systemd が提供するコンテナ テクノロジ ソリューションを使用すると、マシン ctl を介してコンテナと対話できるようになります。たとえば、machine ctl start を使用して systemd 対応コンテナを起動したり、machine ctl stop を使用してシャットダウンしたりできます。このテクノロジーにより、リソースとネットワークの分離がサポートされます。実際、最も重要な機能は systemd ns であり、これは分離のために名前空間を実際に使用します。リソースに関しては、systemd から取得されます。 Systemd は cgroups を使用してリソースを分離できます。実際、これもこれら 2 つの技術的ソリューションの組み合わせです。

6. ドッカー

そして2013年にDockerが登場しました。一般的に言えば、Docker はコンテナ時代のリーダーです。なぜそんなことを言うのですか？なぜなら、2013 年に Docker が登場したとき、彼は標準化されたデプロイメント ユニット、つまり Docker イメージについて初めて言及したからです。同時に、中央イメージリポジトリであるDockerHubも立ち上げました。誰でも DockerHub を通じて事前に構築された Docker イメージをダウンロードし、Docker run の 1 行でコンテナを起動できるようになります。

使いにくく複雑な多くのテクノロジーの中から、Docker が提案されました。コンテナを起動するには、Docker run の 1 行だけが必要です。コンテナの起動の複雑さが大幅に簡素化され、利便性が向上します。

こうして、Docker テクノロジーは世界中で人気を博し始めました。 Dockerが提供する主な機能は何ですか?たとえば、リソースの分離と管理などです。さらに、Docker 0.9 より前のコンテナ ランタイムは LXC でした。 0.9 以降では、LXC が libcontainer に置き換えられ始めましたが、この libcontainer は実際には前述の Google の LMCTFY です。その後、libcontainer は OCI に寄贈されました。そしてその後、Docker の現在のコンテナ ランタイムは何ですか?コンテナです。 containerd の下位層は runc であり、runc のコアは実際には libcontainer です。

2014 年までに、Google は、ほとんどのコンテナ化ソリューションがスタンドアロン ソリューションのみを提供していることを発見しました。同時に、Docker も CS アーキテクチャに基づいているため、デーモン プロセスの存在を必要とする Docker デマンドが必要になります。このデーモン プロセスは、root ユーザーによって開始される必要があります。ルートユーザーによって起動されるデーモンプロセスは、実際には攻撃対象領域を拡大するため、Docker のセキュリティ問題も多くの人から批判されています。

当時、Google はこの点を発見し、Borg システムをオープンソース化しました。そのオープンソース版が Kubernetes です。 Google はいくつかの企業と協力し、Cloud Native Computing Foundation (CNCF) を設立しました。

7. クベネフィット

一般的に言えば、Kubernetes はクラウドネイティブ アプリケーションの基礎となります。つまり、Kubernetes の登場以降、当社のクラウドネイティブ技術は徐々に発展し、徐々にトレンドをリードしてきました。 Kubernetes はいくつかの主要な機能を提供します。

より柔軟なスケジュール、制御、管理をサポートできます。デフォルトのスケジューラに加えて、簡単に拡張することもできます。たとえば、独自のスケジューラや、実際によく使用される機能の一部であるアフィニティとアンチアフィニティを作成できます。

また、組み込み DNS、kube-DNS、ドメイン名を使用してサービス検出を実行する現在の CoreDNS など、Kubernetes が提供するサービスもいくつかあり、Kubernetes には多くのコントローラーがあります。クラスターの状態を期待どおりの状態に調整できます。たとえば、ポッドがハングアップした場合、自動的に期待どおりの状態に復元できます。

さらに、複数のメインレベルなど、豊富なリソースをサポートしています。最も小さいのはポッドで、その上にデプロイメントや StatefulSets、および同様のリソースが存在します。

最後に、このツールをさらに気に入っている点は、豊富な CRD 拡張機能を備えていることです。つまり、自分でカスタム リソースを記述し、それを CRD などに拡張することができます。

8. コンテナ化の推進

今述べた主な技術以外にも、上で詳しく紹介しなかったruncやcontainerdなど、実はまだ触れていないコンテナ化技術が数多く存在します。 Containerd は実際には Docker オープンソースの中核です。その目標は、標準化された産業用コンテナ ランタイムを作成することです。 CoreOS によってオープンソース化された rkt と呼ばれるソリューションもあります。 rkt がターゲットとしているのは、前述した Docker 関連のセキュリティ問題です。しかし、rkt プロジェクトは現在終了しています。

Red Hat によってオープンソース化された podman もあります。 Podman はコンテナの起動と管理に使用でき、デーモン プロセスはありません。そのため、セキュリティ面では、podman は Docker よりも安全であると言えますが、利便性は大幅に低下します。たとえば、コンテナを再起動して起動しますが、いくつか異なる解決策があります。

2017年にはKata Containerがあり、このKata Containerには開発プロセスがあります。当初、Intel は独自のコンテナ ランタイムを開発していました。また、独自のコンテナ ランタイムを開発していた hyper.sh というスタートアップもありました。両社はより安全なコンテナを作ることを目指しており、使用した基盤技術は K8S に基づいていました。その後、2 つの会社が合併し、hyper.sh のオープン ソース ソリューションの 1 つが runv となり、これが Intel の目に留まり、Kata Container が誕生しました。 2018 年に、AWS は独自の Firecracker をオープンソース化しました。

これら 2 つのテクノロジーは、実際には前述のマシン上のコンテナ化テクノロジーとはまったく異なります。その基礎となるレイヤーは実際には仮想マシンと同等であり、通常は軽量仮想マシン用のコンテナ化テクノロジーと考えられているからです。以上が、さまざまなコンテナ化技術の紹介です。

3. Redisの紹介

次はRedisの紹介に移りましょう。以下はRedis公式サイトからの抜粋です。

1. Redisを使用する主なシナリオ

実際、Redis は現在最も広く使用されている KV データベースです。これを使用する場合、主な使用シナリオは次のようになります。

• キャッシュとして使用し、データベースの前に置いてキャッシュとして使用します。

• これを DB として使用するということは、実際にこれを使用すれば永続的にデータを保存できるということです。

• メッセージキューとしては多くのデータ型をサポートしていますが、ここでは紹介しません。

2. Redisの特徴

• シングルスレッドモデルです。実際には複数のスレッドを持つことができますが、ワーカー スレッドは 1 つだけです。 Redis 6.0 以降では、io マルチスレッドがサポートされていますが、io マルチスレッドでは、ネットワーク関連の部分のみを複数のスレッドで処理できます。実際、データの処理には依然として単一のスレッドが使用されるため、全体としては依然としてシングルスレッド モデルと呼ばれます。

• Redis データは実際にはメモリに保存されます。これはメモリ内データベースです。

• HA に関しては、Redis は HA を実行したいと考えています。これまで、Redis HA を行うには主に Redis Sentinel に依存していました。その後、Redis がクラスターとともに登場してからは、HA を実現するために主に Redis クラスターに依存するようになりました。これらが 2 つの主な HA ソリューションです。

4. Redisコンテナ化ソリューションの比較

Redis の運用と保守について話すとき、どのような点を考慮する必要がありますか?

• デプロイメント、迅速にデプロイする方法、迅速にデプロイする方法、また、ポートが競合しないようにリスニング ポートを管理する方法、ログや永続ファイルなど、すべてデプロイメント関連の内容です。

• スケールアップ/スケールダウンもよく遭遇する問題です。

• 監視と警報;

• 失敗と回復。

上記は私たちが最も懸念している点です。次に、これらの側面について紹介します。

1. 展開

単一のマシン上で複数のインスタンスを実行する場合、Redis が単一のマシン上に複数のインスタンスとしてデプロイされるときに、最初に必要なのはプロセス レベルのリソース分離です。特定のノードにデプロイされたすべての Redis インスタンスは独自のリソースを持つことができ、他のインスタンスの影響を受けません。これはプロセスレベルのリソース分離です。

プロセス レベルのリソース分離は、実際には 2 つの主要な側面に分かれています。1 つは CPU、もう 1 つはメモリです。第二に、単一のマシン上で独自のポート管理を実行したり、独立したネットワーク リソース分離関連のテクノロジを導入したりできるようになることを期待しています。

この場合、まずプロセスレベルのリソース分離について説明しました。これまでコンテナ化関連のテクノロジーを数多く導入してきましたが、プロセスレベルのリソース分離をサポートする場合、最も簡単なソリューションは cgroup を使用することだということはすでにわかっています。ネットワーク リソースを分離したい場合は、名前空間を使用します。つまり、cgroup と名前空間をサポートするすべてのソリューションが、ここでのニーズを満たすことができます。

もう 1 つのソリューションは、上で説明した Kata Container などの仮想化ソリューションです。 Kata Container は仮想化ベースのアプローチです。実際、誰もが仮想化ソリューションに触れたことがあるでしょう。仮想化テクノロジーは、実際には最初はデフォルトで分離されていることは誰もが知っています。

したがって、デプロイメントでは、たとえば Docker を使用している場合や、cgroup と名前空間の両方を使用できる systemd-nspawn を使用する場合は、それらを使用できますが、利便性を考慮する必要があります。たとえば、Docker を使用している場合は、Docker コマンドを実行し、それを別のポートにマップするだけで完了です。

systemd-nspawn を使用する場合は、いくつかの設定ファイルを作成する必要があります。仮想化ソリューションを使用する場合は、イメージもいくつか準備する必要があります。

2. 拡大/縮小

拡大/縮小に関しては、実際には主に2つのシナリオがあります。 1 つのシナリオは、単一インスタンスの maxmemory の調整、つまり最大メモリの調整です。クラスタリング用のクラスタ ソリューションとして、Redis Cluster もあります。このクラスター サイズでは、容量を拡大/縮小すると、2 つの変更が発生します。

一方では、ノードの変更であるノードがあります。新しいノードが追加されると、ノードが削除されることもあります。

もう 1 つはスロットの変更です。つまり、スロットを移行したいと考えています。もちろん、これらはノード ノードに関連しています。容量を拡張すると、Redis クラスター内のノード ノードの数が増えるためです。増加後は、スロットの割り当てを停止するか、特定のノードに一部のスロットを集中させることができます。実際、こうしたニーズも存在します。

見てみましょう。その時点で maxmemory を調整したい場合、すでにコンテナ化を行っていて cgroup を通じてそのリソースを制限したい場合は、cgroup クォータの動的な調整をサポートできるソリューションが必要です。

たとえば、Docker update を使用すると、特定のインスタンスまたはその中の特定のコンテナの cgroups リソース制限を直接変更できます。たとえば、Docker update を使用して新しいメモリを指定し、使用可能な最大メモリを制限することができます。使用可能なメモリを増やすと、インスタンスの maxmemory を調整できます。言い換えれば、単一インスタンスの最大メモリにとって最も重要なことは、cgroups テクノロジーを備え、cgroups テクノロジーに対するサポートを提供することです。

クラスター ノードの変更については、このセクションで後ほど詳しく説明します。

3. 監視アラーム

3つ目のポイントは監視と警報です。物理マシン、クラウド環境、またはその他のソリューションを使用する場合でも、監視とアラームに最も期待される効果は、自動的に検出できることです。

インスタンスを起動した後、インスタンス A が起動したこととそのステータスがすぐにわかるようにしたいと考えています。監視とアラームに関しては、この部分は実際には特定のコンテナ化テクノロジに依存しません。純粋な物理マシンに展開されている場合でも、いくつかのソリューションを通じて自動的に検出され、監視システムに自動的に登録されます。したがって、これは監視とアラームの部分に属し、実際には特定のコンテナ テクノロジに依存しません。しかし、唯一の問題は、コンテナ化ソリューションを使用する場合、一般的に使用されている Redis エクスポーターを Prometheus と組み合わせて監視に使用でき、Redis エクスポーターと Redis サーバーの 2 つのプロセスが同じネットワーク名前空間に存在できることです。

両方が同じネットワーク名前空間にある場合は、127.0.0.1:6379 を介して直接接続できます。 k8s を使用している場合は、両方をポッドに配置できます。しかし、特定のコンテナ化技術に依存しないため、問題にはなりません。監視や警報には、任意のテクノロジーを使用できます。

4. 障害回復

最後に触れたセクションは、失敗と回復です。この部分には、主に 3 つの側面があると思います。

• 1 つ目はインスタンスの再起動です。

場合によっては、操作中にインスタンスがクラッシュする可能性があります。自動的に再起動したい場合は、プロセス管理ツールが必要です。私たちの場合、上で systemd について言及しました。 Systemd は、特定のプロセスの自動起動をサポートできるほか、プロセスがハングアップした後の自動起動もサポートできます。再起動することもできますし、Docker を使用する場合は再起動ポリシーも用意されており、常時または失敗時に指定して、ハングアップしたときに再起動することもできます。

k8s を使用している場合は、さらに簡単になり、自動的にプルアップできます。

• 2つ目はマスタースレーブ切り替えです。

マスターとスレーブの切り替えは比較的正常ですが、マスターとスレーブの切り替えプロセス中にクラスターが正常でなくなる可能性があるため、ここでは障害回復にもリストします。このような状況が存在する可能性があります。では、マスターとスレーブが切り替わるときには何をする必要がありますか?一方で、データの永続性が必要です。一方、マスターとスレーブを切り替える場合、リソース不足によりマスタースレーブ切り替えに障害が発生する場合があります。この場合、実際には前述の膨張/収縮に関係しています。したがって、この場合はリソースを追加する必要があり、最善の方法はリソースを自動的に追加することです。

k8s では、リソースを自動的に追加したい場合、通常はリクエストと制限 (リソース割り当て) を設定し、自動的に追加されることを期待します。通常、これを vpa と呼びます。

• 3つ目はデータの復旧です。

一般的に言えば、たとえば、RDB と AOF を開いて、データを復元したときに直接使用できるようにデータを保存できることを望みます。したがって、データの永続性も 1 つの側面です。

コンテナ化を行う際に考慮すべきことは何ですか? Docker を使用している場合は、チケットをハングアップして、データを永続化する必要があります。たとえば、systemd-nspawn を使用する場合は、データを永続化するためのファイル ディレクトリも必要です。

k8s を使用している場合、クーポンをハングするときにさまざまなオプションがあります。たとえば、ceph の RDB、s3、またはローカル ファイル ディレクトリをハングできます。ただし、信頼性を高めるために、より多くのコピーを持つ分散ストレージが使用される場合があります。

5. ノードの変更

次に、先ほどサービス拡大/縮小で触れたノードの変更についてお話します。たとえば、Redis クラスターの 1 つでいくつかのノードを拡張したい場合、ノードを拡張するときには、クラスターに参加してクラスターと正常に通信できる必要があり、つまり、実際にクラスターに参加している必要があります。

また、Redis クラスターでクラスターを構築する場合、最大の問題は k8s であることもわかっています。 k8s では、サービス検出は主にドメイン名を通じて行われますが、Redis の場合、たとえば NodeIP は実際には IP のみをサポートしており、ドメイン名はサポートしていません。

したがって、Node ノードが変更された場合、NodeIP をクラスター構成に動的に書き込むことができるようにする必要があります。

完全なライフサイクルを実現したい場合、次のスクリーンショットは Kubedb と呼ばれるオペレーターからのものです。下の図に示すように、Redis は次の 3 つの主要部分を提供します。

• PVC、PVC はデータの永続化に使用されます。

• サービス、サービスはサービス検出用です。

• StatefulSets、StatefulSets は実際には k8s のリソースであり、このリソースはステートフル アプリケーションに適しています。

実際のところ、コンテンツ全体で紹介されていないものは何でしょうか? Redis の背後にある会社は Redis Labs と呼ばれ、Redis Enterprise という商用ソリューションを提供しています。実際、これも k8s ソリューションに基づいており、Redis オペレーターも使用します。彼のソリューションは基本的に Kubedb のソリューションと似ています。その中心は依然として StatefulSets を使用し、独自のコントローラーを追加してこのタスクを完了することです。

V. 結論

今日のまとめを見てみましょう。これを単一のマシンで使用する場合は、Docker や、cgroups または名前空間リソース管理をサポートするその他のツールに引き渡すことができます。 cgroup と名前空間を使用すると、リソースを分離し、ネットワーク ポートの競合を回避できるためです。

そして、それが上で述べた友人が述べた問題である場合、彼はホストのネットワークを使用する予定であり、Docker にプロセス管理を行わせたいだけであり、新しいコンテンツを導入したくないのです。次に、コンテナ化されたソリューションである systemd または systemd-nspawn を検討します。

複雑なシナリオでスケジュールと管理を行う場合、たとえば、大規模でより柔軟なスケジュールと管理が必要な場合は、実際にソリューションとなる Kubedb などの Kubernetes オペレーターを使用することをお勧めします。シナリオがそれほど複雑ではなく、比較的単純な場合は、ネイティブの Kubernetes StatefulSets で、若干の調整と変更を加えるだけで、実際にニーズを満たすことができます。

以上が本日の私のシェアの主な内容です。ご参加ありがとうございました。

> > > >

質疑応答

Q1: Redis クラスターが 3 台の物理マシン上に構築され、各マシンで 2 つのインスタンスが実行されている場合、各物理マシン上のインスタンスが相互にマスター スレーブにならないようにするにはどうすればよいでしょうか。

A1: これは私たち全員が通常遭遇する問題です。まず、物理マシンを使用しており、各マシンで 2 つのインスタンスを実行し、3 台​​のマシンのそれぞれで 2 つのインスタンスを実行する場合、インスタンスの合計は 6 つになります。これら 6 つのインスタンスが相互にマスター スレーブではないことを保証できますか?実際、これを直接確認することができます。

唯一の問題は、これがクラスターであり、フェイルオーバーが発生し、アクティブ ノードの切り替えが発生した場合、マスターとスレーブが変更される可能性が非常に高いことです。実際、このような問題が見つかった場合は、手動で切り替えることをお勧めします。物理マシン環境では、この問題に対する特に優れた解決策が見当たらないからです。

Q2: k8s で容量を拡張するときに新しいノードを追加するにはどうすればよいですか?容量拡張とスロット割り当ての手順を自動化するにはどうすればよいですか?

A2: 2つのステップに分けてお話ししましょう。最初の部分は、新しいノードを追加することです。新しいノードの追加に関しては、実は先ほどプロセスの中で触れました。新しいノードを追加した後、まずそのノードがクラスターと通信できるようにする必要があります。ただし、そのためにはクラスター構成ファイルを変更する必要があります。また、クラスター間の通信は IP を介して行われるため、クラスターに NodeIP が必要になります。そのため、クラスター内の他のノードと通信できるように、構成ファイルを変更して NodeIP を追加する必要があります。ただし、この部分では、演算子を使用することをお勧めします。

Q3: Redis オペレーターと分散ストレージを使用しない場合、k8s はどのようにクラスターをデプロイしますか?

A3: 実際には、Redis オペレーターを使用しないことも可能です。先ほど紹介したように、2つのモードがあります。 1 つのモードは、比較的安定している StatefulSets を使用することです。同時に、最も重要な部分は依然として構成を変更することです。まず、Redis コンテナ イメージに init コンテナを追加し、この部分の設定を変更する必要があります。それは可能です。設定を変更した後、クラスターに参加できるように再度プルアップします。

Q4: 異なるネットワーク モデルにおけるネットワーク遅延の違いは何ですか?

A4: 物理マシンのネットワークを直接使用する場合、一般的に言えば、この方法では遅延は発生しないと考えられます。つまり、ホスト ネットワークの遅延は一般に無視されます。ただし、オーバーレイ ネットワーク モデルを使用する場合、オーバーレイ ネットワークであるため、パケットの送信と解凍時にさまざまなリソースの損失とパフォーマンスの損失が発生します。

Q5: 一般的に、企業間で Redis クラスターを共有することが推奨されますか、それとも各システムに独立したクラスターを持たせることが推奨されますか?

A5: この質問については、もちろん各システムを個別にクラスタ化することをお勧めします。最も簡単な例を見てみましょう。たとえば、リストを使用する場合、Redis には ziplist 構成項目があり、これが実際にはストレージとパフォーマンスに関連していることは誰もが知っています。会社ですべてに同じクラスターを使用している場合、Redis クラスターの設定を変更すると、すべてのサービスに影響が及ぶ可能性があります。ただし、各システムに対して Redis グループを個別に使用すれば、それらは互いに影響を及ぼさず、1 つのアプリケーションが誤ってクラスターを停止させて連鎖反応を引き起こすような状況は発生しません。

Q6: 本番環境での Redis の永続性をどのように考慮しますか?

A6: この部分については、私はこう思います。本当に永続化を行う必要がある場合、Redis は 2 つのコアを提供します。1 つは RDB、もう 1 つは AOF です。データが大量にある場合、それに応じて RDB も非常に大きくなる可能性があります。永続化を行う場合は、通常、2 つの間でトレードオフを行うことをお勧めします。一般的に言えば、物理マシン環境を使用している場合でも、ストレージ ディレクトリを別のディスクに配置するか、分散ストレージに掛けることをお勧めしますが、その前提として、書き込みパフォーマンスが原因でクラスターのパフォーマンスが低下することはできないため、すべてをオンにすることをお勧めしますが、データがそれほど重要でない場合は、AOF のみをオンにすることができます。

Q7: 実稼働レベルの Ceph は信頼できますか?

A7: 実際、Ceph の信頼性の問題については多くの人が議論してきました。個人的には、Ceph の信頼性は保証されていると思います。ここでは Ceph を多用し、コアデータを大量に保存しているので、Ceph の信頼性は問題ありません。

それを扱えるかどうかがポイントで、皆さんもよくご存知のSUSEという会社があり、Linuxディストリビューションを扱っています。この会社は実際にエンタープライズレベルのストレージ ソリューションを提供しており、その基盤となるレイヤーは Ceph です。実際、これは正常なことです。この問題に取り組んで解決する熱心な人がいる限り、Ceph は十分に安定していると思います。

ちなみに、k8s を使用している場合は、実際に ceph 演算子を提供する rocket というプロジェクトがあります。このソリューションは現在比較的安定しており、試してみることをお勧めします。

Q8: メモリの申請、メモリの制限、Redis メモリ自体の設定方法を教えてください。

A8: ここで考慮すべき問題がいくつかあります。まず、Redis 自体のメモリについて説明します。実際、それはあなたの実際のビジネスの使用シナリオ、またはあなたのビジネスの実際のニーズに依存します。 RedisインスタンスまたはRedisクラスターのメモリを埋めることはできません。

それがいっぱいの場合は、LRUが立ち退きのようなことをすることを可能にする必要があります。これは1つの側面です。もう1つの側面は、メモリを適用することです。実際、ここで尋ねたい質問はK8S環境を参照すべきであることを理解しています。 K8Sには、リクエストと制限があります。制限は、利用可能なメモリ制限でなければなりません。メモリを制限するには、Redis自体が使用するメモリを考慮する必要があります。