Kubernetes Deschedulerの使い方を学ぶのに役立つ記事

Kubernetes Deschedulerの使い方を学ぶのに役立つ記事

kube-scheduler の観点からは、一連のアルゴリズムを使用して、Pod を実行するのに最適なノードを計算します。スケジュールのために新しい Pod が表示されると、スケジューラはその時点の Kubernetes クラスターのリソース記述に基づいて最適なスケジュール決定を行います。ただし、Kubernetes クラスターは非常に動的です。ノードのメンテナンスなど、クラスター全体の変更により、最初にエビクション操作を実行します。このノード上のすべてのポッドは他のノードに追い出されますが、メンテナンスが完了すると、以前のポッドは自動的にノードに戻りません。これは、ポッドがノードにバインドされると、再スケジュールがトリガーされないためです。これらの変更により、Kubernetes クラスターは一定期間不均衡になる可能性があるため、クラスターのバランスを再調整するにはバランサーが必要です。

もちろん、一部のポッドを手動で削除して再スケジュールをトリガーするなど、一部のクラスターを手動でバランス調整することは可能ですが、これは明らかに面倒なプロセスであり、問​​題の解決策にはなりません。実際の運用でクラスター リソースが不足したり無駄になったりする問題を解決するために、descheduler コンポーネントを使用してクラスター Pod のスケジュールを最適化できます。 Descheduler は、いくつかのルールと構成ポリシーに従ってクラスターのステータスを再調整するのに役立ちます。その基本原則は、ポリシー構成に従って削除できるポッドを見つけて排除することです。削除されたポッド自体をスケジュールするのではなく、デフォルトのスケジューラに依存してこれを実現します。現在サポートされているポリシーは次のとおりです。

  • 重複を削除
  • 低ノード使用率
  • 高いノード使用率
  • ポッドの削除、ポッド間の反アフィニティ違反
  • ノードアフィニティに違反しているポッドを削除します
  • ポッド違反ノードテイントの削除
  • トポロジー拡散制約に違反しているポッドを削除します
  • 再起動が多すぎるポッドを削除する
  • ポッドライフタイム
  • 失敗したポッドの削除

これらのポリシーは有効または無効にできます。ポリシーの一部として、ポリシー関連のパラメータも設定できます。デフォルトでは、すべてのポリシーが有効になっています。さらに、次のような一般的な構成がいくつかあります。

  • nodeSelector: 処理するノードを制限する
  • evictLocalStoragePods: LocalStorage を使用して Pod を削除する
  • ignorePvcPods: PVCで設定されたPodを無視するかどうか。デフォルトはFalseです。
  • maxNoOfPodsToEvictPerNode: ノードから排除できるポッドの最大数

以下に示すように、DeschedulerPolicy を通じてこれを構成できます。 

 apiVersion : "descheduler/v1alpha2"
種類: "DeschedulerPolicy"
 nodeSelector : "node=node1" #設定されていない場合は、これを設定せずにすべてのコンテンツが処理されます。
 maxNoOfPodsToEvictPerNode : 5000 #設定されていない場合は制限は必要ありません。
名前空間あたりのポッドの最大追放数: 5000
プロフィール:
 -名前:プロフィール名
プラグイン設定:
 -名前: "DefaultEvictor"
引数:
 evictSystemCriticalPods : true です
失敗したベアポッドの排除: true
ローカルストレージポッドの排除: true
ノードフィット: true
プラグイン:
立ち退き：
有効:
 - 「デフォルトエビクター」
スケジュール解除:
有効:
 - ...
バランス：
有効:
 - ...
 [...]

インストール

デスケジューラは、CronJob または Deployment として k8s クラスターで実行できます。 Helm Chart を使用して descheduler をインストールすることもできます。 

 ➜ Helm リポジトリ追加デスケジューラー https://kubernetes-sigs.github.io/descheduler/

