K8Sの高度な機能を理解するための記事

K8Sの高度な機能を理解するための記事

K8Sの高度な機能

K8S には、アプリケーションの弾力的なスケーリング (上記参照)、ローリング アップデート (上記参照)、構成管理、ストレージ ボリューム、ゲートウェイ ルーティングなど、理解する価値のある高度な機能がいくつかあります。

これらの高度な機能を理解する前に、K8S のいくつかのコア概念を確認する必要があります。

レプリカセット

ReplicaSet は、指定された数の Pod レプリカが常に実行されることを保証します。通常、指定された数の同一ポッドの可用性を確保するために使用されます。 ReplicaSet を直接使用するのではなく、Deployment を使用して管理することをお勧めします。

構成マップ

ConfigMap は、機密性のないデータをキーと値のペアに保存するために使用される API オブジェクトです。使用すると、Pod はこれを環境変数、コマンドライン パラメーター、またはストレージ ボリューム内の構成ファイルとして使用できます。 ConfigMap を使用して、構成データをアプリケーション コードから分離します。

音量

ボリュームとは、ポッド内のコンテナがアクセスできるデータ ディレクトリが含まれるストレージ ボリュームを指します。コンテナ内のファイルは一時的にディスクに保存されます。コンテナがクラッシュすると、ファイルは失われます。また、複数の Pod 間でファイルを共有することはできません。この 2 つの問題は、ストレージ ボリュームを使用することで解決できます。
一般的に使用されるストレージ ボリュームは次のとおりです。

  • configMap: configMap ボリュームは、構成データを Pod に挿入する方法を提供します。 ConfigMap オブジェクトに保存されたデータは、configMap タイプのボリュームによって参照され、Pod で実行されているコンテナ化されたアプリケーションによって使用されます。
  • emptyDir: emptyDir ボリュームはキャッシュ データを保存するために使用できます。 Pod がノードにディスパッチされると、emptyDir ボリュームが作成され、Pod がノード上で実行されている間はボリュームが存在します。 Pod がノードから削除されると、emptyDir ボリューム内のデータも完全に削除されます。
  • hostPath: hostPath ボリュームは、ホスト ノード ファイル システム上のファイルまたはディレクトリを Pod にマウントできます。 Minikube のホストは、Minikube が配置されている仮想マシンを指します。
  • ローカル: ローカル ボリュームは、ディスク、パーティション、ディレクトリなどのマウントされたローカル デバイスを表します。ローカル ボリュームは静的に作成された永続ボリュームとしてのみ使用でき、動的構成はまだサポートされていません。
  • nfs: nfs ボリュームは NFS (ネットワーク ファイル システム) を Pod にマウントできます。
  • persistentVolumeClaim: persistentVolumeClaim ボリュームは、永続ボリューム (PersistentVolume) を Pod にマウントするために使用されます。永続ボリューム (PV) は、管理者が事前にプロビジョニングしたり、ストレージ クラスを使用して動的にプロビジョニングしたりできるクラスター内のストレージの一部です。永続ボリュームは、ノードに似たクラスター リソースです。

イングレス

Ingress は、K8S の Ingress リソースを通じて Nginx と同様のドメイン名ベースのアクセスを実装し、Pod への負荷分散アクセスを実現できます。

Ingress をインストールする

https://github.com/kubernetes/ingress-nginx/blob/nginx-0.20.0/deploy/mandatory.yaml のページに移動し、内容をコピーして、k8s マスター マシン上のファイル ingress-controller.yaml に保存します。その中のイメージ アドレスを変更する必要があります。次の yaml コンテンツを直接使用できます。

ダウンロードアドレス（ポイント不要）: ダウンロードアドレス

APIバージョン: v1
種類: 名前空間
メタデータ:
  名前: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

種類: ConfigMap
APIバージョン: v1
メタデータ:
  名前: nginx-configuration
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

種類: ConfigMap
APIバージョン: v1
メタデータ:
  名前: tcp-services
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

