Kubernetes CSI を通じて Longhorn ボリューム スナップショットのバックアップ、復元、クローン、拡張機能を実装する

Kubernetes CSI を通じて Longhorn ボリューム スナップショットのバックアップ、復元、クローン、拡張機能を実装する

前回の記事では、Longhorn UI を使用してボリューム スナップショット、バックアップとリカバリなどの機能を実行できることを紹介しました。さらに、Kubernetes を通じてボリュームを管理することもできます。たとえば、クラスター上で CSI を使用して、スナップショット、バックアップとリカバリ、クローン作成、容量拡張機能を実装できます。

CSI ボリューム スナップショット

Kubernetes はバージョン 1.12 からストレージ ボリューム スナップショット機能を導入し、バージョン 1.17 でベータ版になりました。 2 つのリソース オブジェクト PV と PVC と同様に、Kubernetes はボリューム スナップショット管理用に VolumeSnapshotContent、VolumeSnapshot、および VolumeSnapshotClass の 3 つのリソース オブジェクトを提供します。

コンセプト

VolumeSnapshotContent は、PV のリソース概念に似ており、PV に基づいて作成されたスナップショットです。 VolumeSnapshot は、永続宣言 PVC の概念に似た、ボリューム スナップショットに対するユーザーの要求です。 VolumeSnapshotClass オブジェクトを使用すると、スナップショットの特性を設定し、VolumeSnapshotContent の詳細を保護し、StorageClass の「クラス」概念と同様に、VolumeSnapshot バインディングの動的な管理を提供できます。

ボリューム スナップショット機能は、Kubernetes ユーザーに、完全に新しいボリュームを作成しなくても、指定した時点でボリュームの内容をコピーする標準的な方法を提供します。たとえば、データベース管理者は、編集や削除などの変更を実行する前に、データベースのバックアップを実行できます。