Helm Chart を通じて、デスケジューラを CronJob または Deployment として実行するように構成できます。デフォルトでは、デスケジューラは、それ自体または kubelet によって削除されるのを避けるために、重要なポッドとして実行されます。クラスター内に system-cluster-critical Priorityclass が存在することを確認する必要があります。 

 ➜ kubectl でシステムクラスタのクリティカルな優先度クラスを取得します
名前 値 グローバル デフォルト 年齢
システム クラスタ クリティカル 2000000000 偽 87d

Helm Chart を使用してインストールすると、デフォルトではスケジュールの実行期間が「*/2 * * * *」の CronJob として実行されます。これは、デスケジューラ タスクが 2 分ごとに実行されることを意味します。デフォルトの構成戦略は次のとおりです。 

 APIバージョン: v1
種類: ConfigMap
メタデータ:
名前:デスケジューラ
データ：
ポリシー。 yaml : |
 apiVersion : "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
低ノード使用率:
有効: true
パラメータ:
ノードリソース使用率しきい値:
ターゲットしきい値:
 CPU : 50
メモリ: 50
ポッド： 50
閾値:
 CPU : 20
メモリ: 20
ポッド： 20
重複を削除:
有効: true
再起動が多すぎるポッドを削除します:
有効: true
パラメータ:
 podsHavingTooManyRestarts :
 includingInitContainers : true
ポッド再起動しきい値: 100
ポッド間のアンチアフィニティに違反しているポッドを削除します:
有効: true
ポッド違反ノードアフィニティを削除します:
有効: true
パラメータ:
ノードアフィニティタイプ:
 -スケジュール中は必須、実行中は無視
ポッド違反ノードテイントを削除します:
有効: true
トポロジースプレッド制約に違反するポッドを削除します:
有効: true
パラメータ:
 includeSoftConstraints :偽

DeschedulerPolicy の戦略を構成することで、descheduler の実行戦略を指定できます。これらの戦略は有効または無効にできます。以下で詳しく紹介させていただきます。ここではデフォルトの戦略を使用し、次のコマンドを使用して直接インストールできます。 

 ➜ helm upgrade --install descheduler descheduler/descheduler --set image.repository=cnych/descheduler -n kube-system

デプロイメントが完了すると、クラスターのステータスのバランスをとるために CronJob リソース オブジェクトが作成されます。 

 ➜ kubectl get cronjob -n kube-system
名前 スケジュール 一時停止 アクティブ 最終スケジュール 年齢
デスケジューラ */2 * * * * False 1 8s 117s
 ➜ kubectl get job -n kube-system
名前 完了 期間 年齢
スケジューラ-28032982 1/1 15秒 17秒
➜ kubectl get pods -n kube-system -l job-name=descheduler-28032982
名前 準備完了 ステータス 再起動 年齢
descheduler-28032982-vxn24 0/1 完了 0 31秒

通常の状況では、デスケジューラ タスクを実行するために対応するジョブが作成されます。ログを確認すると、どのようなバランス調整操作が実行されたかがわかります。 

 ➜ kubectlログ- f descheduler - 28032982 - vxn24 - nkube - system
 I0420 08 : 22 : 10.019936 1 つの名前付き証明書。 go : 53 ] "SNI 証明書をロードしました" index = 0 certName = "自己署名ループバック" certDetail = "\"apiserver-loopback-client@1681978930\" [serving] validServingFor=[apiserver-loopback-client] issuer=\"apiserver-loopback-client-ca@1681978929\" (2023-04-20 07:22:09 +0000 UTC から 2024-04-19 07:22:09 +0000 UTC (現在 = 2023-04-20 08:22:10.019885292 +0000 UTC))"
 I0420 08 : 22 : 10.0201381 secure_serving 。 go : 210 ] [::]: 10258で安全に配信中
