K8Sトレーニングキャンプ

1. Linux 名前空間と Docker

1.linux の 7 つ -------------- ipc,net,pid,mnt.uts.user

 

 Linux の ns を表示する

lsns

 さまざまなタイプの ns を表示する

[root@master ~]# lsns -t net
        NS TYPE NPROCS PID USER COMMAND
4026531956 net     116   1 root /usr/lib/systemd/systemd --system --deserialize 26

特定の ns の pid を表示して入力します

ls -la /proc/1/ns

コンテナーにはコマンドがありません。ホスト経由でコンテナーの nsenter -t pid を表示します。

ステップ 1.docker ps|grep nginx

ステップ 2 docker Inspection name | grep pid

ステップ 3: nsenter -t pid(pid 番号) -n ip a---------n ドロップしないでください。認識しない場合は、親友の ip a になります。

nsenter -t 1 -n ip a

 2. Docker 自体は cgroup ドライバーとして ****cgroupfs**** を使用しますこれはイントラネット内の cgroup システムのセットであり、kubelet の cgroup システムは *****systemd**** です

 保護するために、kubelet は起動時に cgroup ドライバーをチェックし、通常は docker を systemd に変更してからリロードします。

3、、docker の利点とcontainerd との違い

Docker の革新性は、共同ファイル システムにあります。最大の利点は、イメージのパッケージ化、イメージ自体の環境のレポート、移植性であることにあります ---------------- コンテキスト構築

docker と containerd の主な違いは、docker が crid に接続するための shim を追加することです。その理由は、docker のアップグレード前はプロセスが強制終了されますが、cridb は強制終了されないためです。そのため、docker は shim を介して crid に接続します。

 多段階ビルドイメージ

  

 

4. ネットワーク オーバーレイ (パッケージングのレイヤーの追加 -- 一般的に使用されます -- トンネル モード -- レイヤーの追加 -- パケットのアンパック) およびアンダーレイ (ポッド ノードのネットワークの再計画 -- 物理マシン ネットワーク -- ではありません)一般的に使用されます ---)

同じノードのポッドを接続する方法 

1. NULL モード - 自己構成 - 一般的には使用されません

2. デフォルト モード -- ブリッジと NAT -- ポッドが veth を形成 -- それぞれホスト (Docker ブリッジおよびコンテナ ネットワーク) とペアリングします。

docker run -d --name nginx01 -p 3344:80 nginx

bの端が露出する原理はiptableのルール書き換えである

iptables のルールを確認し、TCP プロトコルの場合はルールを追加します。ターゲット ポートは 3344 で DNAT (配布) を実行します。

[root@master ~]# iptables-save -t nat |grep 3344
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 3344 -j DNAT --to-destination 172.17.0.2:80

2. k8s スケジューリング戦略

Borg スケジューリング戦略: 最悪の適合 (アイドル状態のリソースが最も多い場所に配置し、すべてのノードのリソース占有率がほぼ同じ)

                        ベストフィット (リソースとコストを節約するのに十分な量を設定し、可能な限りノードを埋め、クラスターの断片化を減らすように努めます)

                        ハイブリッド (すべてのノードを走査するのではなく、局所的な最適値を見つけてそれを導入します)

1. k8s で DEBUG モードを開く方法:

 k get ns default -v 9

kubectl の本質は REST API、CURL コマンドのカプセル化です。

APIサーバーに行って取得するのではなく、キャッシュに行って取得してください

[root@master module4]# k get ns default -v 9
I1115 18:55:49.139247   12707 loader.go:375] Config loaded from file:  /root/.kube/config
I1115 18:55:49.148958   12707 round_trippers.go:424] curl -k -v -XGET  -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" -H "User-Agent: kubectl/v1.19.7 (linux/amd64) kubernetes/1dd5338" 'https://172.26.144.84:6443/api/v1/namespaces/default'

cat /root/.kube/config

 このとき、左右でnsアップデートを聞くことができます

 crid ランタイムを表示します。デフォルト値は k8s1.24 バージョンより前の docker です。

[root@master ~]# cat /var/lib/kubelet/config.yaml  |grep runtime
kubeReservedCgroup: /podruntime.slice
runtimeRequestTimeout: 2m0s

  3.ETCD

etcd は raft プロトコルに基づいた分散 kv データベースです

キーバリューストア

サービスの検出と登録

監視メカニズム - 非同期システム

Raft コンセンサス アルゴリズムRaftを理解します。リーダーがいない一定期間が経過すると、あなたが候補者になり、メッセージを送信すると反乱が成功し、私があなたのリーダーであると他の人に伝え続けます。

新しく追加されたノード学習者は学習のみを行い、投票はしません。

etcd は kv であるため、Zhiyong と多くのキーにインデックスを付けることができます

etcd とホストを組み合わせると、読み取り効率が非常に高くなります。独立したマウント ディスク SSD を追加します。すべて SSD にする必要があります。そうしないと分割されます。

etcdの復帰の修正バージョン番号は修正されるたびに全体が更新され、最新のバージョン番号のみが通過します。

ETcdのデータ確認も半分以上確認可能

 ETCD をバックアップすると、スナップショットがロックされるため、バックアップ時間を合理的に計画し、VAR/LOG を取り出し、最初にスナップショットを復元してから、VAR/LOG データをロードする必要があります。

  4. APIサーバー

api-server は API ゲートウェイと同等です

認証、認証、アクセス戦略、電流制限、

プラグインの前面は変更できますが、背面は変更できません

通常、Webhook は APIserver のサイドカーとして一緒に動作します。

 

5. docker から crd に切り替える

マスターの 101/docker2containerd.md · cncamp/101 · GitHub

開始シーケンス: CSI-->>CRI-->>CNI

6、ネットワークプラグイン

フランネル -------VXLAN モード、パケット アンパック、独自のリソース オーバーヘッドは約 10% ------- エコロジーなし

calico ------------ 同じネットワーク セグメント上のレイヤー 3、BGP プロトコル (相互通知)、パケットをアンパックする必要なし --------- クロスホスト ネットワーク セグメント tunl0 モード (トンネル --- IPIP ----IP パケットの後に IP パケットが続く --------vxlan と UDP パケット)

calico-----ダイナミックルーティングモード

七、ポッドステータス計算詳細

8、iptables ルールを表示する

出入りする人はすべてKUBE-SERVICESへ

-d は宛先 (宛先アドレス) を表します。

iptables-save -t nat

[root@master ~]# iptables-save -t nat |grep -i ser
:KUBE-SERVICES - [0:0]
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE
-A KUBE-SERVICES ! -s 172.20.0.0/16 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ
-A KUBE-SERVICES -m addrtype --dst-type LOCAL -j KUBE-NODE-PORT
-A KUBE-SERVICES -m set --match-set KUBE-CLUSTER-IP dst,dst -j ACCEPT

戦略としては、1本目、当たらなかったら2本目、当たらなかったら3本目です。

小さなクラスターは問題ありません

iptables リンクルールが多すぎると転送効率が非常に低くなり、最適化したとしても最初のパケットの効率も非常に低くなります。

iptables が完全にリフレッシュされました

ipvs はポストルーティングで SNAT を実行します

ipvs が有効な場合、ローカル マシンからではないデータ パケットが失われるのを防ぐために、ipvs0 の仮想ネットワーク カードがアクティブになります。

 prerouting と postrouting の代わりに、ipvs にはフック ポイントがなく、ポッピング (postrouting) のカモフラージュは引き続き iptables に依存するため、ipvs では iptables の nat ルールが少なくなります。

ipvsadm -L

ナイン、jks パイプライン