ただし、この機能を使用する場合は、次の点に注意してください。

  • VolumeSnapshot、VolumeSnapshotContent、および VolumeSnapshotClass リソース オブジェクトは CRD であり、コア API の一部ではありません。
  • VolumeSnapshot サポートは CSI ドライバーでのみ利用可能です。
  • VolumeSnapshot のデプロイメント プロセスの一環として、Kubernetes チームは、コントロール プレーンにデプロイされるスナップショット コントローラーと、CSI ドライバーと一緒にデプロイされる csi-snapshotter と呼ばれるサイドカー コンテナーを提供します。スナップショット コントローラーは、VolumeSnapshot オブジェクトと VolumeSnapshotContent オブジェクトをリッスンし、VolumeSnapshotContent オブジェクトの作成と削除を担当します。 csi-snapshotter は VolumeSnapshotContent オブジェクトをリッスンし、CSI エンドポイントで CreateSnapshot および DeleteSnapshot 操作をトリガーしてスナップショットを作成または削除します。
  • CSI ドライバーはボリューム スナップショットを実装する場合と実装しない場合があります。 CSI ドライバーは、ボリューム スナップショットのサポートを提供するために csi-snapshotter を使用する場合があります。詳細については、CSI ドライバーのドキュメント (https://kubernetes-csi.github.io/docs/external-snapshotter.html) を参照してください。

VolumeSnapshotContents と VolumeSnapshots のライフサイクルには、リソースのプロビジョニング、リソースのバインディング、PVC を使用するための保護メカニズム、リソースの削除など、さまざまな段階が含まれます。これら 2 つのオブジェクトは、次のライフサイクルに従います。

リソースのプロビジョニング: PV リソースのプロビジョニングと同様に、VolumeSnapshotContent でも静的または動的な方法でリソースをプロビジョニングできます。

  • 静的プロビジョニング: クラスタ管理者は、PVを手動で作成するのと同様に、VolumeSnapshotContentリソースのセットを事前に作成します。
  • 動的プロビジョニング: VolumeSnapshotClass リソースに基づいて、StorageClass が PV を動的に作成する方法と同様に、ユーザーが VolumeSnapshot アプリケーションを作成すると、VolumeSnapshotContent が自動的に作成されます。

リソース バインディング:スナップショット コントローラーは、静的プロビジョニングと動的プロビジョニングの両方を含む、VolumeSnapshot を適切な VolumeSnapshotContent にバインドする役割を担います。 VolumeSnapshot と VolumeSnapshotContent も 1 対 1 でバインドされており、1 対多の状況は発生しません。

使用中の PVC の保護メカニズム:ストレージ スナップショット VolumeSnapshot が作成中でまだ完了していない場合、関連する PVC は使用中としてマークされます。ユーザーが PVC を削除した場合、スナップショットが完了しないことによるデータ損失を回避するために、システムは PVC をすぐには削除しません。削除操作は、VolumeSnapshot が作成される (readyToUse ステータス) か終了する (aborted ステータス) まで遅延されます。

リソースの削除: VolumeSnapshot で削除操作が開始されると、バインドされたバックエンド VolumeSnapshotContent での削除操作は、削除ポリシー DeletionPolicy の設定に基づいて決定されます。設定可能な削除ポリシーは次のとおりです。

  • 削除: VolumeSnapshotContent リソース オブジェクトとスナップショットの内容を自動的に削除します。
  • 保持: VolumeSnapshotContent リソース オブジェクトとスナップショットの内容は保持され、手動でクリーンアップする必要があります。

当社の Longhorn システムは、デプロイメント後に 3 つの csi-snapshotter Pod を作成します。

  kubectl get pods - n longhorn - システム
名前準備完了ステータス再起動年齢
csi - snapshotter - 86f 65 d8bc - 9 t7dd 1 / 1 実行中5 ( 126 ) 2 d17h
csi - snapshotter - 86f 65 d8bc - d6xbj 1 / 1 実行中5 ( 126 ) 2 d17h
csi - snapshotter - 86f 65 d8bc - dncwv 1 / 1 実行中5 ( 126 ) 2 d17h
......

これらは実際に開始される 3 つのレプリカです。同時にサービスを提供できるのは 1 つの Pod のみです。リーダー選出は高可用性を実現するために使用されます。たとえば、現在ここでサービスを提供しているのは csi-snapshotter-86f65d8bc-dncwv です。対応するログ情報を表示できます。

  kubectl ログ- f csi - スナップショット- 86f 65 d8bc - dncwv - n longhorn - システム
......
E0223 04 : 36 : 33.570567 1 反射鏡行く127 ] githubcom / kubernetes - csi / external - snapshotter / client / v3 / informers / externalversions / factorygo : 117 : * v1beta1 の監視失敗しましたVolumeSnapshotClass : * v1beta1リスト失敗しましたVolumeSnapshotClass : サーバー要求されたリソース見つけることできませでした( volumesnapshotclasses.snapshot.storage.k8s.io 取得)
E0223 04 : 37 : 03.773447 1 反射鏡行く127 ] githubcom / kubernetes - csi / external - snapshotter / client / v3 / informers / externalversions / factorygo : 117 : * v1beta1 の監視失敗しましたVolumeSnapshotContent : * v1beta1リスト失敗しましたVolumeSnapshotContent : サーバー要求されたリソース見つけることできませでした ( volumesnapshotcontents.snapshot.storage.k8s.io 取得)

VolumeSnapshotClass リソースと VolumeSnapshotContent リソースがないことがわかります。これは、これら 2 つのリソースが Kubernetes の組み込みリソース オブジェクトではなく、CRD であるためです。 Longhorn のインストール時にこれら 2 つの CRD をインストールしなかったため、見つかりません。 CSI を介してボリューム スナップショット機能を実装するには、当然ながら、まず CRD をインストールする必要があります。これらは https://github.com/kubernetes-csi/external-snapshotter プロジェクトから取得できます。

  git clone https://github.com/kubernetes-csi/external-snapshotter
cd 外部- スナップショット&& git チェックアウトv5 .0 .1
kubectl kustomize クライアント/ config / crd | kubectl 作成-f -

上記のコマンドは、上記の 3 つのスナップショット CRD をインストールします。

  kubectl でcrd を取得します| grep スナップショット
ボリュームスナップショットクラススナップショット ストレージ k8s 2022-02-23 T05 : 31 : 34Z 2022-02-23 T05 : 31 : 34Z
ボリュームスナップショットコンテンツスナップショット ストレージ k8s 2022-02-23 T05 : 31 : 34Z 2022-02-23 T05 : 31 : 34Z
ボリュームスナップショットスナップショット ストレージ k8s 2022-02-23 T05 : 31 : 34Z 2022-02-23 T05 : 31 : 34Z

