インターネット上には参考文献がたくさんありますが、最も単純なアドバイスが最も価値がある場合もあります。 チーム 翻訳された 、記事の著者が Kubernetes に XNUMX 年間取り組んだ後に収集したものです。 ヒントは重要度によって分類されていませんが、誰もが自分にとって役立つものを見つけられると思います。
Kubernetes を操作するための最も簡単なコマンド
まず、これはおそらく、Kubernetes を使用する上で最も単純で最も役立つアクションです。 次のコマンドはコマンド補完を有効にします kubectl bash シェルで:
echo "source <(kubectl completion bash)" >> ~/.bashrc
オートフィル kubectl .bashrc ファイルに書き込まれ、シェルが起動されるたびに自動的にアクティブ化されます。 これにより、次のような長いコマンドやパラメータの入力が高速化されます。 all-namespaces。 続きを読む .
名前空間のデフォルトのメモリと CPU の制限
たとえば、アプリケーションが間違って作成されている場合、データベースへの新しい接続を毎秒開くが閉じない場合、クラスターでメモリ リークが発生します。 また、アプリケーションの展開時にメモリ制限が設定されていない場合、ノード障害が発生する可能性があります。
これを防ぐために、Kubernetes では名前空間ごとにデフォルトの制限を設定できます。 これらは、特定の名前空間の yaml ファイルに書き込まれます。 そのようなファイルの例を次に示します。
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
このような yaml を作成し、任意の名前空間に適用します。 たとえば、名前空間に対して limit-example。 これで、このコンテナーに別の個別の制限が追加で設定されない限り、この名前空間にデプロイされたコンテナーには 512Mi の制限が設定されます。
Kubernetes の古いバージョンでのガベージ コレクション
Kubelet はデフォルトで次の場合にガベージ コレクションを開始します。 var/lib/docker 利用可能なディスク容量の 90% を占有します。 これは素晴らしいことですが、Kubernetes 1.7 までは、ファイル システム内のファイルの数に対応する、使用される i ノードの数にデフォルトの制限がありませんでした。
潜在的にあなたのコンテナ var/lib/docker ディスク領域の 50% しか使用しない可能性がありますが、inode が不足する可能性があり、ワーカーに問題が発生します。
kubelet の古いバージョン 1.4 から 1.6 では、次のフラグを追加する必要があります。
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
1.7 以降のバージョンでは、このフラグはデフォルトで設定されます。 ただし、以前のバージョンでは i ノード制限は監視されません。
Minikube...小さいながらも強力なローカル Kubernetes
Minikube は、ローカル Kubernetes クラスターを実行する最も簡単な方法です。 簡単なコマンドで起動します。
minikube start
このコマンドを実行すると、実際の Kubernetes クラスターがコンピューター上で実行されます。
重要なのは、アプリケーションを構築してそのクラスター上でローカルに実行する方法です。 特に指示がない限り、Docker イメージはクラスターではなくコンピューター上に構築されます。
Docker にイメージをローカル Kubernetes クラスターにプッシュさせるには、Docker マシンに次のコマンドを与えます。
eval $(minikube docker-env)
これで、ローカル Kubernetes クラスター上にアプリケーションを構築できるようになりました。
kubectl へのアクセス権を全員に与えないでください
これは明らかなことのように思えますが、複数のチームがアプリケーションに同じクラスターを使用している場合 (Kubernetes がそのために作成された目的です)、全員に同じクラスターを提供するべきではありません。 kubectl。 コマンドを分離し、それぞれに独自の名前空間を割り当て、RBAC ポリシーを使用してアクセスを制限することをお勧めします。
ポッドごとにアクセス、読み取り、作成、削除などの操作に対する権限を割り当てると混乱する可能性があります。 ただし、重要なことは、シークレットへのアクセスを制限し、管理者のみに許可することです。 このようにして、クラスターを管理できるユーザーと、単にクラスターにデプロイできるユーザーを区別します。
ポッドの予算を管理する
Kubernetes クラスター内のアプリケーションのダウンタイムを確実になくすにはどうすればよいですか? PodDisruptionBudget と再び PodDisruptionBudget です。
クラスターは定期的に更新され、ノードは空になります。 何も止まっていない、それが現実です。 複数のインスタンスを含むすべてのデプロイメントには PDB (PodDisruptionBudget) が含まれている必要があります。 これは、クラスターに適用される単純な yaml ファイルで作成されます。 特定の PDB のカバレッジ エリアは、ラベル セレクターによって決定されます。
注意： PDB 予算は、予算違反が回復可能な場合にのみ考慮されます (）。 ハードウェア障害などの状況では、PDB は機能しなくなります。
PDB の例:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
XNUMX つの主なパラメータは次のとおりです。 matchLabels и minAvailable。 最初のパラメータは、予算がどのアプリケーションに適用されるかを指定します。 たとえば、ラベルが付いたデプロイメントがある場合、 app: app-a и app: app-bの場合、この PDB は最初の PDB にのみ適用されます。
パラメーター minAvailable ノードを空にする (クリーニングする) ときに考慮されます。 たとえば、この例では、空にするときにすべてのインスタンスが削除されます。 app: app-a、XNUMXつを除いて。
これにより、特定の時点で実行するアプリケーションのインスタンスの数を制御できます。
アプリケーションの健全性の監視
このような監視は、Readiness テストまたは Liveness テストを使用する XNUMX つの方法で可能です。
最初のプローブ (準備状況) は、コンテナーがトラフィックを受信する準備ができているかどうかを判断します。
XNUMX 番目 (liveness) は、コンテナーが正常であるか、または再起動する必要があるかを示します。
関連する設定は、デプロイメント用の yaml に単純に追加されます。 そこではタイムアウト、遅延時間、再試行回数を指定できます。 詳細についてはこちらをご覧ください .
タグはいたるところにあります
ラベルは、Kubernetes の基本概念の XNUMX つです。 これにより、オブジェクトが相互に自由に通信したり、ラベルに基づいてクエリを作成したりできるようになります。 Kubernetes では、クライアントにアクセスして、特定のタグのイベントを監視することもできます。
タグを使用するとほとんど何でもできますが、同じクラスター上でプログラムを実行する複数の環境を作成することが好例です。
同じクラスターを次の目的で使用するとします。 dev и qa。 これは、アプリケーションを作成できることを意味します app-a、両方の環境で同時に動作します qa и dev。 この場合、適切なパラメータを指定することで、特定の環境のアプリケーション インスタンスに個別にアクセスできます。 environment。 例えば、 app: app-a и environment: dev XNUMX つの環境について、そして app: app-a и environment: qa XNUMX番目に。
これにより、アプリケーションの両方のインスタンスにアクセスして、たとえばテストを同時に実行できるようになります。
組織する
Kubernetes は非常に強力なシステムですが、どのシステムでも最終的にはプロセスが多すぎると行き詰まる可能性があります。 Kubelet は、独自のプロセスだけでなく、指定したすべてのプロセスとチェックを実行します。
もちろん、XNUMX つの孤立したサービスによってシステムの速度が低下することはありません。また、Kubernetes は根本からスケールするように設計されています。 しかし、XNUMX つのサービスではなく XNUMX 万ものサービスが出現すると、kubelet は窒息し始めます。
何らかの理由でデプロイメント (コンテナー、イメージなど) を削除した場合は、必ず完全なクリーンアップを実行してください。
ミートゴー
主なアドバイスは最後に取っておきました。 Go プログラミング言語を学びましょう。
Kubernetes は Go で開発され、すべての拡張機能は Go で記述され、client-go クライアント ライブラリも正式にサポートされています。
さまざまな興味深いことに使用できます。 たとえば、Kubernetes システムを好みに合わせて拡張します。 したがって、独自のプログラムを使用して、データの収集、アプリケーションのデプロイ、または単にコンテナーのクリーンアップを行うことができます。
Go プログラミング言語を学習し、client-go をマスターすることは、おそらく新しい Kubernetes ユーザーに与えることができる最も重要なアドバイスです。
他に何を読むべきか:
- .
- ?
- .
出所： habr.com