種類: ConfigMap
APIバージョン: v1
メタデータ:
  名前: udp-services
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

APIバージョン: v1
種類: サービスアカウント
メタデータ:
  名前: nginx-ingress-serviceaccount
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: ClusterRole
メタデータ:
  名前: nginx-ingress-clusterrole
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ルール:
  -apiグループ:
      - 「」
    リソース：
      - 構成マップ
      - エンドポイント
      - ノード
      - ポッド
      - 秘密
    動詞:
      - リスト
      - 時計
  -apiグループ:
      - 「」
    リソース：
      - ノード
    動詞:
      - 得る
  -apiグループ:
      - 「」
    リソース：
      - サービス
    動詞:
      - 得る
      - リスト
      - 時計
  -apiグループ:
      - 「拡張機能」
    リソース：
      - 入口
    動詞:
      - 得る
      - リスト
      - 時計
  -apiグループ:
      - 「」
    リソース：
      - イベント
    動詞:
      - 作成する
      -パッチ
  -apiグループ:
      - 「拡張機能」
    リソース：
      - 入力/ステータス
    動詞:
      - アップデート

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: 役割
メタデータ:
  名前: nginx-ingress-role
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ルール:
  -apiグループ:
      - 「」
    リソース：
      - 構成マップ
      - ポッド
      - 秘密
      - 名前空間
    動詞:
      - 得る
  -apiグループ:
      - ""
    リソース：
      - 構成マップ
    リソース名:
      # デフォルトは「<election-id>-<ingress-class>」
      # ここでは: "<ingress-controller-leader>-<nginx>"
      # いずれかのパラメータを変更する場合はこれを調整する必要があります
      # nginx-ingress-controller を起動するとき。
      - 「イングレス コントローラー リーダー nginx」
    動詞:
      - 得る
      - アップデート
  -apiグループ:
      - 「」
    リソース：
      - 構成マップ
    動詞:
      - 作成する
  -apiグループ:
      - 「」
    リソース：
      - エンドポイント
    動詞:
      - 得る

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: RoleBinding
メタデータ:
  名前: nginx-ingress-role-nisa-binding
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ロールリファレンス:
  apiグループ: rbac.authorization.k8s.io
  種類: 役割
  名前: nginx-ingress-role
科目:
  - 種類: サービスアカウント
    名前: nginx-ingress-serviceaccount
    名前空間: ingress-nginx

---

APIバージョン: rbac.authorization.k8s.io/v1beta1
種類: ClusterRoleBinding
メタデータ:
  名前: nginx-ingress-clusterrole-nisa-binding
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
ロールリファレンス:
  apiグループ: rbac.authorization.k8s.io
  種類: ClusterRole
  名前: nginx-ingress-clusterrole
科目:
  - 種類: サービスアカウント
    名前: nginx-ingress-serviceaccount
    名前空間: ingress-nginx

---

APIバージョン: アプリ/v1
種類: DaemonSet
メタデータ:
  名前: nginx-ingress-controller
  名前空間: ingress-nginx
  ラベル:
    app.kubernetes.io/名前: ingress-nginx
    app.kubernetes.io/一部: ingress-nginx