インストールが完了したら、上記の csi-snapshotter 関連の Pod ログを確認すると、すべてが正常であることがわかります。 CRD をインストールした後では、それだけでは不十分です。 VolumeSnapshot および VolumeSnapshotContent オブジェクトをリッスンするためのスナップショット コントローラーも必要です。同様に、external-snapshotter プロジェクトも Common Snapshot Controller を提供します。ワンクリックでインストールするには、次のコマンドを実行します。

 # deploy / kubernetes / snapshot - controller / setup - snapshot - controller .yaml を変更しますイメージアドレスcnych / csi - snapshot - controller : v5.0.0 です デフォルトはgcr イメージです。
kubectl -n kube -system kustomize deploy / kubernetes / snapshot - controller | kubectl 作成-f -

ここでは、スナップショット コントローラーを kube-system 名前空間にインストールし、2 つのコピーを開始します。繰り返しますが、一度にサービスを提供できるのは 1 つの Pod だけです。

  kubectl get pods - n kube - system - l app = snapshot - controller
名前準備完了ステータス再起動年齢
スナップショット- コントローラー- 677 b65dc6c - 288 w9 1 / 1 実行中0 3 m22s
スナップショット- コントローラー- 677 b65dc6c - zgdcm 1 / 1 実行中0 39

この時点で、CSI を使用してスナップショットを構成するための環境が準備されました。

テスト

ボリューム スナップショット機能の使用方法を説明するために、前の mysql-pvc ボリュームを例に挙げてみましょう。

  kubectl pvc を取得- pvc
名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - pvc バウンドpvc - ec17a7e4 - 7bb4 - 4456 - 9380 - 353 db3ed4307 1 Gi RWO longhorn 2 d18h

mysql-pvc のスナップショット要求を作成するには、まず VolumeSnapshot オブジェクトを作成する必要があります。

 # スナップショット- mysqlヤム
apiVersion : スナップショットストレージk8sio / v1
種類: ボリュームスナップショット
メタデータ:
名前: mysql - スナップショット- デモ
仕様:
ボリュームスナップショットクラス名: longhorn
ソース
永続ボリュームクレーム名: mysql - pvc
# volumeSnapshotContentName : テスト- コンテンツ

主な構成パラメータは 2 つあります。

  • volumeSnapshotClassName: VolumeSnapshotClass の名前を指定します。これにより、対応する VolumeSnapshotContent を動的に作成してバインドできます。このパラメータが指定されていない場合は静的メソッドとなり、VolumeSnapshotContent を手動で作成する必要があります。
  • persistentVolumeClaimName: データ ソースの PVC 名を指定します。
  • volumeSnapshotContentName: 静的ストレージ スナップショットを申請する場合は、このパラメータを使用して VolumeSnapshotContent を指定する必要があります。

上記ではストレージ スナップショット クラス longhorn を指定しましたが、もちろんこのオブジェクトを作成する必要があります。

 # スナップショットクラス.yaml
apiVersion : スナップショットストレージk8sio / v1
種類: VolumeSnapshotClass
メタデータ:
名前: ロングホーン
# アノテーション: # デフォルトのスナップショットクラスを指定する場合
# スナップショットストレージKubernetesio / is - デフォルト- クラス: "true"
ドライバードライバーロングホーンio
削除ポリシー: 削除

各 VolumeSnapshotClass には、driver、deletionPolicy、およびparameters フィールドが含まれており、このクラスに属する VolumeSnapshot を動的に構成する必要がある場合に使用されます。

  • ドライバー: CSI ストレージ プラグイン ドライバーの名前を示します。ここではdriver.longhorn.ioという名前のLonghornプラグインを使用します。
  • deletionPolicy: 削除ポリシー。Delete または Retain に設定できます。削除ポリシーが Delete の場合、基盤となるストレージ スナップショットは VolumeSnapshotContent オブジェクトとともに削除されます。削除ポリシーが Retain の場合、基礎となるスナップショットと VolumeSnapshotContent オブジェクトの両方が保持されます。
  • パラメータ: ストレージ プラグインが構成する必要があるパラメータ。 CSI ドライバーは特定の構成パラメータを提供します。

現在のスナップショット クラスをデフォルトとして設定する場合は、 snapshot.storage.kubernetes.io/is-default-class: "true" などのアノテーションを追加する必要があります。

ここで、上記の 2 つのリソース オブジェクトを直接作成します。

  kubectl apply -f スナップショットクラス.yaml
