この記事は、Kubernetes アーキテクチャの設計意図、Kubernetes システムのアーキテクチャ開発と進化、そしてその背後にある原動力を理解するのに役立ちます。 1. 背景 すべてのプラットフォームは、プラットフォームに何を含めるべきか、何を含めるべきでないかについての避けられない問題に直面しますが、Kubernetes も例外ではありません。コンテナをデプロイおよび管理するためのプラットフォームとして、Kubernetes はユーザーのすべての問題を解決することはできませんし、そうすべきでもありません。 Kubernetes は、ユーザーがコンテナ化されたアプリケーションを実行したり、それらの拡張機能を構築したりできる基本的な機能を提供する必要があります。この記事の目的は、Kubernetes アーキテクチャの設計意図を明確にし、Kubernetes の進化と将来の開発の青写真を説明することです。 この記事では、Kubernetes システム アーキテクチャの進化とその背後にある理由について説明します。 Kubernetes システムを拡張またはカスタマイズしたい開発者は、このドキュメントをガイドとして使用し、拡張機能をどこにどのように実装できるかを理解する必要があります。アプリケーション開発者が大規模で移植性があり、将来性も考慮した Kubernetes アプリケーションを開発する必要がある場合は、Kubernetes の将来の進化と開発を理解するためにこのドキュメントも参照する必要があります。 論理的には、Kubernetes のアーキテクチャは次のレベルに分かれています。
2. システムの階層化 Linux にカーネル、コア システム ライブラリ、オプションのユーザー レベル ツールがあるのと同様に、Kubernetes にも機能とツールのレイヤーがあります。開発者にとってこれらのレベルを理解することは非常に重要です。 Kubernetes API、概念、および機能は、次のレイヤー図に示されています。 2.1 核: APIと実行 コア層には、コア API と実行エンジンが含まれています。 これらの API と関数は、アップストリーム Kubernetes コードベースによって実装され、システムの上位層に必要な最小限の機能と概念のセットから構成されます。 アップストリーム Kubernetes コードベースによって実装されるこれらの API と関数には、高レベルのシステムを構築するために必要な最小限の機能と概念のセットが含まれています。これらは明確に指定され、文書化されており、コンテナ化されたすべてのアプリケーションで使用されます。開発者は、コンテンツは常に存在しており、そのコンテンツは安定していて退屈なものになるはずだと安心して想定できます。 2.1.1 APIとクラスターコントロールパネル Kubernetes クラスターは、Kubernetes API サーバーを通じて公開され、永続リソースの追加、削除、変更、クエリをサポートする一連の REST API を提供します。これらの API はコントロール パネルのハブとして機能します。 Kubernetes API 規則 (パス規則、標準メタデータなど) に従う REST API は、共有 API サービス (認証、承認、監査ログ) のメリットを自動的に享受でき、汎用クライアント コードでそれらを操作できます。 システムの最下層として、上位層が機能を追加できるように、必要な拡張メカニズムをサポートする必要があります。さらに、シングルテナントおよびマルチテナントのアプリケーション シナリオをサポートする必要があります。コア層は、セキュリティ モデルを損なうことなく上位層が新しいスコープを拡張できるように十分な柔軟性も提供する必要があります。 Kubernetes は、次の基本的な API とセマンティクスがなければ適切に動作しません。 認証: 認証メカニズムは非常に重要なタスクです。 Kubernetes では、サーバーとクライアントの両方で認証される必要があります。 API サーバーは、基本認証 (ユーザー名/パスワード) (これは将来廃止される予定です)、X.509 クライアント証明書、OpenID Connect トークン、およびベアラー トークンをサポートしています。 kubeconfig のサポートにより、クライアントは上記のさまざまな認証モードを使用できます。サードパーティの認証システムは、TokenReview API を実装し、認証 Webhook を構成することによってそれを呼び出すことができます。これにより、非標準の認証メカニズムを通じて利用可能なクライアントの数を制限できます。
承認:サードパーティの承認システムは、SubjectAccessReview API を実装し、承認 Webhook を構成することでそれを呼び出すことができます。 SubjectAccessReview (フックと同じメカニズム)、LocalSubjectAccessReview、および SelfSubjectAccessReview API を使用すると、Kubelet やその他のコントローラーなどの外部権限チェックが可能になります。
NIY: 組み込みのアドミッション制御セマンティクス、同期アドミッション制御フック、非同期リソース初期化 - パブリッシャー、システムインテグレーター、およびクラスタ管理者は追加のポリシーと自動化を実装します。 NIY: API の登録と公開 (API の集約、追加の API の登録、サポートされている API の公開、サポートされている操作、ペイロード、結果スキーマの詳細の取得など)。 NIY: ThirdPartyResource および ThirdPartyResourceData API (またはその後継)、サードパーティのストレージおよび拡張 API のサポート。 NIY: クラスタが完全に存在し、正しく動作しているかどうかを判断するための Componentstatuses API のスケーラブルで可用性の高い代替手段: ExternalServiceProvider (コンポーネント登録) エンドポイント API、コンポーネントの蓄積ニーズ、API サーバーエンドポイントの自己公開、高可用性、アプリケーション層ターゲットの公開 名前空間 API、ユーザー リソースのスコープ、名前空間のライフサイクル (例: 一括削除) イベントAPIは、状態の変化やエラーなどの重要なイベントの報告や、イベントのガベージコレクションに使用されます。 NIY: カスケード削除ガベージ コレクター、ファイナライズ、および孤立化 NIY: ホストからコンポーネントを自動的に追加し、それらをクラスターに動的に構成して、実行中のクラスターから機能を抽出するには、組み込みのアドオン マネージャーが必要です。
API サーバーはクラスターへのゲートウェイとして機能します。定義上、API サーバーはクラスター外部のクライアントからアクセス可能である必要がありますが、ノードとポッドはクラスター外部のクライアントからアクセスできません。クライアントはAPIサーバーを認証し、それを要塞およびプロキシ/チャネルとして使用して、/proxyおよび/portforward APIを介してノードとポッドにアクセスします。 未定: 証明書、具体的には kubele 証明書の作成を可能にする CertificateSigningRequest API。 理想的には、コア API サーバーは最小限必要な API のみをサポートし、追加機能は集約、フック、初期化子、およびその他の拡張メカニズムを通じて提供される必要があります。集中型の非同期コントローラーは、ガベージ コレクションと同様に、コントローラー マネージャーと呼ばれる別のプロセスで実行されることに注意してください。 API サーバーは次の外部コンポーネントに依存します。
2.1.2 実行 Kubernetes で最も重要なコントローラーは kubelet であり、これは Pod と Node API の主な実装者です。これらの API がなければ、Kubernetes はキー値ストレージによってサポートされる REST アプリケーション フレームワークのみになります (後で、API マシンは最終的に別のプロジェクトになる可能性があります)。 Kubernetes は、デフォルトでスタンドアロン アプリケーション コンテナーとローカル モードを実装します。 Kubernetes は、複数のコンテナとストレージ ボリュームを管理する Pod を提供します。ポッドは Kubernetes における最も基本的な実行単位です。 Kubelet API セマンティクスには以下が含まれます。 Kubernetes 実行ユニットである Pod API には以下が含まれます。 1) ポッド実現可能性のアドミッション制御は、ポッド API のポリシー (リソース要求、ノード セレクター、ノード/ポッドのアフィニティとアンチアフィニティ、テイントと許容値) に基づいています。 API アドミッション コントロールはポッドを拒否したり、追加のスケジューリング制約を追加したりできますが、ポッドが最終的にどのノードで実行されるかを決定するのはスケジューラや DaemonSet ではなく、Kubelet です。 2) コンテナとストレージボリュームのセマンティクスとライフサイクル 3) ポッド IP アドレスの割り当て (各ポッドにはルーティング可能な IP アドレスが必要です) 4) ポッドを特定のセキュリティスコープ(ServiceAccountなど)に接続するためのメカニズム 5) ストレージボリュームソース:
6) サブリソース: バインディング、ステータス、実行、ログ、アタッチ、ポート転送、プロキシ
コンテナイメージとログのライフサイクル
a.一部の構成では、クラスタ管理者にのみ表示されることがあります。
b.クラウドプロバイダー固有のノードインベントリ機能は、プロバイダー固有のコントローラーに分離する必要があります。
紀元前クラウド プロバイダー固有のアタッチ/デタッチ ロジックは、プロバイダー固有のコントローラーに分離する必要があります。 API からプロバイダー固有のストレージ ボリューム ソースを抽出する方法が必要です。
d. NIY: 少なくともローカルストレージでサポートされている
コントローラー マネージャーによって実行されるポッド終了ガベージ コレクションなどの非同期機能を一元化します。 現在、コントロール フィルターと kubelet は「クラウド プロバイダー」インターフェースを呼び出して、インフラストラクチャ レイヤーから情報を照会し、インフラストラクチャ リソースを管理します。ただし、Kubernetes はこれらのタッチポイント (問題) を外部コンポーネントに抽象化しようとしています。外部コンポーネントでは、満たされないアプリケーション/コンテナ/OS レベルのリクエスト (PODS、PersistentVolumeClaims など) が外部の「動的プロビジョニング」システムへのシグナルとして使用され、インフラストラクチャがこれらのリクエストを満たすことができるようになります。また、Kubernetes ではインフラストラクチャ リソース (Node、PersistentVolumes など) を使用してこれらのリクエストが表現されるため、Kubernetes はリクエストとインフラストラクチャ リソースを結び付けることができます。 kubelet の場合、次の拡張可能なコンポーネントに依存します。
また、次の要因に依存する可能性があります:
2.2 アプリケーション層: デプロイメントとルーティング アプリケーション管理および構成レイヤーは、自己修復、スケーラビリティ、アプリケーション ライフサイクル管理、サービス検出、負荷分散、ルーティング (サービス オーケストレーションおよびサービス ファブリックとも呼ばれます) を提供します。これらの API と機能は、すべての Kubernetes ディストリビューションに必要です。 Kubernetes はこれらの API のデフォルト実装を提供する必要がありますが、代替実装を使用することもできます。アプリケーション層 API がなければ、ほとんどのコンテナ化されたアプリケーションは実行できません。 Kubernetes の API は、IaaS のようなコンテナ中心のインフラストラクチャと、すべてのワークロードのオーケストレーション (自己修復、スケーリング、更新、終了) をサポートするライフサイクル コントローラーを提供します。これらのアプリケーション管理、構成、検出、ルーティング API と機能には、次のものが含まれます。
NIY: 再スケジューラーは、スケジュールされたポッドをリアクティブかつプロアクティブに削除し、他のノードに置き換えて再スケジュールできるようにします。 継続的に実行されるアプリケーション: このタイプのアプリケーションは、宣言的な更新、カスケード削除、および孤立/採用のサポートを使用してリリース (ロールバック) できる必要があります。 DaemonSet に加えて、水平拡張もサポートする必要があります。
バッチアプリケーションの終了: これには、終了したジョブの自動削除 (NIY) が含まれる必要があります。
検出、負荷分散、ルーティング
アプリケーション層は以下に依存できます。
2.3 ガバナンス層: 自動化とポリシーの適用 ポリシーの適用と高度な自動化。これらの API と機能はアプリケーションを実行するためのオプションであり、他のソリューションによって実装する必要があります。 サポートされている各 API/関数は、エンタープライズ運用、セキュリティ、ガバナンスのシナリオの一部として適用されます。 少なくとも次のユースケースをサポートする、クラスターの可能な構成と検出のデフォルト戦略を提供する必要があります。
注意すべき点:
自動化 API と機能:
1. デフォルトのストレージボリュームタイプの実装が少なくとも1つあるStorageClass API
ポリシー API と関数: 認可: ABAC および RBAC 認可ポリシー ソリューション 1. RBAC、次のAPIを実装します: Role、RoleBinding、ClusterRole、ClusterRoleBinding
管理は以下に依存します。
2.4 インターフェース層: クラスライブラリとツール これらのメカニズムは、アプリケーション バージョンを配布する場合に推奨され、ユーザーはこれを使用してアプリケーションをダウンロードしてインストールすることもできます。これらには、公式 Kubernetes プロジェクトによって開発された共通のライブラリ、ツール、システム、インターフェースが含まれており、リリースに使用できます。
これらのコンポーネントは以下に依存します。
2.5 エコシステム Kubernetes には明確な境界が定義されている領域が数多くあります。ただし、Kubernetes は、コンテナ化されたアプリケーションのデプロイと管理に必要な共通機能を提供する必要があります。しかし、原則として、Kubernetes は、機能が Kubernetes の一般的なオーケストレーション機能を補完する領域では、ユーザーの選択を維持します。特に、独自の競争上の優位性を持つ分野、特にさまざまなニーズや好みに対応できる多数のソリューション。 Kubernetes は、これらのソリューション用のプラグイン API を提供したり、複数のバックエンドによって実装される共通 API を公開したり、そのようなソリューションが対象とすることができる API を公開したりすることができます。明示的なインターフェースを必要とせずに、Kubernetes を使用して機能をきれいに構成できる場合があります。 さらに、Kubernetes の一部と見なされる場合、コンポーネントは Kubernetes の設計規則に従う必要があります。たとえば、プライマリ インターフェースが Kubenetes API アプローチと互換性のないドメイン固有言語 (Puppet、Open Policy Agent など) を使用するシステムは、Kubernetes で使用できますが、Kubernetes の一部とは見なされません。同様に、複数のプラットフォームをサポートするように設計されたソリューションは、Kubernetes API プロトコルに準拠していない可能性があるため、Kubernetes の一部とは見なされません。 内部コンテナ イメージ: Kubernetes はコンテナ イメージの内容を提供しません。コンテナ イメージにデプロイされるように設計されているものは、直接 Kubernetes の一部とは見なされません。たとえば、言語固有のフレームワークなどです。 Kubernetes上で 1. 永続的な統合とデプロイメント (CI/CD): Kubernetes では、ソース コードからイメージに移行する機能は提供されません。 Kubernetes はソースコードをデプロイせず、アプリケーションをビルドしません。ユーザーとプロジェクトは、独自のニーズに応じて永続的な統合と永続的なデプロイメントのワークフローを選択できます。 Kubernetes の目標は、CI/CD の動作を指示するのではなく、CI/CD の使用を容易にすることです。 2. アプリケーション ミドルウェア: Kubernetes は、メッセージ キューや SQL データベースなどの組み込みインフラストラクチャとしてアプリケーション ミドルウェアを提供しません。ただし、簡単にプロビジョニング、検出、アクセスできるようにする汎用メカニズムを提供することができます。理想的には、これらのコンポーネントは Kubernetes 上でのみ実行されます。 3. ログ記録と監視:ログ記録と監視のメカニズムは Kubernetes クラスターの重要な部分ですが、Kubernetes 自体はログの集約や包括的なアプリケーション監視機能を提供しておらず、テレメトリ分析やアラート システムもありません。 4. データ処理プラットフォーム:データ処理プラットフォームとしては、Spark と Hadoop がよく知られていますが、市場には他にも多くのシステムが存在します。 5. アプリケーション固有のオペレーター: Kubernetes は、一般的なカテゴリのアプリケーションのワークロード管理をサポートします。 6. サービスとしてのプラットフォーム (PaaS): Kubernetes は PaaS の基盤を提供します。 7. Function as a Service (FaaS): PaaS に似ていますが、Faa はコンテナーと言語固有のアプリケーション フレームワークに侵入します。 8. ワークロード オーケストレーション: 「ワークフロー」は非常に幅広く多様な分野であり、通常は特定のユース ケース シナリオ (データ フロー図、データ駆動型処理、デプロイメント パイプライン、イベント駆動型自動化、ビジネス プロセス実行、iPAAS など) と特定の入力およびイベント ソースのソリューションを対象としており、通常はコードを記述して実装する必要があります。 9. ドメイン固有言語を構成する:ドメイン固有言語は、高レベルの API やツールを階層化するのに適しておらず、通常、表現力、テスト可能性、親しみやすさ、ドキュメント化が制限されています。それらは構成の生成を複雑にし、相互運用性と構成可能性の間でトレードオフする傾向があります。それらは依存関係の管理を複雑にし、抽象化とカプセル化を破壊してしまうことがよくあります。 10. Kompose: Kompose は、Docker Compose から Kubernetes への移行を支援し、シンプルなユースケースを提供するアダプタ ツールです。 Kompose は Kubernetes の規則には従わず、手動で保守される DSL に基づいています。 11. ChatOps:チャット サービス用のアダプタ ツールでもあります。 Kubernetesのサポート 1. コンテナ ランタイム: Kubernetes 自体はコンテナ ランタイム環境を提供しませんが、選択したコンテナ ランタイムをプラグインするためのインターフェイスを提供します。 2. イメージリポジトリ: Kubernetes 自体はコンテナイメージを提供しません。 Harbor、Nexus、docker レジストリを通じてイメージ リポジトリを構築し、クラスターに必要なコンテナ イメージをプルできます。 3. クラスター状態ストレージ:クラスターの動作状態を保存するために使用されます。たとえば、デフォルトでは Etcd が使用されますが、他のストレージ システムも使用できます。 4. ネットワーク:コンテナ ランタイムと同様に、Kubernetes はさまざまなネットワーク プラグインにアクセスするためのコンテナ ネットワーク インターフェイス (CNI) を提供します。 5. ファイルストレージ:ローカルファイルシステムとネットワークストレージ 6. ノード管理: Kubernetes は、包括的なマシン構成、メンテナンス、管理、または自己修復システムを提供または採用していません。通常、異なるパブリック/プライベート クラウド、異なるオペレーティング システム、および可変および不変のインフラストラクチャ向けです。 7. クラウド プロバイダー: IaaS のプロビジョニングと管理。 8. クラスターの作成と管理:コミュニティでは、minikube、kubeadm、bootkube、kube-aws、kops、kargo、kubernetes-anywhere など、多くのツールが開発されています。ツールの多様性からわかるように、クラスターの展開と管理 (アップグレードなど) には万能のソリューションはありません。とはいえ、共通のビルディング ブロック (安全な Kubelet レジストリなど) とアプローチ (特にセルフホスティング) により、このようなツールに必要なカスタム オーケストレーションの量は削減されます。 その後、Kubernetes エコシステムを構築し、関連するソリューションを統合して、上記のニーズを満たすことを目指しています。 マトリックス管理 オプション、構成可能なデフォルト、拡張機能、プラグイン、アドオン、プロバイダー固有の機能、バージョン管理、機能の検出、依存関係の管理。 Kubernetes はオープンソースのツールボックスであるだけでなく、一般的なクラスターやサービスの運用環境でもあります。 Kubernetes では、ほとんどのユーザーとユースケースがアップストリーム バージョンを使用することが想定されているため、Kubernetes は再構築することなくさまざまなシナリオを処理できるほど拡張可能である必要があります。 拡張性のギャップがコードフォークの主な要因であり、上流のクラスターライフサイクル管理ソリューションのギャップが現在の Kubernetes ディストリビューションの主な要因であった一方で、オプション機能 (アルファ API、プロバイダー固有の API など)、構成可能性、プラグイン可能性、拡張性の存在により、このコンセプトは避けられないものとなっています。 ただし、ユーザーが Kubernetes 上でアプリケーションをデプロイおよび管理できるようにし、開発者が Kubernetes クラスター上に Kubernetes 拡張機能を構築できるようにするには、Kubernetes クラスターまたはディストリビューションについて想定できる必要があります。基本的な前提が満たされない場合は、利用可能な機能を発見し、使用するための機能要件 (依存関係) を表現する方法を見つける必要があります。 アドオンを含むクラスター コンポーネントは、コンポーネント登録 API を介して登録し、/componentstatuses を介して検出する必要があります。 組み込み API、集約 API、登録済みのサードパーティ リソースを、検出および OpenAPI (Savigj.JSON) エンドポイント経由で検出できるようにします。前述のように、LoadBalancer タイプのサービスのクラウド サービス プロバイダーは、ロード バランサー API が存在するかどうかを判断する必要があります。 StorageClass と同様に、拡張機能とそのオプションは FoeClass リソースを介して登録する必要があります。ただし、fooClassName は、パラメータの説明、型 (整数と文字列など)、検証の制約 (ranger または regexp など)、およびデフォルト値を使用して拡張 API から参照されます。これらの API は、動的ストレージ ボリュームのプロビジョニング (空でない storageclass.provisioner フィールドで示される) などの関連機能の存在を構成/公開し、担当するコントローラーを識別する必要があります。このような API は、少なくともスケジューラ クラス、イングレス コントローラ クラス、Flex ストレージ ボリューム クラス、コンピューティング リソース クラス (GPU、その他のアクセラレータなど) に追加する必要があります。 既存のネットワーク ストレージ ボリュームをフレックス ストレージ ボリュームに変換すると、この方法ではストレージ ボリューム ソースが上書きされます。将来的には、LoadBalancer サービスのように抽象化をすべての環境に実装する必要がない場合でも (つまり、API が最も一般的な機能に対応する必要がない場合でも)、API は汎用の抽象化のみを提供する必要があります。 NIY: 登録と発見のために以下のメカニズムを開発する必要があります。
NIY: 単一の API およびきめ細かい機能のアクティブ化/非アクティブ化は、次のメカニズムによって解決できます。
NIY: 複数のコンポーネント (HA クラスター内の同じコンポーネントのレプリカを含む) のアップグレードに依存するバージョン管理操作の問題は、次の方法で対処する必要があります。
これらの機能は、次のマイナー リリースではデフォルトで有効になります。
Kubernetes API サーバーは、サポートされていないリソース フィールドとクエリ パラメータを無視しますが、不明な API や未登録の API は無視しません (実装されていない API や非アクティブな API は無効になっていることに注意してください)。これにより、クラスターの複数のバージョン間で構成を再利用できるようになりますが、予期しない結果が生じることもよくあります。 Kubctl は、サーバーの Wagger/OpenAPI 仕様を使用したオプションの検証をサポートしています。このようなオプションの検証は、サーバー (NYY) によって提供される必要があります。さらに、ユーザーの利便性のために、共有リソース マニフェストでは、kubectl やその他のクライアントによって検証できる最小の Kubernetes バージョン要件を指定する必要があります。 サービス カタログ メカニズム (NIY) は、S3 互換のクラスター ストレージなどのアプリケーション レベルのサービスが存在することをアサートできる必要があります。 安全関連システムの階層化 Kubernetes クラスターを適切に保護し、安全に拡張できるようにするには、システムのコンポーネントによっていくつかの基本概念が定義され、合意される必要があります。 ***セキュリティの観点から見ると、Kubernetes は一連のリングであり、各レイヤーが後続のレイヤーに機能を提供するものと考えてください。
下位層が上位層に依存すると、セキュリティ モデルが崩壊し、システムが複雑になります。管理者は操作の簡素化のためにこれを行うことを選択できますが、これは意識的な選択でなければなりません。簡単な例としては、etcd が挙げられます。etcd にデータを書き込むことができるすべてのコンポーネントがクラスター全体に存在し、あらゆるアクター (信頼性の高いリソースを侵害できるユーザー) がほぼどこからでも段階的なアップグレードを実行できます。実際には一部がクラッシュする可能性があっても、上記のレイヤーをプロセスの各レイヤー (etcd->apiservers+controller->コア セキュリティ拡張->委任拡張->ユーザー ワークロード) ごとに異なるマシン セットに分割します。 上記のレイヤーが同心円を定義する場合、重複する円や独立した円が存在することも可能です。たとえば、管理者は、クラスター ワークロードはアクセスできるが、プラットフォームは暗黙的にアクセスできない代替のシークレット ストレージ ソリューションを選択できます。これらの円の交点はワークロードを実行するマシンである傾向があり、ノードには通常の機能に必要な権限以上の権限があってはなりません。 最後に、どのレイヤーでも拡張機能を介して新しい機能を追加する場合は、その動作の影響を伝えるためにベスト プラクティスに従う必要があります。 拡張機能を介してシステムに機能を追加すると、その目的は何ですか?
それらは3つの主要なカテゴリに分かれています。
管理者を簡単にだまして拡張中に新しいクラスターレベルのセキュリティルールをインストールできる場合、レイヤー化は壊れてシステムが脆弱です。 この記事の翻訳者は、Beijing Shenzhou Aerospace Software Technology Co.、LtdのプロダクトマネージャーであるJi Xiangyuanです。 |
<<: 一般的に、クラウド コンピューティングのコストの主なカテゴリは何ですか?
オンライン マーケティング モデルの人気が高まり、オンライン プロモーションには従来のマーケティング...
はじめに: Hostexcellence については、ほとんどの人が知らないでしょうし、無謀な中小企...
yourlasthost は、特別価格で 2 つの OpenVZ 仮想 VPS をリリースします。価...
ソン・ソンが描いた多くの人々、特にベテランネットユーザーは、1990年代初頭、中関村の街を歩いている...
セキュリティ問題に関する小さな提案でさえ、クラウド コンピューティング プロジェクトを台無しにし、ク...
1. 技術の理想化各データ収集方法には独自の技術的利点がありますが、ウェブサイト訪問者のすべての行動...
かつては、「難病や複雑な病気の治療を専門とする」医療ウェブサイトが多数、百度の関連検索ページの最初の...
エモーショナルマーケティングはマーケティング手法のひとつです。ユーザーの感情から心理を捉えるためには...
ここ数日、「月収2万のSEOになる方法 - 初心者編」、「月収2万のSEOになる方法 - どん底編」...
SEOの人気が高まるにつれて、オンラインマーケティングに従事するほぼすべての企業が優れたSEOを備え...
[要約] 内部関係者は最近、テンセントテクノロジーに、Qvodが著作権侵害の疑いで関係部門から巨額の...
Hostdoc は、米国ロサンゼルスに新しいデータセンターを追加することを発表しました。このマシン群...
私の分析では、Weibo はもはや誰もが思っているようなものではない。4 つの新しい側面から、Wei...
2016年を振り返ると、アリババグループの年間プラットフォーム取引量は3兆元を超えた。当時の電子商取...
今が最高の時だ。映画やテレビドラマのIPは、資本から賞賛され、人々に「愛され」、一時的に脚光を浴びて...