仕様:
  セレクタ：
    一致ラベル:
      app.kubernetes.io/名前: ingress-nginx
      app.kubernetes.io/一部: ingress-nginx
  テンプレート：
    メタデータ:
      ラベル:
        app.kubernetes.io/名前: ingress-nginx
        app.kubernetes.io/一部: ingress-nginx
      注釈:
        prometheus.io/ポート: "10254"
        prometheus.io/scrape: "true"
    仕様:
      ホストネットワーク: true
      サービスアカウント名: nginx-ingress-serviceaccount
      コンテナ:
        - 名前: nginx-ingress-controller
          イメージ: siriuszg/nginx-ingress-controller:0.20.0
          引数:
            - /nginx-イングレスコントローラー
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          セキュリティコンテキスト:
            権限昇格を許可: true
            機能:
              落とす：
                - 全て
              追加：
                -NET_BIND_SERVICE
            # wwwデータ -> 33
            実行ユーザー: 33
          環境:
            - 名前: POD_NAME
              値:
                フィールド参照:
                  フィールドパス: metadata.name
            - 名前: POD_NAMESPACE
              値:
                フィールド参照:
                  フィールドパス: metadata.namespace
          ポート:
            - 名前: http
              コンテナポート: 80
            - 名前: https
              コンテナポート: 443
          ライブネスプローブ:
            失敗しきい値: 3
            httpGet:
              パス: /healthz
              ポート: 10254
              スキーム: HTTP
            初期遅延秒数: 10
            期間秒数: 10
            成功しきい値: 1
            タイムアウト秒数: 1
          準備プローブ:
            失敗しきい値: 3
            httpGet:
              パス: /healthz
              ポート: 10254
              スキーム: HTTP
            期間秒数: 10
            成功しきい値: 1
            タイムアウト秒数: 1

---

APIバージョン: v1
種類: サービス
メタデータ:
  名前: ingress-nginx
  名前空間: ingress-nginx
仕様:
  ポート:
    - 名前: http
      ポート: 80
      ターゲットポート: 80
      プロトコル: TCP
    - 名前: https
      ポート: 443
      ターゲットポート: 443
      プロトコル: TCP
  セレクタ：
    app.kubernetes.io/名前: デフォルトのhttp-backend
    app.kubernetes.io/一部: ingress-nginx

---

インストールが成功したか確認する

kubectl get pods -n ingress-nginx -o ワイド

Ingress アクセス ルールを構成して (nginx プロキシ転送構成を構成するのと同様)、Ingress がドメイン名 tomcat.core.com をバックエンドの tomcat-service-yaml サービスに転送できるようにします。次の内容を含む新しいファイル ingress-tomcat.yaml を作成します。

APIバージョン: networking.k8s.io/v1beta1
種類: イングレス
メタデータ:
 名前: web-ingress
仕様:
 ルール:
 - ホスト: tomcat.core.com # 転送ドメイン名 http:
    パス:
    - パス：​​ /
      バックエンド: 
       サービス名: tomcat-service-yaml
       servicePort: 80 # サービスポート

有効なイングレス ルールを表示します。

kubectl 取得

アクセス マシン上のホストを構成し、マスター ディレクトリ: /etc/hosts で、ホストに次のホストを追加します (Ingress によってデプロイされたマシン IP は、アクセスするドメイン名に対応します)

192.168.159.131 コア
または 192.168.159.132 tomcat.core.com

設定後、クライアント ブラウザーで http://tomcat.core.com/ に直接アクセスして、通常どおり Tomcat にアクセスします。

高度な機能

構成管理

ConfigMap を使用すると、構成ファイルをイメージ ファイルから分離して、コンテナー化されたアプリケーションを移植可能にすることができます。次に、ConfigMap のプロパティを Pod の環境変数に挿入する方法を示します。

ConfigMap を作成するには、設定ファイル nginx-config.yaml を追加します。ConfigMap の名前は nginx-config で、ストレージ情報はデータ ノードの下に配置されます。

APIバージョン: v1
種類: ConfigMap
メタデータ: 
 名前: nginx-config
 名前空間: デフォルト
データ：
 nginx-env:テスト

nginx-config.yaml ファイルを適用して ConfigMap を作成します。

kubectl 作成 -f nginx-config.yaml

すべてのConfigMapを取得します。

kubectl 設定マップを取得する

ConfigMap の内容を yaml 形式で表示します。

kubectl get configmaps nginx-config -o yaml

構成ファイル nginx-deployment.yaml を追加して、デプロイメントを作成し、nginx サービスをデプロイし、Nginx 環境変数の ConfigMap 内のプロパティを参照します。

APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ: 
 名前: nginx-deployment
 ラベル:
  アプリ: nginx