ボリュームスナップショットクラススナップショットストレージk8sio / longhorn 作成
kubectl apply -f スナップショット- mysql .yaml
ボリュームスナップショットスナップショットストレージk8sio / mysql - スナップショット- デモが作成されました
kubectl ボリュームスナップショットクラスを取得する
名前ドライバー削除ポリシー年齢
ロングホーンドライバーロングホーンio 削除43
kubectl ボリュームスナップショットを取得する
名前READYTOUSE ソース PVC ソース スナップショット コンテンツ復元 サイズスナップショット クラススナップショット コンテンツ作成時間 経過時間
mysql - スナップショット- デモtrue mysql - pvc 1 Gi longhorn snapcontent - 1119649 a - d4f2 - 447f - a21a - e527f202e43e 43 43

この時点で、VolumeSnapshotContent オブジェクトが動的に作成されます。

  kubectl ボリュームスナップショットコンテンツを取得する
名前READYTOUSE RESTORESIZE DELETIONPOLICY ドライバーボリューム スナップショット クラスボリューム スナップショットボリューム スナップショット 名前空間 年齢
snapcontent - 1119649 a - d4f2 - 447f - a21a - e527f202e43e true 1073741824 ドライバーを削除しますロングホーンio longhorn mysql - スナップショット- デモデフォルト97

自動的に作成された VolumeSnapshotContent オブジェクトの内容は次のとおりです。

 apiVersion : スナップショットストレージk8sio / v1
種類: VolumeSnapshotContent
メタデータ:
名前: snapcontent - 1119649a - d4f2-447f - a21a - e527f202e43e
仕様:
削除ポリシー: 削除
ドライバードライバーロングホーンio
ソース
ボリュームハンドル: pvc - ec17a7e4-7bb4-4456-9380-353db3ed4307
ボリュームスナップショットクラス名: longhorn
ボリュームスナップショット参照:
apiVersion : スナップショットストレージk8sio / v1
種類: ボリュームスナップショット
名前: mysql - スナップショット- デモ
名前空間: デフォルト
リソースバージョン: "4967456"
uid : 1119649a - d4f2-447f - a21a - e527f202e43e
状態
作成時間: 16455975460000000000
使用可能: true
復元サイズ: 1073741824
スナップショットハンドル: bs : //pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307/backup-f5f28fd624a148ed

source.volumeHandle フィールドの値は、バックエンド ストレージ上に作成され、ストレージ ボリュームの作成中に CSI ドライバーによって返されるボリュームの一意の識別子です。このフィールドは動的プロビジョニング モードで必須であり、スナップショットのソース ボリューム情報を指定します。 volumeSnapshotRef の下には、関連付けられている VolumeSnapshot オブジェクトに関する関連情報があります。もちろん、この時点では、上記で作成したスナップショットを Longhorn UI インターフェイスで確認することもできます。スナップショット名は snapshot-1119649a-d4f2-447f-a21a-e527f202e43e であり、その背後にある ID は上記の VolumeSnapshotContent 名と一致しています。

対応するバックアップ操作も実行されます。バックアップ情報は、bs://backup-/backup- の形式で snapshotHandle によって指定されます。

これにより、CSI によるボリューム スナップショット管理機能が完成しました。

CSIボリュームリカバリ

Kubernetes は、バージョン 1.17 でスナップショットに基づいてストレージ ボリュームを作成するベータ バージョンを更新しました。この機能を有効にするには、kube-apiserver、kube-controller-manager、および kubelet の Feature Gate で --feature-gates=...,VolumeSnapshotDataSource を有効にする必要があります (バージョン 1.22 ではデフォルトで有効になっています)。その後、スナップショットに基づいて新しい PVC ストレージ ボリュームを作成できます。たとえば、上記で作成した mysql-snapshot-demo オブジェクトに基づいて新しい PVC を作成します。

 # 復元- mysqlヤム
APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: mysql - 復元- pvc
仕様:
ストレージクラス名: longhorn
アクセスモード:
-ReadWriteOnce
リソース
リクエスト:
ストレージ: 1 Gi
データソース:
apiGroup : スナップショットストレージk8sio
種類: ボリュームスナップショット
名前: mysql - スナップショット- デモ

上記の PVC オブジェクトは、基本的に通常の宣言方法と同じです。唯一の違いは、dataSource フィールドを通じて、mysql-snapshot-demo という名前のストレージ スナップショットに基づいて作成されることです。上記のリソース オブジェクトを作成すると、PV が自動的に作成され、それにバインドされます。

  kubectl get pvc mysql - 復元- pvc
