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.1.2 利点

2.1.2 利点Yii は学習も使用も簡単です。ユーザーは、事前に新しいアーキテクチャやテンプレート...

草の根フォーラム: オンライン採用がなぜすべての人を惹きつけるのか

インターネットはプラットフォームです。さまざまなリソースがそこに流入し、ネットワーク プラットフォー...

SEO ルールが頻繁に更新されるウェブマスターにとって、将来の希望は何でしょうか?

SEO ルールが頻繁に更新されるウェブマスターにとって、将来の希望は何でしょうか?今年5月に百度がル...

記事ページが多すぎるとSEOにどのような影響が出るかについて簡単に説明します

多くの有名なポータルサイトの影響を受けているのかもしれませんが、多くのウェブマスターが短い記事を無理...

観光電子商取引の進化：価格競争が始まると観光客は笑う

観光の進化における電子商取引近年、国の観光業の発展に伴い、オンライン旅行サイト、旅行電子商取引、モバ...

クラウド化、値下げ、苦難を乗り越えたクラウドコンピューティングはどこへ向かうのか？

クラウド コンピューティング業界を一文で要約すると、「あらゆる「災難」にもかかわらず、業界は前進を続...

分散型高並列キャッシュ設計システム

概要キャッシュの概要キャッシュとはWiki でのキャッシュの定義: データへの後続のアクセスを高速化...

オンライン採用のプロセスで言及しなければならない協同運営の特徴

タレント運用のスキルについては、ここ数日、何人かの友人が十分に言っています。運用事例と運用アイデアが...

YY社、IPO価格帯を決​​定、最大9,750万ドルを調達

新浪科技ニュース：北京時間11月8日朝のニュース、YY社は本日、米国証券取引委員会（SEC）にF-1...

kvmla-香港 VPS/127 元/メモリ 4g/ハードディスク 65g/トラフィック無制限//Windows 中国語版

kvmla.pro の香港データセンターが補充されました: 沙田データセンターと PN データセンタ...

Stablehost が 30% 割引の VPS 製品をリリース

皆さんの stablehost との接点は、仮想ホストから始まったと思います。安定していて信頼できる...

リンク交換の成功率を高める4つのポイントの解説

1: ウェブサイトの状態を理解するこのステータスは主に、スナップショット時間、スナップショット頻度、...

racknerd: 「618」、ロサンゼルス VPS、60G の高防御、年間 59 ドル、KVM/5G メモリ/3 コア/80g ハードディスク/10T トラフィック/1Gbps 帯域幅

Racknerd の 618 イベント: ロサンゼルスの Multacom および Sharktec...

中国SEO業界の奇妙な現状についてのコメント

昨日、ロビンはDianshiのVIPメンバーとこの非常に興味深いトピックについて話し合いました。私は...

「チャイナパートナーズ」が優れたウェブサイトの運営方法を教えてくれる

数日前、映画館に行って、最近公開された感動的な映画「チャイニーズ・パートナーズ」を見ました。この映画...