仕様:
 レプリカ: 1
 セレクタ：
  一致ラベル:
   アプリ: nginx
 テンプレート：
  メタデータ:
   ラベル:
    アプリ: nginx
  仕様:
   コンテナ:
    - 名前: nginx
      イメージ: nginx:1.10
      ポート:
       - コンテナポート: 80
      環境:
       - name: NGINX_ENV # Nginx で環境変数を設定します valueFrom:
          configMapKeyRef:
           name: nginx-config # ConfigMapの名前を設定します key: nginx-env # 取得するキー

構成ファイルを適用してデプロイメントを作成します。

kubectl を適用 -f nginx-deployment.yaml

作成が成功したら、Pod 内の環境変数を確認し、NGINX_ENV 変数が挿入されていることを確認します。

kubectl get pod -o ワイド


kubectl exec -it nginx-deployment-5ff74658b6-rlft8 --sh
# コンテナコンソールに入り、次のコマンドを実行します ECHO $NGINX_ENV

ストレージボリュームの使用状況

ストレージ ボリュームを使用すると、外部データをコンテナーにマウントして、コンテナー内のアプリケーションからアクセスできるようにすることができます。これにより、コンテナーがクラッシュしても、データは存在し続けることができます。

以前、Docker を使用して Nginx をデプロイしたときに、Nginx の html、logs、conf ディレクトリを外部からコンテナーにマウントしたことを思い出してください。

docker run -p 80:80 --name nginx \
-v /mydata/nginx/html:/usr/share/nginx/html \
-v /mydata/nginx/logs:/var/log/nginx \
-v /mydata/nginx/conf:/etc/nginx \
-d nginx:1.10

Minikubeは仮想マシンとみなすことができます。Minikubeのsshコマンドを使用してアクセスできます。

ミニキューブSSH

Minikube にはデフォルトで docker ユーザーが存在します。まずはそのパスワードをリセットしましょう。

sudo パスワード docker

Minikubeにmydataディレクトリを作成する

mkdir /home/docker/mydata

ディレクトリをマウントするには、nginx ディレクトリを Minikube にコピーする必要があります。docker ユーザーは /home/docker ディレクトリ内のファイルのみを変更できることに注意してください。scp コマンドを使用してファイルをコピーします。

scp -r /home/macro/mydata/nginx [email protected]:/home/docker/mydata/nginx

デプロイメントを作成するには、設定ファイル nginx-volume-deployment.yaml を追加します。

APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ: 
 名前: nginx-ボリュームデプロイメント
 ラベル:
  アプリ: nginx
仕様:
 レプリカ: 1
 セレクタ：
  一致ラベル:
   アプリ: nginx
 テンプレート：
  メタデータ:
   ラベル:
    アプリ: nginx
  仕様:
   コンテナ:
    - 名前: nginx
      イメージ: nginx:1.10
      ポート:
       - コンテナポート: 80
      ボリュームマウント:
       - マウントパス: /usr/share/nginx/html
         名前: html-ボリューム
       -マウントパス: /var/logs/nginx
         名前: ログボリューム
       - マウントパス: /etc/nginx
         名前: conf-volume
   ボリューム:
    - 名前: html-ボリューム
      ホストパス:
       パス: /home/docker/mydata/nginx/html
       タイプ: ディレクトリ
    - 名前: ログボリューム
      ホストパス:
       パス: /home/docker/mydata/nginx/logs
       タイプ: ディレクトリ
    - 名前: conf-volume
      ホストパス:
       パス: /home/docker/mydata/nginx/conf
       タイプ: ディレクトリ

構成ファイルを適用してデプロイメントを作成する

kubectl を適用 -f nginx-ボリューム-デプロイメント.yaml

サービスを作成するために設定ファイルnginx-service.yamlを追加します。

APIバージョン: v1
種類: サービス
メタデータ: 
 名前: nginx-service
仕様:
 タイプ: NodePort
 セレクタ：
  アプリ: nginx
 ポート:
 - 名前: http
    プロトコル: TCP
    ポート: 80
    ターゲットポート: 80
    ノードポート: 30080

