K8sの運用・保守の日常業務
- K8s を使用してプロジェクトをデプロイする利点
K8s を使用してプロジェクトをデプロイする利点は次のとおりです。
1. 高い拡張性: K8s はコンテナの拡張と縮小を自動的に管理できるため、プロジェクトが高トラフィックのプレッシャーに対処できるようになります。
2. 高可用性: K8s は、コンテナーの高可用性を自動的に確保し、コンテナーに障害が発生した場合にはコンテナーを自動的に再起動します。
3. リソース管理: K8s は、リソースの無駄を避けるためにコンテナ リソース (CPU やメモリなど) を自動的に管理できます。
4. 便利なメンテナンス: K8s はコンテナのバージョンと更新を簡単に管理できるため、プロジェクトのメンテナンスが簡単になります。
5. マイクロサービスのサポート: K8s はマイクロサービス アーキテクチャをサポートしており、大規模なアプリケーションを複数の独立したサービスに分割して、保守性と拡張性を向上させることができます。
2. Kubernetes アーキテクチャ
Kubernetes は主に次のコア コンポーネントで構成されています:
etcd: クラスター全体のステータスを保存します;
apiserver: リソース操作への唯一の入り口を提供し、認証、認可、アクセス制御、API 登録と検出などのメカニズムを提供します。 ;
コントローラーマネージャー: 障害検出、自動拡張、ローリングアップデートなど、クラスターのステータスを維持する責任を負います;
スケジューラー: リソースのスケジューリングを担当し、事前に決定されたスケジューリングポリシーに従って対応するマシンにポッドをスケジュールする責任があります;
kubelet: メンテナンスを担当しますコンテナのライフサイクルを担当し、同時にボリューム (CVI) とネットワーク (CNI) の管理も担当します。
コンテナ ランタイム: イメージ管理とポッドとコンテナの実際の操作 (CRI) を担当します。kube
-proxy :
コア コンポーネントといくつかの推奨されるアドオンに加えて、サービスのクラスター内でサービス検出と負荷分散を提供する責任を負います:
kube-dns: クラスター全体に DNS サービスを提供する責任を負います
イングレス コントローラー: 外部ネットワークの入り口を提供しますサービス
Heapster: リソース監視を提供します。
Dashboard: GUI を提供します
。 フェデレーション: クラスター フェデレーションにより、アベイラビリティ ゾーン全体にクラスターを提供します
。 Fluentd-elasticsearch: クラスター ログの収集、ストレージ、およびクエリを提供します。
- ワークロード
ポッドは、「保留中」ステージから始まる事前定義されたライフ サイクルに従います。メイン コンテナーの少なくとも 1 つが正常に開始すると、「実行中」ステージに入り、ポッド内のコンテナーが終了したかどうかに応じて「成功」または「失敗」ステージに入ります。失敗した状態。
ポッドの実行中、kubelet はコンテナを再起動して、いくつかの障害シナリオを処理できます。Pod 内で、Kubernetes はさまざまなコンテナのステータスを追跡し、Pod を再び正常な状態にするために必要なアクションを決定します。
Kubernetes API では、Pod には仕様部分と実際の状態部分が含まれます。Pod オブジェクトの状態には、一連の Pod 条件 (Conditions) が含まれます。アプリケーションで必要な場合は、カスタムの準備情報をアプリケーションに注入することもできます。
Pod はライフサイクル中に 1 回だけスケジュールされます。ポッドがノードにスケジュール (割り当て) されると、ポッドが停止または終了されるまで、そのノードで実行され続けます。
コンテナのステータス
Kubernetes は、ポッドの全体的なステージを追跡するのと同じように、ポッド内の各コンテナのステータスを追跡します。コンテナーのライフサイクル コールバックを使用して、コンテナーのライフサイクルの特定の時点でイベントをトリガーできます。
スケジューラーが Pod をノードにディスパッチすると、kubelet はコンテナー ランタイムを通じて Pod のコンテナーの作成を開始します。コンテナには、待機中、実行中、終了の 3 つの状態があります。
ポッド内のコンテナのステータスを確認するには、kubectl description pod <ポッド名> を使用できます。その出力には、ポッド内の各コンテナのステータスが含まれます。
各ステータスには特定の意味があります。
待機
中 コンテナが実行中または終了状態のいずれでもない場合、コンテナは待機中状態になります。待機状態のコンテナーは、コンテナー イメージ ウェアハウスからコンテナー イメージを取得したり、コンテナーにシークレット データを適用したりするなど、起動を完了するために必要な操作をまだ実行しています。kubectl を使用して待機状態を含むコンテナのポッドをクエリすると、コンテナが待機状態になっている理由を示す Reason フィールドも表示されます。
実行中
実行中ステータスは、コンテナが実行中であり、問題が発生していないことを示します。postStart コールバックが構成されている場合、コールバックはすでに実行され、完了しています。kubectl を使用して実行状態を含むコンテナのポッドをクエリすると、実行状態になったコンテナに関する情報も表示されます。
終了しました
終了状態のコンテナは実行を開始し、正常に終了したか、何らかの理由で失敗しました。kubectl を使用して、Terminated 状態を含むコンテナの Pod をクエリすると、コンテナがこの状態になった理由、終了コード、コンテナの実行中の開始時刻と終了時刻が表示されます。
コンテナーが preStop コールバックを使用して構成されている場合、コールバックはコンテナーが終了状態になる前に実行されます。
- ワークロードリソース
1.Namespace (名前空間)
Kubernetes システムにおけるもう 1 つの非常に重要な概念である名前空間は、マルチテナントのリソース分離を実装するために多くの場合に使用されます。ネームスペースは、クラスター内のリソース オブジェクトをさまざまなネームスペースに「割り当て」て、論理的にグループ化されたさまざまなプロジェクト、グループ、またはユーザー グループを形成します。これにより、さまざまなグループが個別に管理されながら、クラスター全体のリソースを共有して使用できるようになります。
2. ステートレス デプロイメントは
、Kubernetes v1.2 で導入された概念であり、導入の目的は、Pod オーケストレーションの問題をより適切に解決することです。この目的のために、Deployment はその目的を達成するために内部的にレプリカ セットを使用します。Deployment の役割と目的、その YAML 定義、またはその特定のコマンド ライン操作に関係なく、これを RC のアップグレードとみなすことができます。この 2 つの類似点は次のとおりです。 90％以上。
RC と比較した Deployment の最大のアップグレードの 1 つは、現在のポッドの「デプロイメント」の進行状況をいつでも把握できることです。実際、ノードの作成、スケジュール設定、バインド、およびポッドのターゲット ノードでの対応するコンテナの開始という完全なプロセスには一定の時間がかかるため、N 個のポッド コピーを開始するシステムの目標状態は、実際には継続的であることが予想されます。 「展開プロセス」は最終状態につながります。
Deployment の一般的な使用シナリオには次のようなものがあります。
Deployment オブジェクトを作成して対応するレプリカ セットを生成し、ポッド レプリカの作成プロセスを完了します。
デプロイメントのステータスをチェックして、デプロイメント・アクションが完了したかどうか (ポッドのコピー数が期待値に達したかどうか) を確認します。
デプロイメントを更新して、新しいポッドを作成します (イメージのアップグレードなど)。
現在のデプロイメントが不安定な場合は、以前のデプロイメント バージョンにロールバックします。
デプロイメントを一時停止して、複数の PodTemplateSpec 構成項目を一度に変更し、新しいリリースのためにデプロイメントを再開します。
高負荷を処理できるようにデプロイメントをスケールします。
リリースが成功したかどうかを示す指標として、デプロイメントのステータスを確認します。
不要になった古いバージョンの ReplicaSet をクリーンアップします。
再起動するたびにコンテナ名とIPが変わります
。
Kubernetes システムでは、Pod の管理オブジェクトである RC、Deployment、DaemonSet、および Job はすべてステートレス サービスです。しかし実際には、多くのサービス、特に MySQL クラスター、MongoDB クラスター、Kafka クラスター、Zookeeper クラスターなどの一部の複雑なミドルウェア クラスターはステートフルです。これらのアプリケーション クラスターには次の共通点があります。
各ノードには固定の ID ID があり、この ID を通じてクラスター内のメンバーは相互に検出し、通信できます。
クラスターのサイズは比較的固定されており、クラスターのサイズを自由に変更することはできません。
クラスター内の各ノードはステートフルであり、通常はデータを永続ストレージに保存します。
ディスクが破損すると、クラスタ内のノードが正常に動作できなくなり、クラスタの機能が低下します。
上記のステートフル クラスターを実装するために RC/Deployment を使用して Pod のコピー数を制御すると、Pod の名前はランダムに生成され、Pod の IP アドレスは実行中にのみ決定されるため、最初の点が満たされないことがわかります。ランタイムは変更される可能性があります。各ポッドの一意で一定の ID を事前に決定することはできません。他のノードで障害が発生したノードを回復できるようにするには、このクラスター内のポッドをある種の共有 ID に接続する必要があります。この問題を解決するために、Kubernetes はバージョン v1.4 から新しいリソース オブジェクト PetSet を導入し、バージョン v1.5 ではその名前を StatefulSet に変更しました。本質的に、StatefulSet は Deployment/ の特別なバリアントと見なすことができます。 RC. 以下のような特徴があります。
StatefulSet 内の各ポッドには、安定した一意のネットワーク識別子があり、クラスター内の他のメンバーを検出するために使用できます。StatefulSet の名前が kafka であると仮定すると、最初の Pod は kafak-0、2 番目の Pod は kafak-1 というようになります。
StatefulSet によって制御される Pod コピーの起動と停止の順序が制御され、n 番目の Pod を操作するとき、最初の n-1 個の Pod はすでに実行され、準備が整っています。
StatefulSet の Pod は、PV/PVC を通じて実装される安定した永続ストレージ ボリュームを使用します。Pod が削除されても、StatefulSet に関連するストレージ ボリュームは、デフォルトでは削除されません (データ セキュリティを確保するため)。
名前と IP は、再起動するたびに変更されません
。
典型的なアプリケーションには次のようなものがあります。
ログ収集 (fluentd、logstash など)
システム監視 (Prometheus Node Exporter、collectd、New Relic エージェント、Ganglia gmond など)
システム プログラム (kube-proxy、kube-dns、glusterd、ceph など)
5.サービス（サービス）
Service は、Kubernetes のコア リソース オブジェクトの 1 つでもあります。Kubernetes の各 Service は、実際には、よく言及されるマイクロサービス アーキテクチャにおける「マイクロサービス」です。先ほど述べた Pod や RC などのリソース オブジェクトは、実際には「ウェディング ドレス」ですこのセクションで言及されている「サービス」の場合は、「Kubernetes Service」を参照してください。次の図は、Pod、RC、Service 間の論理関係を示しています。
Kubernetes のサービスは、サービスのアクセス エントリ アドレスを定義します。フロントエンド アプリケーション (Pod) は、このエントリ アドレスを通じて、その背後にあるポッド コピーで構成されるクラスタ インスタンスのグループにアクセスします。サービスとそのバックエンド ポッド コピー クラスタ間の接続ラベルセレクターを介して「シームレスな接続」を実現します。RC の役割は、実際には、サービスのサービス機能とサービス品質が常に期待される基準に達していることを保証することです。
6.ボリューム（収納量）
ボリュームは、複数のコンテナからアクセスできるポッド内の共有ディレクトリです。Kubernetes のボリュームの概念、使用法、目的は Docker のボリュームと似ていますが、この 2 つは同等ではありません。まず、Kubernetes のボリュームはポッド上で定義され、ポッド内の複数のコンテナによって特定のファイル ディレクトリにマウントされます。次に、Kubernetes のボリューム内のデータは失われません。最後に、Kubernetes は、Gluster、Ceph、その他の高度な分散ファイル システムなど、複数のタイプのボリュームをサポートしています。
7.PV/PVC/StorageClass
Persistent Volume (PV) は、管理者によって構成されたクラスター内のネットワーク ストレージのセクションです。クラスター内のリソースは、クラスター リソースであるノードに似ています。PV はボリュームと同様のボリューム プラグインですが、PV を使用する個々のポッドから独立したライフサイクルを持ちます。この API オブジェクトは、ストレージ (NFS、iSCSI、またはクラウド プロバイダー固有のストレージ システムなど) の実装の詳細をキャプチャします。
PersistentVolumeClaim (PVC) は、ユーザーが保存したリクエストです。ポッドに似ています。ポッドはノード リソースを消費し、PVC は太陽光発電リソースを消費します。ポッドは特定のレベルのリソース (CPU とメモリ) を要求できます。資格は特定のサイズとアクセス モードを要求できます (たとえば、1 回の読み取り/書き込みまたは読み取り専用で何度もマウントできます)。
PersistentVolumeClaim を使用すると、ユーザーは抽象ストレージ リソースを使用できますが、ユーザーがさまざまな問題に応じてさまざまなプロパティ (パフォーマンスなど) を持つ Persistent Volume を必要とするのが一般的です。クラスター管理者は、ユーザーにこれらのボリュームの実装の詳細を意識させることなく、サイズとアクセス モードだけが Persistent Volume とは異なる複数の Persistent Volume を提供できる必要があります。これらのニーズに対応するために、StorageClass リソースが存在します。
StorageClass は、管理者が提供するストレージの「クラス」を記述する方法を提供します。さまざまなクラスがサービス品質レベル、バックアップ ポリシー、またはクラスター管理者によって決定されたポリシーにマップされる場合があります。Kubernetes 自体は、どのようなカテゴリが表現されるかについては自明です。この概念は、他のストレージ システムでは「構成ファイル」と呼ばれることもあります。
8. Secret Secret Dictionary
Secret は、パスワード、トークン、キーなどの機密データをイメージや Pod 仕様に公開することなく、機密データの構成の問題を解決します。シークレットはボリュームまたは環境変数として使用できます。
シークレットには 3 つのタイプがあります。
サービス アカウント: Kubernetes API へのアクセスに使用され、Kubernetes によって自動的に作成され、ポッドの /run/secrets/Kubernetes.io/serviceaccount ディレクトリに自動的にマウントされます; 不透明
: Base64 エンコード形式のシークレット、パスワードやキーなどの保存に使用されます。
Kubernetes.io/dockerconfigjson: プライベート Docker レジストリの認証情報を保存するために使用されます。
9.ConfigMap 構成アイテム
ConfigMap は、構成データのキーと値のペアを保存するために使用され、単一の属性または構成ファイルを保存するために使用できます。ConfigMap は Secret に非常に似ていますが、機密情報を含まない文字列をより簡単に処理できます。
10. CronJob スケジュールされたタスク
CronJob は、Linux システムの crontab に似たスケジュールされたタスクで、指定された期間に指定されたタスクを実行します。Kubernetes 1.5 では、CronJob を使用するには、batch/v2alpha1 API、つまり –runtime-config=batch/v2alpha1 を有効にする必要があります。.名前空間
11.イングレスルーティング
通常、サービスとポッドの IP にはクラスター内でのみアクセスできます。クラスターの外部からのリクエストは、ロード バランシングを通じてノード上のサービスによって公開される NodePort に転送され、その後 kube-proxy によって関連する Pod に転送される必要があります。
Ingress は、クラスターへの外部アクセス、ロード バランシング、SSL 終了、HTTP ルーティングなどのための URL を使用したサービスを提供できます。これらの Ingress ルールを構成するには、クラスター管理者は Ingress コントローラーを展開する必要があります。このコントローラーは、Ingress とサービスの変更を監視し、ロード バランシングを構成し、ルールに従ってアクセスを提供します。
- K8s の共通コマンド
次のクエリ コマンド -A はすべての名前空間を示し、-n の後に指定された名前空間が続きます。
kubectl get Nodes #クラスター内のすべてのノードを表示します。
kubectl get ns # すべての名前空間内のすべてのポッドをリストします
kubctl get pods –A # すべての名前空間内のポッドを表示します
kubectl get pods -n yxyw -o Wide # 名前空間内のすべてのポッドを表示し、ポッド IP、ノード名、 kubectl
getdeploy -o Wide -n yxyw # デプロイされたすべてのアプリケーションを表示すると、コンテナーだけでなく、コンテナーで使用されるイメージ、ラベル、その他の情報も表示されます。
kubectl get pods -n yxyw #名前空間内のすべてのポッドを表示します。
kubectl get Secret -n yxyw #yxyw 名前空間キーを表示
kubectl get configmap -n yxyw #yxyw 名前空間構成ファイルを表示
kubectl get pv -A #すべての名前空間を表示 pv
kubectl get pvc -A #すべての名前空間を表示 pvc
kubectl get svc -A #Viewすべての名前空間サービス
kubectl get ingress -A #すべてのイングレス ドメイン名を表示
kubectl top pods -n yxyx #名前空間内のすべてのポッドのメモリと CPU を表示
kubectl description pod osale-im -n yxyw #pod im 情報の表示
kubectl description ingress gyxtest.gemdale.com-ingress -n yxyw #ingress ドメイン名情報の表示
kubectl description configmap nginx-gyx-nginx-conf -n yxyw #設定ファイルの表示情報
kubectl get configmap nginx-gyx-nginx-conf -o yaml -n yxyw #出力設定ファイル起動テンプレート
kubectl get Secret gem-acr-p-a01-registry.cn-shenzhen.com-secret -o yaml -n yxyw #キーテンプレートの出力
kubectl get Secret -n devops #ダッシュボードのキー名の検索
kubectl get Secret cluster-admin-token-mbmgg -o yaml -n devops #クラスターキーの出力
コマンド ラインでダッシュボードのドメイン名とキーを検索します。
kubectl get ingress -A
kubectl get ingress -o yaml kubernetes-dashboard-test.gemdale.com-ingress -n devops #イングレス ドメイン名を表示します
kubectl get Secret -n devops #秘密キーを見つけます
kubectl get Secret admin-token-4t89n -o yaml -n devops
kubectlロールアウト再起動デプロイメント osale-im -n yxyw #ローリング再起動デプロイメント
kubectlロールアウト再起動デプロイメント $(kubectl getdeployment -n yxyw-uat | awk '{print $1}' | grep -v NAME) -n yxyw-uat # new ポッドが正常に起動したら、古いポッドを削除してスムーズに再起動します。
kubectl exec -it osale-im-8875fd54-gdhxn -n yxyw – bash #ポッドに入るコマンドライン
kubectl logs -f osale-im-8875fd54-gdhxn -n yxyw #リアルタイム
ログの表示 kubectl logs osale-im-8875fd54 -gdhxn -n yxyw #最新の出力ログを表示します
kubectl delete pods -n yxyw osale-im-8875fd54-gdhxn #ポッド コンポーネントを削除し、ポッド コンポーネントを再起動します
kubectl deletedeployment osale-im-8875fd54-gdhxn -n yxyw #削除後は再起動しません
kubectl cp osale-im-8875fd54-gdhxn:/gemdale/osale-im-0.0.1-SNAPSHOT.jar を直接強制的に削除します。 /osale-im-0.0.1-SNAPSHOT.jar -n yxyw #ポッド内のファイルをコピーします
kubectl delete deploy `kubectl get deploy -n yxyw-dev | awk '{print $1}' | grep dev` -n yxyw-dev #删除所有-dev的pod
kubectl delete service `kubectl get svc -n yxyw-dev | grep dev | awk '{print $1}'` -n yxyw-dev #删除所有-dev的service
- nginx サービスを迅速にデプロイします。
デプロイの例:
kubectl createdeployment nginx --image=nginx:1.11
kubectl 公開デプロイメント nginx --port=80 --type=NodePort
kubectl get svc -n default #View アクセス ポート
10.0.21.21:prot
kubectl delete svc nginx -n デフォルト
kubectl deletedeployment nginx -ndefault
6. マーケティング ビジネス マイクロサービス デプロイメント テンプレート分析
https://flow.aliyun.com/pipelines/2250688/current osale-im-k8s.test パイプライン
apiVersion: apps/v1
kind: Deployment
metadata:
name: @APP_NAME@
labels:
app: @APP_NAME@
spec:
replicas: @REPLICAS@
revisionHistoryLimit: 10
selector:
matchLabels:
app: @APP_NAME@
template:
metadata:
labels:
app: @APP_NAME@
armsPilotAutoEnable: "on"
armsPilotCreateAppName: @APP_NAME@
one-agent.jdk.version: "OpenJDK11"
spec:
imagePullSecrets:
- name: gem-acr-p-a01-registry1.cn-shenzhen.com-secret
containers:
- name: @APP_NAME@
image: ${IMAGE}
ports:
- containerPort: @targetPort@
protocol: TCP
imagePullPolicy: IfNotPresent
readinessProbe:
tcpSocket:
port: @targetPort@
initialDelaySeconds: 30
periodSeconds: 10
livenessProbe:
tcpSocket:
port: @targetPort@
initialDelaySeconds: 15
periodSeconds: 20
resources:
limits:
cpu: @LIMIT_CPU@
memory: @LIMIT_MEMORY@
requests:
cpu: @REQUEST_CPU@
memory: @REQUEST_MEMORY@
volumeMounts:
- name: logs
mountPath: /gemdale/logs
- name: data
mountPath: /gemdata/share/
volumes:
- name: logs
hostPath:
type: DirectoryOrCreate
path: /data/logs/test/@APP_NAME@
- name: data
hostPath:
type: DirectoryOrCreate
path: /gemdata/share/
###############################
---
apiVersion: v1
kind: Service
metadata:
name: @APP_NAME@
labels:
app: @APP_NAME@
spec:
ports:
- port: @port@
targetPort: @targetPort@
@NodePort@
selector:
app: @APP_NAME@
type: @PORT_TYPE@
kubectl getdeploy osale-im -o yaml -n yxyw
- マーケティング ビジネス ドメイン名 ビジネス プロセス
osaletest.gemdale.com
slb – ingress – osale-gateway
ACK メモリ可用性の最適化
sed -i 's/1764Mi/1024Mi/g' /etc/kubernetes/kubelet-customized-args.conf
systemctl restart kubelet
ps -ef |grep /usr/bin/kubelet |grep 1024