I0420 08 : 22 : 10.0203011tlsconfig 。 go : 240 ] "DynamicServingCertificateController を起動しています"
 I0420 08 : 22 : 10.021237 1ポリシー構成。 go : 211 ] Descheduleプラグインを変換しています: % sRemovePodsViolatingInterPodAntiAffinity
 I0420 08 : 22 : 10.021255 1ポリシー構成。 go : 211 ] Descheduleプラグインを変換しています: % sRemovePodsViolatingNodeAffinity
 I0420 08 : 22 : 10.021262 1ポリシー構成。 go : 211 ] Descheduleプラグインを変換しています: % sRemovePodsViolatingNodeTaints
 I0420 08 : 22 : 10.021269 1ポリシー構成。 go : 202 ] Balanceプラグインを変換しています: % sRemovePodsViolatingTopologySpreadConstraint
 I0420 08 : 22 : 10.021280 1ポリシー構成。 go : 202 ] Balanceプラグインを変換中: % sLowNodeUtilization
 I0420 08 : 22 : 10.021296 1ポリシー構成。 go : 202 ] Balanceプラグインの変換: % sRemoveDuplicates
 I0420 08 : 22 : 10.021312 1ポリシー構成。 go : 211 ] Descheduleプラグインを変換しています: % sRemovePodsHavingTooManyRestarts
 # ......
 I0420 08 : 22 : 11.630980 1重複を削除しました。 go : 162 ] "重複が見つかりました" pod = "kruise-system/kruise-controller-manager-7d78fc5c97-pxsqx"
 I0420 08 : 22 : 11.630997 1重複を削除しました。 go : 103 ] "処理ノード" node = "node2"
 I0420 08 : 22 : 11.631052 1重複を削除しました。 go : 103 ] "処理ノード" node = "node3"
 I0420 08 : 22 : 11.631113 1重複を削除しました。 go : 103 ] "処理ノード" node = "master1"
 I0420 08 : 22 : 11.631184 1重複を削除しました。 go : 194 ] 「実行可能なノードの調整」 owner = { namespace : kruise - system kind : ReplicaSet name : kruise - controller - manager - 7 d78fc5c97 imagesHash : openkruise / kruise - manager : v1 .3 .0 } from = 4 to = 3
 I0420 08 : 22 : 11.631200 1重複を削除しました。 go : 203 ] "ノードあたりの平均発生回数" node = "node1" ownerKey = { namespace : kruise - system kind : ReplicaSet name : kruise - controller - manager - 7 d78fc5c97 imagesHash : openkruise / kruise - manager : v1 .3 .0 } avg = 1
 I0420 08 : 22 : 11.647438 1立ち退き。 go : 162 ] "ポッドが削除されました" pod = "kruise-system/kruise-controller-manager-7d78fc5c97-pxsqx" reasnotallow = "" strategy = "RemoveDuplicates" node = "node1"
 I0420 08 : 22 : 11.647494 1 つのスケジュール解除者。 go : 408 ] "排除されたポッドの数" totalEvicted = 1
 I0420 08 : 22 : 11.647583 1反射鏡。 go : 227 ]リフレクタを停止しています* v1 。 k8sからの名前空間( 0 s )。 io /クライアント- go /インフォーマー/ファクトリー。行く： 150
 I0420 08 : 22 : 11.647702 1反射鏡。 go : 227 ]リフレクタを停止しています* v1 。 k8sからのPriorityClass ( 0 s )。 io /クライアント- go /インフォーマー/ファクトリー。行く： 150
 I0420 08 : 22 : 11.647761 1 tlsconfig . go : 255 ] "DynamicServingCertificateController をシャットダウンしています"
 I0420 08 : 22 : 11.647764 1反射鏡。 go : 227 ]リフレクタを停止しています* v1 。 k8sからのノード( 0 s )。 io /クライアント- go /インフォーマー/ファクトリー。行く： 150
 I0420 08 : 22 : 11.647811 1 secure_serving 。 go : 255 ] [::]のリスニングを停止しました: 10258
 ......