サービスアクセスポートを確認する

kubectl サービスを取得する

CURL コマンドを使用して Nginx ホームページ情報にアクセスします。

要約する

サービスはK8Sサービスの核であり、サービスの詳細をシールドし、サービスインターフェースを統一的に外部に公開することで、真の「マイクロサービス」を実現します。たとえば、サービス A には 3 つのバックアップ、つまり 3 つの Pod がデプロイされています。ユーザーは、1 つのサービスの入り口に注意するだけでよく、どの Pod を要求するかを心配する必要はありません。利点は非常に明白です。一方では、外部ユーザーは、Pod 上のサービスの予期しないクラッシュや K8S による Pod の再プルによって引き起こされる IP 変更を意識する必要がありません。また、外部ユーザーは、サービスのアップグレードや変更による Pod の置き換えによって引き起こされる IP 変更を意識する必要もありません。他方では、サービスはトラフィックの負荷分散も実行できます。

ただし、サービスは主に K8S クラスター内のネットワーク トポロジを担当します。では、クラスターの外部からクラスターの内部にアクセスするにはどうすればよいでしょうか?このとき、Ingress が必要になります。公式ドキュメントでの説明は次のとおりです。

Ingress は、クラスター内のサービスへの外部アクセスを管理する API オブジェクトです。一般的なアクセス方法は HTTP です。

ngress は、負荷分散、SSL 終了、名前ベースの仮想ホスティングを提供できます。

翻訳: Ingress は、K8S クラスター全体、複雑なクラスターの内部および外部通信のアクセス レイヤーです。

Ingress と Service のネットワーク トポロジ図は次のとおりです。

kubectl サービスの問題のトラブルシューティング

K8S でのサービス展開の失敗をトラブルシューティングするにはどうすればよいですか?

次のコマンドを使用します:

kubectl は ${リソース} ${名前} を記述します。

最後までスクロールして「イベント」セクションを確認します。このセクションには、このサービスのデプロイ プロセスにおける K8S の主要なログが表示されます。

一般的に、デプロイメントの失敗のほとんどは、kubectl describe pod ${POD_NAME} を通じて見つけることができます。もちろん、特定の問題には特定の分析が必要です。

K8S にデプロイされた異常なサービスをトラブルシューティングするにはどうすればよいですか?

サービスが正常にデプロイされ、ステータスが実行中の場合は、Pod 内のコンテナにアクセスしてサービス ログを表示する必要があります。

Pod 内のコンテナによって出力されたログを表示します。

kubectl log ${POD_NAME} -c ${CONTAINER_NAME} を実行します。

Pod 内にコンテナを入力します。

kubectl exec ‐it [オプション] ${POD_NAME} ‐c ${CONTAINER_NAME} [引数]

このコマンドの目的は、kubectl を介して docker exec xxx を実行し、コンテナ インスタンスに入ることです。その後、ユーザーは自分のサービスのログをチェックして問題を特定します。

K8S は本当に Docker を放棄したのでしょうか?

Docker は非常に人気のあるコンテナ技術です。K8S によって廃止され、別のコンテナ技術である containerd に置き換えられたという記事が数多くあります。実際、containerd は Docker から分離された基盤となるコンテナ ランタイムにすぎません。使い方は Docker と変わりません。Docker から containerd への移行は非常に簡単で、基本的に制限はありません。 基本的には、先ほどの Docker コマンドの docker を crictl に変更するだけで完了です。どちらも同じ会社が開発しており、使い方も同じです。したがって、K8S が Docker を放棄するかどうかに関係なく、開発者には基本的に影響はありません。

K8S クリ

K8S は、コンテナ ランタイム インターフェースを統一した CRI (Container Runtime Interface) をリリースしました。CRI をサポートするコンテナ ランタイムはすべて、K8S の基盤となるコンテナ ランタイムとして使用できます。

K8S がコンテナランタイムとして Docker を放棄し、containerd を使用するのはなぜですか?

