個人ホームページ:バグの克服 - CSDN ブログ
kubernetes コラム: kubernetes_Conquering バグ ブログ - CSDN ブログ
目次
-
クラスタコンポーネント
-
核となるアイデア
-
クラスターのインストール
1 クラスターコンポーネント
-
クラスタ クラスタ: 同じソフトウェア サービスの複数のノードをまとめて組織し、システムにサービスを提供するプロセスは、ソフトウェアのクラスタと呼ばれます。Redis クラスター、es クラスター、mongo など
-
k8s クラスター: 複数ノード: 3 ノードの役割: 1. マスター ノード/コントロール プレーン コントロール ノード 2. ワーク ノード: ワーキング ノード (ポッド コンテナ: アプリケーション コンテナ)
Kubernetes がデプロイされると、完全なクラスターが完成します。ノードと呼ばれるワーカー マシンのグループは、コンテナ化されたアプリケーションを実行します。每个集群至少有一个工作节点。ワーカー ノードは托管 Pod、ポッドはアプリケーションのロードとして機能するコンポーネントです。控制平面管理集群中的工作节点和 Pod。
1.1 コントロールプレーンのコンポーネント
コントロール プレーン コンポーネントは、クラスターに対してグローバルな決定を行います资源的调度。 以及检测和响应集群事件，例如当不满足部署的 replicas 字段时， 要启动新的 pod。
コントロール プレーン コンポーネントは、クラスター内のどのノードでも実行できます。ただし、簡単にするために、セットアップ スクリプトは通常、同じマシン上ですべてのコントロール プレーン コンポーネントを開始し、このマシン上でユーザー コンテナーを実行しません。
-
APIサーバーへ
API サーバーは、Kubernetes コントロール プレーンのコンポーネントです
该组件负责公开了 Kubernetes API，负责处理接受请求的工作。API サーバーは、Kubernetes コントロール プレーンのフロントエンドです。Kubernetes API サーバーの主な実装は kube-apiserver です。kube-apiserverこれは水平方向に拡張するように設計されており、複数のインスタンスをデプロイすることで拡張します。kube-apiserverの複数のインスタンスを実行し、それらのインスタンス間でトラフィックのバランスを取ることができます。 -
etcd
一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库。 -
kubeスケジューラー
kube-scheduler実行するノードを指定していない新しく作成された Pod を監視する役割を担うコントロール プレーンのコンポーネントであり、Pod が実行されるノードを選択します。スケジュールの決定で考慮される要素には、個々の Pod と Pod のコレクションのリソース要件、ハードウェア、ソフトウェア、およびポリシーの制約、アフィニティおよび反アフィニティの仕様、データの局所性、ワークロード間の干渉、および期限が含まれます。 -
kube-コントローラー-マネージャー
kube-controller-manager は、コントローラー プロセスの実行を担当するコントロール プレーンのコンポーネントです。論理的には、各コントローラーは別個のプロセスですが、複雑さを軽減するために、それらはすべて同じ実行可能ファイルにコンパイルされ、同じプロセスで実行されます。
これらのコントローラーには次のものが含まれます。
-
ノード コントローラー: ノードに障害が発生した場合の通知と応答を担当します。
-
ジョブ コントローラー: 1 回限りのタスクを表すジョブ オブジェクトを監視し、それらのタスクを完了するまで実行するポッドを作成します。
-
EndpointSlice コントローラー: EndpointSlice オブジェクトを設定します (サービスとポッド間のリンクを提供するため)。
-
サービス アカウント コントローラー (ServiceAccount コントローラー): 新しい名前空間のデフォルトのサービス アカウント (ServiceAccount) を作成します。
-
-
クラウド コントローラー マネージャー(オプション オプション)
クラウド固有の制御ロジックを組み込む Kubernetes コントロール プレーン コンポーネント。クラウド コントローラー マネージャーを使用すると、クラスターをクラウド プロバイダーの API に接続し、そのクラウドと対話するコンポーネントをクラスターと対話するコンポーネントから分離できます。
cloud-controller-managerクラウド プラットフォームに固有のコントローラーのみを実行します。したがって、独自の環境で Kubernetes を実行している場合、またはローカル マシンで学習環境を実行している場合は、デプロイされたクラスターにクラウド コントローラー マネージャーが必要ありません。と同様にkube-controller-manager、cloud-controller-manager論理的に独立した複数の制御ループが同じ実行可能ファイルに結合され、同じプロセスとして実行できます。水平方向に拡張する (複数のレプリカを実行する) ことで、パフォーマンスを向上させたり、フォールト トレランスを向上させることができます。次のコントローラーにはすべて、クラウド プラットフォーム ドライバーへの依存関係が含まれています。
-
ノード コントローラー: クラウド プロバイダーをチェックして、ノードが応答を終了した後にノードが削除されたかどうかを判断するために使用されます。
-
ルート コントローラー: 基盤となるクラウド インフラストラクチャでルーティングを設定するために使用されます。
-
サービス コントローラー: クラウド プロバイダーのロード バランサーの作成、更新、削除に使用されます。
-
1.2 ノードのコンポーネント
ノード コンポーネントは各ノードで実行され、実行中のポッドを維持し、Kubernetes ランタイム環境を提供する役割を果たします。
-
キュベレット
kubelet はクラスター内のすべてのノードで実行されます。これにより、コンテナー (コンテナー) が Pod 内で実行されるようになります。
kubelet は、さまざまなメカニズムを通じて提供される一連の PodSpec を受け取り、これらの PodSpec に記述されているコンテナーが実行中で正常であることを確認します。kubelet は、Kubernetes によって作成されていないコンテナーを管理しません。
-
代理人になる
kube-proxy は、クラスター内の各ノード (ノード) で実行されるネットワーク プロキシであり、Kubernetes サービス (Service) の概念の一部を実現します。
kube-proxy は、クラスター内外のネットワーク セッションからポッドとのネットワーク通信を許可するいくつかのネットワーク ルールをノード上で維持します。
オペレーティング システムが利用可能なパケット フィルタリング層を提供している場合、kube-proxy はそれを介してネットワーク ルールを実装します。それ以外の場合、kube-proxy はトラフィックのみを転送します。
-
コンテナランタイム
コンテナ ランタイムは、コンテナの実行を担当するソフトウェアです。
Kubernetes は、containerd、CRI-0、Docker、その他の Kubernetes CRI 実装など、多くのコンテナー ランタイムをサポートしています。
1.3 アドオン
-
DNS
他のプラグインは厳密に必須ではありませんが、多くの例では DNS サービスが必要であるため、ほとんどすべての Kubernetes クラスターにクラスター DNS が必要です。
-
Webインターフェース（ダッシュボード）
ダッシュボードは、Kubernetes クラスター用の汎用の Web ベースのユーザー インターフェイスです。これにより、ユーザーはクラスター自体だけでなく、クラスター内で実行されているアプリケーションも管理およびトラブルシューティングできるようになります。
-
コンテナリソースの監視
コンテナー リソースの監視は、コンテナーに関するいくつかの一般的な時系列メトリックを一元化されたデータベースに保存し、これらのデータを参照するためのインターフェイスを提供します。
-
クラスターレベルのログ
クラスター レベルのログ メカニズムは、検索および参照インターフェイスを提供する集中ログ ストレージにコンテナーのログ データを保存する役割を果たします。
2 クラスターアーキテクチャの詳細
-
要約する
-
Kubernetesクラスタは複数のノードで構成されており、ノードは管理プレーンに属するマスターノード/コントロールノード(Master Node)と、業務に属するワーカーノード(WorkerNode)の2種類に分けられます。飛行機。明らかに、複雑な作業はコントロール ノードに引き渡される必要があり、ワーカー ノードは安定した操作インターフェイスと機能の抽象化を提供する責任があります。
-
3 クラスター構築 [強調]
-
minikubeは単なる K8S クラスター シミュレーターであり、マスターとワーカーが一緒になっているテスト用の 1 つのノードだけを持つクラスターです。
-
ベアメタルインストールには少なくとも 2 台のマシン (マスターノード用とワーカーノード用に 1 台) が必要で、Kubernetes コンポーネントを自分でインストールする必要があり、設定が少し面倒です。短所: 構成が面倒、ロードバランサーやクラウドストレージなどの環境サポートが欠如している。
-
クラウド プラットフォーム Kubernetes を直接使用して視覚的に構築し、わずか数ステップでクラスターを作成できます。メリット：簡単な導入、完全なエコロジー、ロードバランサー、ストレージなどがすべて提供され、簡単な操作で完了できます。
-
k3s
インストールは簡単で、スクリプトは自動的に完了します。
利点: 軽量、構成要件が低い、設置が簡単、完全なエコロジー。
3.1 minikube
3.2 ベアメタルのインストール
〇環境整備
-
ノード数: 3 仮想マシン centos7
-
ハードウェア構成：2G以上のRAM、2CPU以上、ハードディスク30G以上
-
ネットワーク要件: 複数のノード間のネットワーク相互通信。各ノードは外部ネットワークにアクセスできます。
1 クラスター計画
-
k8s-node1：10.15.0.5
-
k8s-node2：10.15.0.6
-
k8s-node3：10.15.0.7
2 ホスト名を設定する
$ hostnamectl set-hostname k8s-node1
$ hostnamectl set-hostname k8s-node2
$ hostnamectl set-hostname k8s-node33 hostsファイルを同期する
/etc/hostsDNS がホスト名解決をサポートしていない場合は、各マシンのファイルにホスト名と IP の間の対応する関係を追加する必要があります。
cat >> /etc/hosts <<EOF
192.168.2.4 k8s-node1
192.168.2.5 k8s-node2
192.168.2.6 k8s-node3
EOF4 ファイアウォールをオフにする
$ systemctl stop firewalld && systemctl disable firewalld5 SELINUX を閉じる
注: ARM アーキテクチャは実行しないでください。実行すると、IP が取得できないという問題が発生します。
$ setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config6 スワップパーティションを閉じる
$ swapoff -a && sed -ri 's/.*swap.*/#&/' /etc/fstab7 同期時間
$ yum install ntpdate -y
$ ntpdate time.windows.com8containerdをインストールする
# 安装 yum-config-manager 相关依赖
$ yum install -y yum-utils device-mapper-persistent-data lvm2
# 添加 containerd yum 源
$ yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
# 安装 containerd
$ yum install -y containerd.io cri-tools
# 配置 containerd
$ cat > /etc/containerd/config.toml <<EOF
disabled_plugins = ["restart"]
[plugins.linux]
shim_debug = true
[plugins.cri.registry.mirrors."docker.io"]
endpoint = ["https://frz7i079.mirror.aliyuncs.com"]
[plugins.cri]
sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.2"
EOF
# 启动 containerd 服务 并 开机配置自启动
$ systemctl enable containerd && systemctl start containerd && systemctl status containerd
# 配置 containerd 配置
$ cat > /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF
# 配置 k8s 网络配置
$ cat > /etc/sysctl.d/k8s.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF
# 加载 overlay br_netfilter 模块
modprobe overlay
modprobe br_netfilter
# 查看当前配置是否生效
$ sysctl -p /etc/sysctl.d/k8s.conf9 ソースの追加
-
ソースを見る
$ yum repolist-
ソースx86を追加
$ cat <<EOF > kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
$ mv kubernetes.repo /etc/yum.repos.d/-
ソースアームを追加
$ cat << EOF > kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-aarch64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
$ mv kubernetes.repo /etc/yum.repos.d/11 k8sのインストール
# 安装最新版本
$ yum install -y kubelet kubeadm kubectl
# 指定版本安装
# yum install -y kubelet-1.26.0 kubectl-1.26.0 kubeadm-1.26.0
# 启动 kubelet
$ sudo systemctl enable kubelet && sudo systemctl start kubelet && sudo systemctl status kubelet12 クラスターの初期化
-
注意: 初始化 k8s 集群仅仅需要再在 master 节点进行集群初始化!
$ kubeadm init \
--apiserver-advertise-address=本机masterIP地址 \
--pod-network-cidr=10.244.0.0/16 \
--image-repository registry.aliyuncs.com/google_containers \
--cri-socket=unix:///var/run/containerd/containerd.sock
# 添加新节点
$ kubeadm token create --print-join-command --ttl=0
$ kubeadm join 10.15.0.21:6443 --token xjm7ts.gu3ojvta6se26q8i --discovery-token-ca-cert-hash sha256:14c8ac5c04ff9dda389e7c6c505728ac1293c6aed5978c3ea9c6953d4a79ed34 13 クラスターネットワークの構成
構成を作成します: kube-flannel.yml 、kubectl apply -f kube-flannel.yml を実行します。
-
注意: 只在主节点执行即可!
---
kind: Namespace
apiVersion: v1
metadata:
name: kube-flannel
labels:
pod-security.kubernetes.io/enforce: privileged
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: flannel
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: flannel
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: flannel
subjects:
- kind: ServiceAccount
name: flannel
namespace: kube-flannel
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: flannel
namespace: kube-flannel
---
kind: ConfigMap
apiVersion: v1
metadata:
name: kube-flannel-cfg
namespace: kube-flannel
labels:
tier: node
app: flannel
data:
cni-conf.json: |
{
"name": "cbr0",
"cniVersion": "0.3.1",
"plugins": [
{
"type": "flannel",
"delegate": {
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan"
}
}
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: kube-flannel-ds
namespace: kube-flannel
labels:
tier: node
app: flannel
spec:
selector:
matchLabels:
app: flannel
template:
metadata:
labels:
tier: node
app: flannel
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
hostNetwork: true
priorityClassName: system-node-critical
tolerations:
- operator: Exists
effect: NoSchedule
serviceAccountName: flannel
initContainers:
- name: install-cni-plugin
#image: flannelcni/flannel-cni-plugin:v1.1.0 for ppc64le and mips64le (dockerhub limitations may apply)
image: docker.io/rancher/mirrored-flannelcni-flannel-cni-plugin:v1.1.0
command:
- cp
args:
- -f
- /flannel
- /opt/cni/bin/flannel
volumeMounts:
- name: cni-plugin
mountPath: /opt/cni/bin
- name: install-cni
#image: flannelcni/flannel:v0.20.2 for ppc64le and mips64le (dockerhub limitations may apply)
image: docker.io/rancher/mirrored-flannelcni-flannel:v0.20.2
command:
- cp
args:
- -f
- /etc/kube-flannel/cni-conf.json
- /etc/cni/net.d/10-flannel.conflist
volumeMounts:
- name: cni
mountPath: /etc/cni/net.d
- name: flannel-cfg
mountPath: /etc/kube-flannel/
containers:
- name: kube-flannel
#image: flannelcni/flannel:v0.20.2 for ppc64le and mips64le (dockerhub limitations may apply)
image: docker.io/rancher/mirrored-flannelcni-flannel:v0.20.2
command:
- /opt/bin/flanneld
args:
- --ip-masq
- --kube-subnet-mgr
resources:
requests:
cpu: "100m"
memory: "50Mi"
limits:
cpu: "100m"
memory: "50Mi"
securityContext:
privileged: false
capabilities:
add: ["NET_ADMIN", "NET_RAW"]
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: EVENT_QUEUE_DEPTH
value: "5000"
volumeMounts:
- name: run
mountPath: /run/flannel
- name: flannel-cfg
mountPath: /etc/kube-flannel/
- name: xtables-lock
mountPath: /run/xtables.lock
volumes:
- name: run
hostPath:
path: /run/flannel
- name: cni-plugin
hostPath:
path: /opt/cni/bin
- name: cni
hostPath:
path: /etc/cni/net.d
- name: flannel-cfg
configMap:
name: kube-flannel-cfg
- name: xtables-lock
hostPath:
path: /run/xtables.lock
type: FileOrCreate14 クラスターのステータスを表示する
# すべてのクラスター ノードのステータスが [準備完了] として表示されます。これは、クラスターが正常に構築されたことを意味します。
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-node1 Ready control-plane 21h v1.26.0
k8s-node2 Ready <none> 21h v1.26.0
k8s-node3 Ready <none> 21h v1.26.0# クラスター システム内のポッドの実行ステータスを確認します。次のすべてのポッドが実行ステータスになっており、クラスターが利用可能であることを意味します
$ kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx 1/1 Running 0 21h
kube-flannel kube-flannel-ds-gtq49 1/1 Running 0 21h
kube-flannel kube-flannel-ds-qpdl6 1/1 Running 0 21h
kube-flannel kube-flannel-ds-ttxjb 1/1 Running 0 21h
kube-system coredns-5bbd96d687-p7q2x 1/1 Running 0 21h
kube-system coredns-5bbd96d687-rzcnz 1/1 Running 0 21h
kube-system etcd-k8s-node1 1/1 Running 0 21h
kube-system kube-apiserver-k8s-node1 1/1 Running 0 21h
kube-system kube-controller-manager-k8s-node1 1/1 Running 0 21h
kube-system kube-proxy-mtsbp 1/1 Running 0 21h
kube-system kube-proxy-v2jfs 1/1 Running 0 21h
kube-system kube-proxy-x6vhn 1/1 Running 0 21h
kube-system kube-scheduler-k8s-node1 1/1 Running 0 21h