名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - 復元- pvc バインドされたpvc - e4ddd985 - 31 a8 - 4570 - b393 - dcedec3b0d95 1 Gi RWO longhorn 17 s

Longhorn UI でボリュームを確認すると、ボリュームの実際のサイズが 0 ではないことがわかります。これは、スナップショットからボリュームを作成したためです。これは、上記のスナップショットからデータを復元することと同じです。

ボリュームのクローン作成

CSI ストレージは、スナップショットに基づいて新しい PVC オブジェクトを作成するだけでなく、既存の PVC に基づいて新しい PVC を複製できるストレージ クローンもサポートしています。これは、dataSource フィールドにソース PVC を設定することによっても実現されます。

PVC のクローン作成は、実際には既存のストレージ ボリュームのコピーを作成することです。唯一の違いは、システムがクローンされた PVC にバックエンド ストレージ リソースを提供するときに、新しい空の PV を作成せず、元の PVC にバインドされた PV とまったく同じ PV をコピーすることです。

Kubernetes API の観点から見ると、クローンの実装は、新しい PVC を作成するときに既存の PVC をデータ ソースとして指定する機能を追加するだけです。ソース PVC はバインドされた状態にあり、使用可能 (使用されていない) である必要があります。

この機能を使用する場合、ユーザーは以下の事項に注意する必要があります。

  • クローン作成はCSIドライバーでのみ利用可能です
  • クローン作成は動的プロビジョニングにのみ適しています
  • クローン機能は、特定の CSI ドライバーがこの機能を実現しているかどうかによって異なります。
  • ターゲット PVC とソース PVC は同じ名前空間に存在する必要があります。
  • 同じ StorageClass でのみサポートされます (デフォルトを使用できます)
  • 2つのストレージボリュームのストレージモード(VolumeMode)は一致している必要があります

同様に、以前の mysql-pvc ストレージ ボリュームをクローンしてみましょう。対応する PVC 宣言は次のとおりです。

 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: mysql - クローン- pvc
仕様:
アクセスモード:
-ReadWriteOnce
ストレージクラス名: longhorn
リソース
リクエスト:
ストレージ: 1 Gi # ソース値以上である必要があります
データソース:
種類: PersistentVolumeClaim
名前: mysql - pvc

この PVC は、ソース PVC と同じ構成を宣言します。唯一の違いは、ソース PVC の名前が dataSource を通じて指定されることです。このリソース オブジェクトは直接作成されます。その結果、新しい PVC mysql-clone-pvc にはソース mysql-pvc と同じデータが含まれます。

  kubectl get pvc mysql - クローン- pvc
名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - クローン- pvc バインドされたpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695 1 Gi RWO longhorn 31 s

対応するボリュームは、Longhorn UI ページでも確認できます。

新しい PVC が使用可能になると、複製された PVC は他の PVC と同様に使用でき、複製、スナップショット、削除などを行うことができます。

ダイナミックボリューム拡張

容量の拡張はストレージにとって非常に重要な要件であることは承知しています。 Kubernetes における動的ボリューム拡張も基本機能です。 PV 拡張には、基盤となるストレージのサポートが必要です。 Longhorn の基盤となるストレージはボリューム拡張をサポートしていますが、拡張されたボリュームはデタッチされた状態である必要があります。 Longhorn ボリュームを拡張するには、PVC を変更する方法と Longhorn UI を使用する方法の 2 つがあります。

Longhorn UI を使用すると操作は比較的簡単です。操作を実行するには、ページで拡張するボリュームを選択し、操作でボリュームの拡張を選択するだけです。

PVC を通じて容量を拡張するには、まず PVC を Longhorn StorageClass によって動的にプロビジョニングし、StorageClass の allowVolumeExpansion プロパティを true に設定する必要があります。この方法は、PVC と PV が自動的に更新され、拡張後も一貫性が維持されるため、推奨されます。たとえば、上記で使用した mysql-clone-pvc ボリューム (デタッチ状態) で使用される longhorn StorageClass は、すでに allowVolumeExpansion: true に設定されています。次に、mysql-pvc ボリュームの下の spec.resources.requests.storage 値を直接変更できます。

  kubectl get pvc mysql - クローン- pvc
名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - クローン- pvc バウンドpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695 1 Gi RWO ロングホーン40 m
kubectl patch pvc mysql - clone - pvc - p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}}'