K8S コンテナ ランタイムとして Docker を使用する場合、kubelet は最初に dockershim を介して Docker を呼び出し、次に Docker を介して containerd を呼び出す必要があります。

K8S コンテナ ランタイムとして containerd を使用する場合、containerd には CRI プラグインが組み込まれているため、kubelet は containerd を直接呼び出すことができます。
containerd を使用すると、パフォーマンスが向上するだけでなく (呼び出しチェーンが短くなる)、リソースの使用量も削減されます (Docker は純粋なコンテナ ランタイムではなく、他にも多くの機能があります)。

もちろん、将来的には、Docker は K8S の基盤となる使用法と互換性を持たせるために、K8S CRI インターフェースを直接実装する可能性があります。

K8S の高度な機能に関するこの記事はこれで終わりです。K8S の高度な機能に関するより関連性の高いコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません:
  • Javaプロジェクトのk8sデプロイメントの実装
  • golang grpc 負荷分散方法
  • Java Grpcインスタンスでの負荷分散の作成の詳細な説明
  • Kubernetes (K8S) コンテナ クラスタ管理環境の完全な展開の詳細チュートリアル - パート 1
  • grpc-java k8sでの負荷分散処理方法

<<:  CSS で要素を垂直方向に中央揃えする 7 つの方法

>>:  テーブルを使用する場合と CSS を使用する場合 (経験の共有)

推薦する

Dockerはコンテナに入るためにnsenterツールを使用する

Dockerコンテナを使用する場合は、nsenterツールを使用する方が便利です。システムにない場合...

MySQL で絵文字表現を挿入できない理由と解決策

失敗のシナリオMySQL データベースに絵文字表現を挿入するために JDBC を呼び出すと、例外ja...

MySQL データベース インデックスが B+ ツリーの使用を選択するのはなぜですか?

MySQL データベース インデックスが B+ ツリーを使用する理由をさらに分析する前に、データ構...

Docker で Docker0 ブリッジのデフォルトのネットワーク セグメントを変更する方法

1. 背景Docker サービスが開始されると、デフォルトで docker0 ブリッジが作成され (...

JS が WeChat の「クソ爆弾」機能を実装

みなさんこんにちは、Qiufengです。最近、WeChatは新しい機能をリリースしました（WeCha...

IE をフリーズさせる HTML コード

任意のテキスト エディターを開き、次のコードをコピーして、たとえば SomeFilename.htm...

js でオブジェクトを作成するさまざまな方法とその長所と短所のまとめ

目次初期作成方法ファクトリーパターンコンストラクターパターンコンストラクタパターンの最適化プロトタイ...

node.js で PC 上の WeChat アプレット パッケージを復号化するための処理アイデア

目次アプレットのソースコードはどこにありますか? PC ミニプログラムはどのように暗号化されますか?...

ユーザーのニーズがマーケティング指向のデザインにつながる

<br />それぞれのトピックについて、チーム内でメールで議論します。議論が白熱するにつ...

Ubuntu 20.04 CUDA & cuDNN のインストール方法 (グラフィカル チュートリアル)

CUDA インストール cuda をダウンロードサポートされているcudaバージョンを表示するには...

Linux で time(NULL) 関数と localtime() を使用して現在の時刻を取得する方法

time(); 関数関数プロトタイプ: time_t time(time_t *timer)関数の目...

dockerコンテナにviコマンドをインストールする簡単な操作

docker コンテナを使用する場合、vim がインストールされていないことがあり、vim コマンド...

Vue の el-table は自動天井効果を実現します (固定をサポート)

目次序文実装のアイデア効果：使用：メインソースコード:序文多くのケースを見た結果、単純な観点からは、...

CSS の両端揃えを実現する div+css レイアウトの 4 つの方法の概要

2 端揃えを実現する div+css レイアウトは、Web ページの組版でよく使用されます。この記事...

Docker ロード後にイメージ名が none になる問題の解決方法

最近、docker load -i コマンドを使用してイメージ パッケージを圧縮した後、イメージ名と...