ログから、どのポリシーによってどの Pod が削除されたかを明確に知ることができます。

電子データ

デスケジューラは再スケジュールのためにポッドを削除するため、サービスのすべてのレプリカが削除されると、サービスが利用できなくなる可能性があります。サービス自体に単一障害点がある場合、削除によってサービスが利用できなくなることは間違いありません。この場合、単一障害点を回避するために、アンチアフィニティと複数のレプリカを使用することを強くお勧めします。ただし、サービス自体が複数のノードに分散しており、これらのポッドが削除された場合、サービスも利用できなくなります。この場合、すべてのレプリカが同時に削除されないように PDB (PodDisruptionBudget) オブジェクトを構成できます。たとえば、削除中にアプリケーションのレプリカを最大 1 つだけ使用できないように設定できます。次に、以下に示すようにリソース リストを作成します。 

 # pdb -デモ.yaml
 apiバージョン:ポリシー/ v1
種類: PodDisruptionBudget
メタデータ:
名前: pdb -デモ
仕様:
 maxUnavailable : 1 #利用できないレプリカの最大数を設定するか、整数またはパーセンテージのminAvailableを使用します
セレクター:
 matchLabels : #Podラベルを一致させる
アプリ:デモ

PDB の詳細については、公式ドキュメント (https://kubernetes.io/docs/tasks/run-application/configure-pdb/) を参照してください。

したがって、デスケジューラを使用してクラスターの状態を再調整する場合は、保護のためにアプリケーションに対応する PodDisruptionBudget オブジェクトを作成することを強くお勧めします。

戦略

PodLifeTime: 指定された時間制限を超えたポッドを排除する

このポリシーは、maxPodLifeTimeSeconds より古い Pod を削除するために使用されます。 podStatusPhases を使用して、どの状態の Pod を削除するかを設定できます。アプリケーションの可用性を確保するために、アプリケーションごとに PDB を作成することをお勧めします。たとえば、7 日以上実行されている Pod を削除するには、次のポリシーを構成できます。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「ポッドの寿命」:
 有効: true
 パラメータ:
 maxPodLifeTimeSeconds: 604800 # ポッドは最大7日間実行されます

重複を削除

この戦略により、ポッドに関連付けられた RS、デプロイメント、またはジョブ リソース オブジェクトが 1 つだけ同じノード上で実行されるようになります。より多くのポッドがある場合、これらの重複したポッドは削除され、ポッドがクラスター全体に分散されます。これは、何らかの理由で一部のノードがクラッシュし、これらのノード上の Pod が他のノードに移動し、RS に関連付けられた複数の Pod が同じノード上で実行される場合に発生する可能性があります。障害が発生したノードが再び準備できたら、このポリシーを有効にして重複したポッドを排除できます。

ポリシーを構成するときに、excludeOwnerKinds パラメータを指定してタイプを除外できます。次のタイプのポッドは削除されません: 

 apiVersion : "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「重複を削除」 :
有効: true
パラメータ:
重複を削除:
所有者の種類を除外:
 - 「レプリカセット」

低ノード使用率

この戦略は主に、十分に活用されていないノードを見つけて他のノードからポッドを排除し、kube-scheduler が十分に活用されていないノードにポッドを再スケジュールできるようにするために使用されます。この戦略のパラメータは、フィールド nodeResourceUtilizationThresholds を通じて構成できます。

ノードの使用率が低いかどうかは、CPU、メモリ、およびポッドの数のパーセンテージとして設定できるしきい値パラメータを設定することで判断できます。ノードの使用率がすべてのしきい値を下回る場合、そのノードは十分に使用されていないとみなされます。

さらに、Pod を排除する可能性のあるノードを計算するために使用される、構成可能なしきい値 targetThresholds があります。このパラメータは、CPU、メモリ、およびポッドの数のパーセンテージとして構成することもできます。次の例に示すように、thresholds と targetThresholds はクラスターのニーズに基づいて動的に調整できます。 

 apiVersion : "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「低ノード使用率」 :
有効: true
パラメータ:
ノードリソース使用率しきい値:
閾値:
 「CPU」 : 20
 「メモリ」 : 20
 「ポッド」 ： 20
ターゲットしきい値:
 「CPU」 : 50
 「メモリ」 : 50
 「ポッド」 ： 50

以下の点に注意してください。

  • サポートされるリソースタイプは次の3つのみです: cpu、memory、pods
  • しきい値とターゲットしきい値は同じタイプで設定する必要があります
  • パラメータ値は0から100（パーセントシステム）までアクセスされます
  • 同じリソースタイプの場合、しきい値設定はtargetThresholds設定より高くすることはできません。

リソース タイプが指定されていない場合、ノードが十分に使用されていない状態から過剰に使用されていない状態に移行するのを防ぐために、デフォルトは 100% になります。 LowNodeUtilization 戦略に関連付けられているもう 1 つのパラメーターは numberOfNodes です。このパラメータは、使用率の低いノードの数がこの設定値より大きい場合にのみ戦略をアクティブにするように設定できます。このパラメータは、一部のノードが頻繁に使用されたり、短期間で十分に使用されなかったりする可能性がある大規模なクラスターに非常に役立ちます。デフォルトでは、numberOfNodes は 0 です。

ポッドの削除、ポッド間の反アフィニティ違反

このポリシーにより、Pod のアンチアフィニティに違反する Pod がノードから削除されます。たとえば、ノードに PodA があり、同じノードで実行されている podB と podC に同じノードでの実行を禁止するアンチアフィニティ ルールがある場合、podA はノードから削除され、podB と podC は正常に実行できるようになります。この問題は、podB と podC がノード上ですでに実行された後にアンチアフィニティ ルールが作成された場合に発生します。

このポリシーを無効にするには、単に false に設定します。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「ポッド間のアンチアフィニティに違反しているポッドを削除します」:
 有効: false

ポッド違反ノードテイントの削除

このポリシーにより、NoSchedule 汚染に違反する Pod がノードから削除されます。たとえば、podA という名前の Pod は、許容度キー = 値:NoSchedule を構成することによって、汚染が構成されたノードにスケジュールできます。その後、ノードのテイントが更新または削除されると、テイントはポッドの許容範囲を満たさなくなり、削除されます。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「PodsViolatingNodeTaints を削除します」:
 有効: true

ノードアフィニティに違反しているポッドを削除します

このポリシーにより、ノードアフィニティに違反するポッドがノードから削除されます。たとえば、podA という名前の Pod がノード nodeA にスケジュールされます。スケジュール中に、podA はノード アフィニティ ルール requiredDuringSchedulingIgnoredDuringExecution を満たします。しかし、時間が経つにつれて、ノード nodeA はルールを満たさなくなります。ノード アフィニティ ルールを満たす別のノード nodeB が利用可能な場合、podA はノード nodeA から削除されます。以下はポリシー構成の例です。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「ノードアフィニティに違反しているポッドを削除します」:
 有効: true
 パラメータ:
 ノードアフィニティタイプ:
 - 「実行中にスケジュールが必要で無視される」

トポロジー拡散制約に違反しているポッドを削除します

この戦略により、トポロジ分散制約に違反するポッドがノードから確実に排除されます。具体的には、各制約の​maxSkew​内でトポロジ ドメインのバランスをとるために必要な最小数の Pod を排除しようとします。ただし、この戦略を使用するには、k8s バージョン 1.18 以降が必要です。

デフォルトでは、この戦略はハード制約のみを処理しますが、パラメーター​includeSoftConstraints​ True に設定すると、ソフト制約もサポートされます。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「トポロジー拡散制約に違反しているポッドを削除します」:
 有効: true
 パラメータ:
 includeSoftConstraints: 偽

再起動が多すぎるポッドを削除する

このポリシーにより、再起動回数が多すぎる Pod がノードから削除されます。パラメータには、Pod を削除するまでの再起動回数である podRestartThreshold と、計算で init コンテナの再起動を考慮するかどうかを決定する InitContainers が含まれます。ポリシー構成は次のとおりです。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「再起動が多すぎるポッドを削除します」:
 有効: true
 パラメータ:
 podsHavingTooManyRestarts:
 ポッド再起動しきい値: 100
 includingInitContainers: true

フィルターポッド

Pod を削除する場合、すべての Pod を削除する必要がない場合があります。 Descheduler には、名前空間フィルタリングと優先度フィルタリングという 2 つの主要なフィルタリング方法が用意されています。

名前空間フィルタリング

特定の名前空間を含めるか除外するかをポリシーで設定できます。この戦略を使用できるのは次の場合です。

  • ポッドライフタイム
  • 再起動が多すぎるポッドを削除する
  • ポッド違反ノードテイントの削除
  • ノードアフィニティに違反しているポッドを削除します
  • ポッドの削除、ポッド間の反アフィニティ違反
  • 重複を削除
  • トポロジー拡散制約に違反しているポッドを削除します

たとえば、特定の名前空間内の Pod のみを削除する場合は、次に示すように include パラメータを使用して設定できます。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「ポッドの寿命」:
 有効: true
 パラメータ:
 ポッドの寿命:
 最大ポッドライフタイム秒数: 86400
 名前空間:
 含む：
 - 「名前空間1」
 - 「名前空間2」

または、特定の名前空間内の Pod を除外する場合は、次のように exclude パラメータ設定を使用できます。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「ポッドの寿命」:
 有効: true
 パラメータ:
 ポッドの寿命:
 最大ポッドライフタイム秒数: 86400
 名前空間:
 除外:
 - 「名前空間1」
 - 「名前空間2」

優先フィルタリング

すべてのポリシーは優先度しきい値を使用して構成でき、このしきい値を下回るとポッドが削除されます。このしきい値は、thresholdPriorityClassName (しきい値を指定された優先クラスの値に設定する) または thresholdPriority (しきい値を直接設定する) を設定することによって指定できます。デフォルトでは、しきい値は system-cluster-critical PriorityClass の値に設定されています。

たとえば、thresholdPriority を使用する場合: 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「ポッドの寿命」:
 有効: true
 パラメータ:
 ポッドの寿命:
 最大ポッドライフタイム秒数: 86400
 しきい値優先度: 10000

または、thresholdPriorityClassName を使用してフィルタリングします。 

 apiVersion: "descheduler/v1alpha1"
種類: "DeschedulerPolicy"
戦略:
 「ポッドの寿命」:
 有効: true
 パラメータ:
 ポッドの寿命:
 最大ポッドライフタイム秒数: 86400
 しきい値優先度クラス名: "優先度クラス1"

ただし、thresholdPriority と thresholdPriorityClassName を同時に設定することはできないことに注意してください。指定された優先クラスが存在しない場合、デスケジューラはそれを作成せず、エラーが発生します。

予防

descheduler を使用して Pod を削除する場合は、次の点に注意してください。

  • priorityClassName が system-cluster-critical または system-node-critical に設定されている Pod などの重要な Pod は削除されません。
  • RS、デプロイメント、またはジョブによって管理されていないポッドは削除されません。
  • DaemonSet によって作成されたポッドは削除されません。
  • LocalStorage を使用する Pod は、evictLocalStoragePods: true が設定されていない限り削除されません。
  • ignorePvcPods: true が設定されていない限り、PVC を持つ Pod は削除されません。
  • LowNodeUtilization および RemovePodsViolatingInterPodAntiAffinity ポリシーでは、Pod は低優先度から高優先度へと削除されます。優先度が同じ場合、Besteffort Pod は Burstable Pod および Guaranteed Pod よりも先に削除されます。
  • アノテーションに descheduler.alpha.kubernetes.io/evict フィールドがあるポッドは削除できます。このアノテーションは、削除を防止するチェックをオーバーライドするために使用され、ユーザーは削除する Pod を選択できます。
  • Pod の削除に失敗した場合は、--v=4 を設定して、デスケジューラ ログから理由を見つけることができます。削除が PDB 制約に違反する場合、そのような Pod は削除されません。

<<:  クラウドネイティブアプリケーションの完全なライフサイクル管理

>>:  世界のクラウド支出はIaaSの牽引により21.7%増加すると予想されている

推薦する

キーワードのランキングを決定する2つの要素

検索エンジンでキーワードの順位が変わるのはよくあることで、ウェブマスターなら誰でもよく目にするもので...

Red Hat Enterprise Linux 7.6がリリースされ、ハイブリッドクラウドのイノベーションがさらに最適化されました。

オープンソース ソリューションのリーディング プロバイダーである Red Hat, Inc. (NY...

moguhost-韓国の高速BGP回線VPSの簡単なレビュー

今日は、Mushroom Host [moguhost.com] の韓国 VPS をテストします。H...

SEO シリーズ: ロングテールキーワードのトラフィックを増やす方法

みなさんこんにちは。私はハン・イージョウです。今日は、ロングテールキーワードをウェブサイトに取り込む...

Leica Cloud: クラウドサーバーは月額 9.9 元から (更新価格は同じ/2G メモリ/2 コア/30g SSD/10M 帯域幅)、オプションのデータセンター - 香港/韓国/米国/鎮江/宿遷/紹興/揚州/棗荘

lcayun/Leica Cloudは今月、超特別プロモーションを実施しています。2Gメモリ、2コア...

簡単な分析: Baidu 入札ランディング ページ効果分析

数日前、私は「Baidu 入札の単位原価計算」と「Baidu 入札の図解分析: 期間分析」という 2...

ウェブサイト診断 - 新しいウェブサイトの分析

新しいウェブサイトの診断と分析には、一般的に 2 つの状況があります。1 つは新しいウェブサイトの運...

北京に拠点を置く電子商取引企業は、価格詐欺の再発を防ぐためにプロモーションを規制する必要がある。

昨日の夕方、「ダブル11」が近づく中、北京市発展改革委員会が北京の電子商取引企業に販促指導通知を発行...

Alibaba Cloud は素晴らしい特典を提供しています。ダブル 11 期間中は、既存ユーザーはさらに 12% オフ、新規ユーザーは 25% オフになります。また、ビジネス チャンスを推奨するとボーナス残高を獲得することもできます。

Alibaba Cloud には以前からパートナー制度があり、従来のモデルでは公式サイトに登録した顧...

Bacloud-$29.99/E3-1230V2/8gメモリ/1Tハードディスク/100M無制限

リトアニアのホスティング プロバイダーである Bacloud.com には、独自のデータ センターが...

アリババクラウドとそのパートナーは、10の業界をカバーする20のシナリオベースのソリューションをリリースしました。

7月13日、2022 Alibaba Cloud パートナーカンファレンスにおいて、20社以上のパー...

フォーラムの外部リンクを作成する方法

みなさんこんにちは。私はみんなに愛され、どこに行っても花を咲かせる Yan Fengshou です。...

簡単な議論：インターネットマーケティングは実際にはそれほど単純でも難しくもありません

中国インターネットネットワークインフォメーションセンター（CNNIC）は今年1月に第33回「中国イン...

Kubernetes スレーブ ノードが参加に失敗するのはなぜですか?

[[398367]]この記事はWeChatの公開アカウント「プログラマーjinjunzhu」から転載...

フォックスコンがLeTV TVに1億3000万元を投資：インターネット動画の情勢が変化

アップルからシャオミの携帯電話まで、「飢餓マーケティング」は常に消費者を待ち続けることで道に迷わせて...