変更後、PVC のイベント情報を表示できます。

  kubectl はpvc mysql を記述します- クローン- pvc
......
イベント:
タイプ理由年齢送信元 メッセージ
---- ------ ---- ---- -------
......
通常のサイズ変更14 s 外部リサイズドライバーロングホーンio 外部リサイザーボリュームのサイズを変更していますpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695
警告ExternalExpanding 14 s volume_expand PVC 無視します: ボリュームを拡張できるプラグインが見つかりませんでした外部コントローラーがこの PVC を処理するのを待機しています。
通常VolumeResizeSuccessful 2 秒外部リサイズドライバー ロングホーンio ボリュームのサイズ変更に成功しました

サイズ変更操作は、external-resizer コンポーネントを通じて実装されていることがわかります。 PVC および PV のサイズ検証を確認します。

  kubectl get pvc mysql - クローン- pvc
名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - クローン- pvc バウンドpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695 2 Gi RWO ロングホーン43 m
kubectl get pv pvc - 58 eab5f0 - a386-435 c - 91f 4-0 c26f7935695
名前容量アクセスモード回収ポリシーステータス請求ストレージクラス理由年齢
pvc - 58 eab5f0 - a386-435 c - 91f 4-0 c26f7935695 2 Gi RWO 削除バインドデフォルト/ mysql - クローン- pvc longhorn 43 m

PVC、PVともに容量が2Giになっており、拡張が成功していることがわかります。 Longhorn UI を通じてボリューム拡張の成功を確認することもできます。

<<:  2022 年に企業はクラウドでどのような課題に直面するでしょうか?

>>:  インターネットの巨人「クラウド」の最も暗い瞬間:退化、降格、そして大量の顧客喪失

推薦する

企業におけるクラウドコンピューティングの利点と課題

クラウド コンピューティングは、ユーザーがどこからでもオンデマンドでコンピューティング リソースにア...

supremevps: 6 ドル/Windows VPS/1g メモリ/30g SSD/3T トラフィック/ロサンゼルス

新しいマーチャントである supremevps は、コロクロッシングのロサンゼルスとシカゴのデータセ...

アリババの革新的な研究プログラムは3年間実施され、世界中の100以上の大学と協力して300以上の論文を生み出しました。

科学技術には国境がなく、学問には境界がありません。アリババが主導する世界的な科学研究協力プログラム「...

Dockerfileファイルを取得するためのDockerイメージ解析

01. 概要コンテナ イメージのセキュリティに関しては、特にイメージ ポイズニングによるセキュリティ...

クラウドへの移行を成功させるための手順

調査によると、現在進行中の COVID-19 パンデミック中に、エンタープライズ クラウド コンピュ...

Zookeeper を廃止した後、Kafka はトピックとコンシューマー グループをどのように保存しますか?

筆者の会社で現在使用している Kafka のバージョンは 2.2.1 であるため、Kafka カーネ...

SEM医療ウェブサイト技術はコード標準化の背後に人間化が必要

2月20日に私が「SEMの医療SEOキーワード戦略はユーザーの検索体験に応える」という記事を公開した...

古いウェブサイトの最適化方法についての簡単な説明

多くの人は、古いウェブサイトを引き継いだときに、それを最適化する方法を知りません。コンテンツから始め...

映画コレクションステーションの運用アイデアとよくある問題点

今日は何もすることがないので、映画コレクションステーションの運用アイデアについてお話ししましょう。私...

ガートナー: エッジコンピューティングソリューションの構築における中国企業のベストプラクティス

中国企業がデジタル成熟度と浸透度を向上させ続けるにつれて、インフラストラクチャおよび運用 (I&am...

クラウド コンピューティングの支出が増加している理由は何ですか?

昨年、業界アナリストは「クラウド コンピューティングの減速」が懸念されると警告しました。これは、予算...

SEOサイト全体の最適化と従来のキーワード最適化の違い

サイト全体の最適化とはSEO 最適化は、ウェブサイト最適化とも呼ばれ、検索エンジンのランキング ルー...

「海天盛宴」の孫静亜の事件から通信セキュリティを考察

CCTVのニュースは最近、警察が「海天生宴」の周辺少女である孫静亜のネット売春事件を摘発したと報じた...

電子商取引戦争が迫る、必見のウェブデザインボード5選

毎年恒例の電子商取引プロモーションイベントが近づいてきました。昨年の天猫ダブル11は、私たちの記憶に...