注: この記事は、Li Zhenliang 先生からのものです。
「完全なエンタープライズ K8s クラスターをデプロイする」
v1.20 、kubeadmの方法
| 著者情報 |
Li Zhenliang (A Liang)、WeChat: xyz12366699 |
| DevOps実践アカデミー |
|
| 例証する |
ドキュメントには、読みやすいナビゲーション ペインがあります。左側に表示されていない場合は、Word が有効になっているかどうかを確認してください。 転載の際は作者を明示し、倫理に反する行為はお断りします！ |
| 最終更新 |
2021-04-21 |
目次
1.1 本番環境に Kubernetes クラスターをデプロイする 2 つの方法... 2
2. Nginx+Keepalived High Availability Load Balancer をデプロイする... 6
2.1 ソフトウェアパッケージのインストール (メイン/スタンバイ)... 7
2.2 Nginx 構成ファイル (マスター/スタンバイと同じ).... 7
2.3 キープアライブ構成ファイル (Nginx マスター).... 9
2.4 keepalived 構成ファイル (Nginx バックアップ).... 10
2.6 keepalived の動作状況を確認する... 12
2.7 Nginx+Keepalived 高可用性テスト....12
3.1 cfssl 証明書生成ツールを準備する ... 13
3.3 Github からバイナリをダウンロード....16
4. Docker/kubeadm/kubelet をインストール [全ノード].... 21
4.2 Alibaba Cloud YUM ソフトウェアソースの追加... 21
4.3 kubeadm、kubelet、および kubectl のインストール.. 21
5. Kubernetes マスターをデプロイする.. 22
1. 事前知識ポイント
1.1 本番環境に Kubernetes クラスターをデプロイする 2 つの方法
現在、本番環境で Kubernetes クラスターをデプロイする主な方法は 2 つあります。
- kubeadm
Kubeadm は、Kubernetes クラスターの迅速なデプロイのために kubeadm init と kubeadm join を提供する K8s デプロイ ツールです。
- バイナリパッケージ
ディストリビューションのバイナリ パッケージを github からダウンロードし、各コンポーネントを手動でデプロイして Kubernetes クラスターを形成します。
ここでは、kubeadm を使用してクラスターを構築します。
kubeadm ツール機能:
- kubeadm init:マスター ノードを初期化する
- kubeadm join:ワーカー ノードをクラスターに参加させます
- kubeadm のアップグレード: K8s のバージョンをアップグレードします
- kubeadm token: kubeadm join で使用されるトークンを管理します
- kubeadm reset: kubeadm init または kubeadm join によってホストに加えられたすべての変更をクリアします
- kubeadm バージョン: kubeadm バージョンを表示
- kubeadm alpha:利用可能な新機能のプレビュー
1.2 環境を整える
サーバー要件:
- 推奨される最小ハードウェア構成: 2 コア CPU、2G メモリ、30G ハードディスク
- サーバーは外部ネットワークにアクセスできることが望ましく、インターネットからイメージをプルする必要があります.サーバーがインターネットにアクセスできない場合は、事前に対応するイメージをダウンロードしてノードにインポートする必要があります.
ソフトウェア環境:
| ソフトウェア |
バージョン |
| オペレーティング·システム |
CentOS7.8_x64 （ミニ） |
| ドッカー |
19世紀 |
| Kubernetes |
1.20 |
サーバーの全体的な計画:
| 役割 |
知財 |
その他のシングルパック コンポーネント |
| k8s-master1 |
192.168.16.80 |
docker，etcd，nginx，keepalived |
| k8s-master2 |
192.168.16.81 |
docker，etcd，nginx，keepalived |
| k8s-node1 |
192.168.16.82 |
docker，etcd |
| ロードバランサーの外部 IP |
192.168.16.88 (VIP) |
アーキテクチャ図:
1.3 オペレーティング システムの初期化構成
＃ファイアウォール を閉じる _ _ _ _ _ _ *swap.*/#&/' /etc/fstab # 恒久的 # 計画に従ってホスト名を設定 hostnamectl set-hostname <hostname> # ホストを追加 cat >> /etc/hosts << EOF 192.168.16.80 k8s-master01
192.168.16.81 k8s-master02
192.168.16.82 k8s-node01
192.168.16.83 k8s-node02
192.168.16.88 k8s-vip EOF #ブリッジされた IPv4 トラフィックを iptables チェーンに転送 cat > /etc/sysctl.d/k8s.conf << EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge- nf-call-iptables = 1 EOF sysctl --system # effective # 時刻同期 yum install ntpdate -y ntpdate time.windows.com
ntpdate cn.pool.ntp.org
crontab -l
0 5 * * * /usr/sbin/ntpdate -u cn.pool.ntp.org
[root@k8s-master01 ~]# systemctl enable ntpdate.service
2. Nginx+Keepalived 高可用性ロード バランサーをデプロイする
コンテナー クラスター システムである Kubernetes は、ヘルス チェック + 再起動戦略によって Pod 障害の自己修復機能を実現し、スケジューリング アルゴリズムによって Pod の分散展開を実現し、予想されるコピー数を維持し、Node に応じて他の Node の Pod を自動的にプルアップします。障害ステータス アプリケーション層での高可用性。
Kubernetes クラスターの場合、高可用性には、Etcd データベースの高可用性と Kubernetes マスター コンポーネントの高可用性という 2 つの考慮事項も含める必要があります。kubeadm で構築した K8s クラスタでは、Etcd が 1 つしかなく、ポイントが 1 つしかないため、ここでは Etcd クラスタを個別に構築します。
マスター ノードは、マスター コントロール センターの役割を果たし、ワーカー ノード上の Kubelet および kube-proxy と常に通信することにより、クラスター全体の正常な動作状態を維持します。マスター ノードに障害が発生すると、クラスター管理に kubectl ツールまたは API を使用できなくなります。
マスターノードには主に kube-apiserver、kube-controller-manager、kube-scheduler の 3 つのサービスがありますが、このうち kube-controller-manager と kube-scheduler コンポーネントは選択メカニズムにより高可用性を実現しているため、高可用性Master の主なコンポーネントは kube-apiserver Component で、このコンポーネントは HTTP API でサービスを提供するため、Web サーバーと同様の高可用性を備えています。ロード バランサーを追加して負荷を分散するだけで、水平方向に拡張できます。
kube-apiserver の高可用性アーキテクチャ図:
- Nginx は主流の Web サービスであり、リバース プロキシ サーバーです. ここでは、apiserver の負荷分散を実現するために 4 つのレイヤーが使用されます。
- Keepalived は主流の高可用性ソフトウェアで、VIP バインディングに基づいてサーバーのホット バックアップを実現します. 上記のトポロジでは、Keepalived は主に Nginx の実行状態に基づいてフェイルオーバー (オフセット VIP) が必要かどうかを判断します. たとえば、Nginx がマスター ノードがハングアップすると、VIP VIP が常に使用可能になり、Nginx の高可用性が実現されるように、Nginx スタンバイ ノードに自動的にバインドされます。
注: マシンを保存するために、ここでは K8s マスター ノード マシンで再利用されます。nginx と apiserver が通信できる限り、k8s クラスターから独立してデプロイすることもできます。
2.1 ソフトウェア パッケージのインストール (メイン/スタンバイ)
yum install epel-release -y
yum install nginx keepalived -y
2.2 Nginx構成ファイル (マスター/スタンバイと同じ)
cat > /etc/nginx/nginx.conf << "EOF" user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; include /usr/share/nginx/modules /*.conf; events { worker_connections 1024; } # 2つのマスター apiserver コンポーネントに負荷分散 ストリームを提供する 4 層の負荷分散 { log_format main '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent'; access_log /var/ log/nginx/k8s-access.log main; 上流の k8s-apiserver { server 192.168.16.80:6443; # Master1 APISERVER IP:PORT server 192.168.16.81:6443; # Master2 APISERVER IP:PORT } server { listen 16443; # nginx とマスター ノードは多重化されている ため、 リッスン ポートを 6443 にすることはできませ ん 。 ' $ status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc /nginx/mime.types; default_type アプリケーション/オクテット ストリーム; サーバー { リッスン 80 default_server; サーバーの名前 _; 場所 / { } } } EOF
2.3 keepalived 構成ファイル (Nginx マスター)
cat > /etc/keepalived/keepalived.conf << EOF global_defs { notification_email { [email protected] [email protected] [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id NGINX_MASTER } vrrp_script check_nginx { script "/etc/keepalived/check_nginx.sh" } vrrp_instance VI_1 { state MASTER interface ens33 #実際のネットワーク カード名に変更 virtual_router_id 51 # VRRP ルーティング ID インスタンス、各インスタンスは一意の 優先度 100 # 優先度、スタンバイ サーバー セット90 advert_int 1 # VRRP ハートビート パケットの通知間隔を指定します。デフォルトは 1 秒です authentication { auth_type PASS auth_pass 1111 } # virtual IP virtual_ipaddress { 192.168.16.88/24 } track_script { check_nginx } } EOF
- vrrp_script: nginx の動作状況を確認するスクリプトを指定します (nginx の状況に応じてフェイルオーバーするかどうかを判断します)。
- virtual_ipaddress: 仮想 IP (VIP)
上記の構成ファイルで、nginx の実行ステータスを確認するスクリプトを準備します。
cat > /etc/keepalived/check_nginx.sh << "EOF"
#!/bin/bash
count=$(ss -antp |grep 16443 |egrep -cv "grep|$$")
if [ "$count" -eq 0 ];then
exit 1
else
exit 0
fi
EOF
chmod +x /etc/keepalived/check_nginx.sh
2.4 keepalived 構成ファイル (Nginx バックアップ)
cat > /etc/keepalived/keepalived.conf << EOF global_defs { notification_email { [email protected] [email protected] [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id NGINX_BACKUP } vrrp_script check_nginx { script "/etc/keepalived/check_nginx.sh" } vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 51 # VRRPルーティング ID インスタンス、各インスタンスは一意の 優先度 90 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.16.88/24 } track_script { check_nginx } } EOF
上記の構成ファイルで、nginx の実行ステータスを確認するスクリプトを準備します。
cat > /etc/keepalived/check_nginx.sh << "EOF"
#!/bin/bash
count=$(ss -antp |grep 16443 |egrep -cv "grep|$$")
if [ "$count" -eq 0 ];then
exit 1
else
exit 0
fi
EOF
chmod +x /etc/keepalived/check_nginx.sh
注: keepalived は、スクリプトから返されるステータス コード (0 は正常な動作を意味し、0 以外は異常を意味します) に従って、フェイルオーバーするかどうかを判断します。
2.5 スタートアップの起動と設定
systemctl daemon-reload systemctl start nginx —— nginx启动不成功 systemctl start keepalived systemctl enable nginx systemctl enable keepalived
2.6 keepalived の動作ステータスを表示する
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 スコープ ホスト lo
valid_lft 永久に preferred_lft 永久に
inet6 ::1/128 スコープ ホスト
valid_lft 永久に Preferred_lft 永久
に 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 状態 UP グループ デフォルト qlen 1000
リンク/イーサ00:0c:29:04:f7:2c brd ff:ff:ff:ff:ff:ff
inet 192.168.31.80/24 brd 192.168.31.255 スコープ グローバル noprefixroute ens33
valid_lft 永久に preferred_lft 永久に
inet 192.168.31.88/24 スコープ グローバル セカンダリens33
valid_lft 永久に preferred_lft 永久
に inet6 fe80::20c:29ff:fe04:f72c/64 スコープ リンク
valid_lft 永久に Preferred_lft 永久に
192.168.31.88 の仮想 IP が ens33 ネットワーク カードにバインドされていることがわかります。これは、正常に動作していることを示しています。
2.7 Nginx+Keepalived高可用性テスト
アクティブ ノードで Nginx をシャットダウンし、VIP がスタンバイ ノードのサーバーにドリフトしたかどうかをテストします。
Nginx マスターで pkill nginx を実行し、
Nginx バックアップで ip addr コマンドを実行して、VIP が正常にバインドされていることを確認します。
3. Etcd クラスターをデプロイする
研究で問題が発生した場合、または文書が間違っている場合は、A Liang に連絡してください〜 Wechat: xyz12366699
Etcd は分散キー値ストレージ システムです. Kubernetes はデータ ストレージに Etcd を使用します. デフォルトでは, kubeadm のビルド時に 1 つの Etcd Pod のみが開始されます. 単一障害点があります. 本番環境では強く推奨されません.ここでは 3 台のサーバーを使用してクラスターを形成します. 1 台のマシンの障害を許容することはもちろん、5 台のマシンを使用してクラスターを形成し、2 台のマシンの障害を許容できるクラスターを形成することもできます。
| ノード名 |
知財 |
| etcd-1 |
192.168.16.80 |
| etcd-2 |
192.168.16.81 |
| etcd-3 |
192.168.16.82 |
注: マシンを節約するために、ここでは K8s ノード マシンで再利用されます。apiserver が接続できる限り、k8s クラスターから独立してデプロイすることもできます。
3.1 cfssl 証明書生成ツールの準備
cfssl は、json ファイルを使用して証明書を生成するオープン ソースの証明書管理ツールであり、openssl よりも便利に使用できます。
操作するサーバーを見つけます。ここでは、マスター ノードを使用します。
[root@k8s-master01 ~]# cd /opt/
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2 /cfssl-certinfo_linux-amd64
chmod +x cfssl_linux-amd64 cfssljson_linux-amd64 cfssl-certinfo_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
mv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo
3.2 Etcd 証明書の生成
1.自己署名認証局 (CA)
作業ディレクトリを作成します。
mkdir -p ~/etcd_tls
cd ~/etcd_tls
自己署名 CA:
cat > ca-config.json << EOF
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"www": {
"expiry": "87600h",
"usages ": [
"署名"、 "キー暗号
化
"、
"サーバー認証"、
"クライアント認証"
]
}
}
}
EOF
猫 > ca-csr.json << EOF
{
"CN": "etcd CA",
"キー" : {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "北京",
"ST": "北京"
}
]
}
EOF
証明書を生成します。
cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
ca.pem および ca-key.pem ファイルが生成されます。
2.自己署名 CA を使用して Etcd HTTPS 証明書を発行する
証明書要求ファイルを作成します。
cat > server-csr.json << EOF
{
"CN": "etcd",
"hosts": [
"192.168.16.80",
"192.168.16.81",
"192.168.16.82"
],
"key": {
"algo ": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "北京",
"ST": "北京"
}
]
}
EOF
注: 上記のファイルの hosts フィールドの IP は、すべての etcd ノードのクラスター内部通信 IP であり、どれも欠落することはできません! 後の拡張を容易にするために、さらにいくつかの予約済み IP を書き込むことができます。
証明書を生成します。
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=www server-csr.json | cfssljson -ベアサーバー
server.pem および server-key.pem ファイルが生成されます。
3.3 Github からバイナリをダウンロードする
ダウンロードリンク: https://github.com/etcd-io/etcd/releases/download/v3.4.9/etcd-v3.4.9-linux-amd64.tar.gz
3.4 Etcd クラスターのデプロイ
次の操作はノード 1 で実行されます。操作を簡素化するために、ノード 1 によって生成されたすべてのファイルは後でノード 2 とノード 3 にコピーされます。
1.作業ディレクトリを作成し、バイナリ パッケージを解凍します。
mkdir /opt/etcd/{bin,cfg,ssl} -p tar zxvf etcd-v3.4.9-linux-amd64.tar.gz mv etcd-v3.4.9-linux-amd64/{etcd,etcdctl} /opt/etcd /置き場/
猫 > /opt/etcd/cfg/etcd.conf << EOF
#[メンバー]
ETCD_NAME="etcd-1"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://192.168.16.80 :2380"
ETCD_LISTEN_CLIENT_URLS="https://192.168.16.80:2379"
#[クラスタリング]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.16.80:2380
" ETCD_ADVERTISE_CLIENT_URLS
="https://192.168.16.80:2379" -1=https://192.168.16.80:2380,etcd-2=https://192.168.16.81:2380,etcd-3=https://192.168.16.82:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE= 「新しい」
EOF
- ETCD_NAME: クラスタ内で一意のノード名
- ETCDDATADIR: データディレクトリ
- ETCDLISTENPEER_URLS: クラスタ通信リスニング アドレス
- ETCDLISTENCLIENT_URLS: クライアント アクセスのリッスン アドレス
- ETCDINITIALADVERTISEPEERURLS: クラスター通知アドレス
- ETCDADVERTISECLIENT_URLS: クライアント通知アドレス
- ETCDINITIALCLUSTER: クラスタ ノード アドレス
- ETCDINITIALCLUSTER_TOKEN: クラスタートークン
- ETCDINITIALCLUSTER_STATE: クラスターの現在の状態に参加します。new は新しいクラスターです。existing は既存のクラスターに参加することを意味します。
cat > /usr/lib/systemd/system/etcd.service << EOF
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
Type=notify
EnvironmentFile =/opt/etcd/cfg/etcd.conf
ExecStart=/opt/etcd/bin/etcd \
--cert-file=/opt/etcd/ssl/server.pem \
--key-file=/opt/etcd/ ssl/server-key.pem \
--peer-cert-file=/opt/etcd/ssl/server.pem \
--peer-key-file=/opt/etcd/ssl/server-key.pem \
-- trusted-ca-file=/opt/etcd/ssl/ca.pem \
--peer-trusted-ca-file=/opt/etcd/ssl/ca.pem \
--logger=zap
Restart=on-failure
LimitNOFILE= 65536
[インストール]
WantedBy=multi-user.target
EOF
4.生成されたばかりの証明書をコピーします
新しく生成された証明書を構成ファイルのパスにコピーします。
cp ~/etcd_tls/ca*pem ~/etcd_tls/server*pem /opt/etcd/ssl/
systemctl daemon-reload
systemctl start etcd
systemctl enable etcd
6.上記のノード 1 によって生成されたすべてのファイルをノード 2 およびノード 3 にコピーします。
scp -r /opt/etcd/ [email protected]:/opt/
scp /usr/lib/systemd/system/etcd.service [email protected]:/usr/lib/systemd/system/
scp -r /opt /etcd/ [email protected]:/opt/
scp /usr/lib/systemd/system/etcd.service [email protected]:/usr/lib/systemd/system/
次に、ノード 2 とノード 3 の etcd.conf 構成ファイルでノード名と現在のサーバー IP をそれぞれ変更します。
vi /opt/etcd/cfg/etcd.conf #[Member] ETCD_NAME="etcd-1" #ここを修正 ノード 2 を etcd-2 に、ノード 3 を etcd-3 に変更 ETCD_DATA_DIR="/var/lib/ etcd/ default.etcd" ETCD_LISTEN_PEER_URLS="https://192.168.31.71:2380" # 現在のサーバー IP としてここを 変更 ETCD_LISTEN_CLIENT_URLS="https://192.168.31.71:2379" #現在のサーバー IP としてここを変更 #[ クラスタリング] ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.31.71:2380" # 現在のサーバー IP としてここを 変更 ETCD_ADVERTISE_CLIENT_URLS="https://192.168.31.71:2379" #現在のサーバー IP としてここを変更 ETCD_INITIAL_CLUSTER="etcd-1 =https ://192.168.31.71:2380,etcd-2=https://192.168.31.72:2380,etcd-3=https://192.168.31.73:2380" ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster" ETCD_INITIAL_CLUSTER_STATE="新規"
最後に、上記のように、etcd を開始し、ブート時に開始するように設定します。
ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/ server-key.pem --endpoints="https://192.168.16.80:2379,https://192.168.16.81:2379,https://192.168.16.82:2379" エンドポイントの正常性 --write-out=table
+ ----------------------------+--------------------+------------ -+--------+
| エンドポイント | 健康 | とった | エラー |
+----------------------------+--------+----------------------- --+---------+
| https://192.168.31.61:2379 | 真 | 10.301506ms | | |
| | https://192.168.31.63:2379 | 真 | 12.87467ms | | |
| | https://192.168.31.62:2379 | 真 | 13.225954ms | | |
+----------------------------+--------+----------------------- --+---------+
原因tailf -n 10 /var/log/messages 送信されたリクエストは、クラスター ID の不一致により、リモート ピアによって無視されました
問題が解決しました：
新しいクラスターの回避策
3 つの etcd サービスを停止し、3 つのノードの etcd データを削除してから、リロードして開始すると、3 つの etcd サービスが正常に開始されます。
[root@k8s-master01 ~]# systemctl stop etcd
[root@k8s-master01 ~]# cd /var/lib/etcd/default.etcd
[root@k8s-master01 default.etcd]# rm -rf member/
[root@k8s-master01 default.etcd]# systemctl daemon-reload
[root@k8s-master01 default.etcd]# systemctl start etcd
分析: 3 番目の etcd サービスが以前に開始できない (ステータスが常に開始されている) 理由は、そのサーバーの時刻が他の 2 つのサーバーと同期されていないためです。
ntpdate cn.pool.ntp.org
ntpdate サービスのインストールと同期時刻サーバーの実行に加えて、起動時に ntpdate サービスが自動的に開始されるように設定する必要があります。
上記の情報が出力されれば、クラスタのデプロイは成功です。
問題がある場合、最初のステップはログを確認することです: /var/log/message または journalctl -u etcd
4. Docker/kubeadm/kubelet をインストール [全ノード]
ここでは、コンテナー エンジンとして Docker を使用していますが、containerd などの別のエンジンに置き換えることもできます。
4.1 Docker のインストール
wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo yum -y install docker-ce systemctl docker を有効にする&& systemctl start docker
ミラー ダウンロード アクセラレータを構成します。
cat > /etc/docker/daemon.json << EOF
{
"registry-mirrors": ["https://b9pmyelo.mirror.aliyuncs.com"]
}
EOF
systemctl restart docker
docker info
4.2 Alibaba Cloud YUM ソフトウェア ソースの追加
cat > /etc/yum.repos.d/kubernetes.repo << EOF
[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
4.3 kubeadm、kubelet、および kubectl のインストール
バージョンの更新が頻繁に行われるため、バージョン番号の展開は次のように指定されます。
yum インストール -y kubelet-1.20.0 kubeadm-1.20.0 kubectl-1.20.0
systemctl enable kubelet
5. Kubernetes マスターをデプロイする
研究で問題が発生した場合、または文書が間違っている場合は、A Liang に連絡してください〜 Wechat: xyz12366699
5.1 Master1 の初期化
初期化構成ファイルを生成します。
cat > kubeadm-config.yaml << EOF apiVersion: kubeadm.k8s.io/v1beta2 bootstrapTokens: - グループ: - system:bootstrappers:kubeadm:default-node-token トークン: 9037x2.tcaqnpaqkra9vsbw ttl: 24h0m0s 使用法: - 署名 - 認証 種類: InitConfiguration localAPIEndpoint: 広告アドレス: 192.168.16.80 bindPort: 6443 nodeRegistration: criSocket: /var/run/dockershim.sock 名: k8s-master01 テイント: - 効果: NoSchedule キー: node-role.kubernetes.io/master --- apiServer: certSANs: #すべてのマスター/LB/VIP IP を含み、1 つも少なくありません! 後の拡張を容易にするために、さらにいくつかの予約済み IP を書き込むことができます。 - k8s-master01 - k8s-master02 - 192.168.16.80 - 192.168.16.81 - 192.168.16.82 - 127.0.0.1 extraArgs: 承認モード: ノード、RBAC timeoutForControlPlane: 4m0s apiVersion: kubeadm.k1betas2c8s.io/vertific clusterName: kubernetes controlPlaneEndpoint: 192.168.16.88:16443 # 負荷分散仮想 IP (VIP) とポート controllerManager: {} dns: type: CoreDNS etcd: external: # 外部 etcd エンドポイントを使用: - https://192.168.16.80 :2379 # etcd クラスター3 ノード - https://192.168.16.81:2379 - https://192.168.16.82:2379 caFile: /opt/etcd/ssl/ca.pem # etcd への接続に必要な証明書 certFile: /opt/etcd/ssl/server.pem keyFile: /opt/etcd/ssl/server -key.pem imageRepository: registry.aliyuncs.com/google_containers # 中国ではデフォルトのプル イメージ アドレス k8s.gcr.io にアクセスできないため、Alibaba Cloud イメージ リポジトリのアドレスは次のとおりです kind : ClusterConfiguration kubernetesVersion: v1.20.0 # K8s バージョン、上記と同じ インストールされた一貫性のある ネットワーク: dnsDomain: cluster.local podSubnet: 10.244.0.0/16 # Pod ネットワーク、CNI ネットワーク コンポーネントと一貫性があり、 serviceSubnet の下にデプロイされた yaml: 10.96.0.0/12 # クラスター内部仮想ネットワーク、Pod統合アクセス エントリ スケジューラ: {} EOF
または、構成ファイルを使用してブートストラップします。
kubeadm init --config kubeadm-config.yaml ... Kubernetes コントロール プレーンが正常に初期化されました。 クラスターの使用を開始するには、通常のユーザーとして次を実行する必要があります: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id - u):$(id -g) $HOME/.kube/config または、root ユーザーの場合は、次を実行できます。 export KUBECONFIG=/etc/kubernetes/admin.conf これで、Pod ネットワークをクラスターにデプロイする必要があります。 . https://kubernetes.io/docs/concepts/cluster-administration/addons/ にリストされているオプションのいずれかを使用して、「kubectl apply -f [podnetwork].yaml」を実行します。 各ノードで認証局とサービス アカウント キーをコピーし、ルート として以下を実行することで、任意 の数のコントロール プレーン ノードに参加できるようになりました 。 ca-cert-hash sha256:b1e726042cdd5df3ce62e60a2f86168cd2e64bff856e061e465df10cd36295b8 \ --control-planeその後、 ルートとして次のコマンドを実行することで、任意の数のワーカー ノードに参加 できます 。トークン-ca-証明書-ハッシュ sha256:b1e726042cdd5df3ce62e60a2f86168cd2e64bff856e061e465df10cd36295b8
初期化が完了すると、2 つの結合コマンドが表示されます。 --control-plane を使用して結合してマルチマスター クラスターを形成し、それを使用せずにノードを結合します。
kubectl が使用する接続 k8s 認証ファイルをデフォルト パスにコピーします。
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master1 NotReady コントロール プレーン、マスター 6m42s v1.20.0
5.2 Master2 の初期化
Master1 ノードによって生成された証明書を Master2 にコピーします。
scp -r /etc/kubernetes/pki/ 192.168.16.81:/etc/kubernetes/
マスター結合コマンドをコピーして結合し、master2 で実行します。
kubeadm 参加 192.168.31.88:16443 --token 9037x2.tcaqnpaqkra9vsbw \
--discovery-token-ca-cert-hash sha256:b1e726042cdd5df3ce62e60a2f86168cd2e64bff856e061e465df10cd36295b \
--control-plane
kubectl が使用する接続 k8s 認証ファイルをデフォルト パスにコピーします。
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master1 NotReady コントロール プレーン、マスター 28m v1.20.0
k8s-master2 NotReady コントロール プレーン、マスター 2m12s v1.20.0
注: ネットワーク プラグインがまだデプロイされていないため、NotReady です。
5.3アクセスロードバランサのテスト
K8s クラスター内の任意のノードを見つけ、curl を使用して K8s バージョン テストを表示し、VIP アクセスを使用します。
curl -k https://192.168.16.88:16443/version
{
"major": "1",
"minor": "20",
"gitVersion": "v1.20.0",
"gitCommit": "e87da0bd6e03ec3fea7933c4b5263d151aafd07c",
" gitTreeState": "clean",
"buildDate": "2021-02-18T16:03:00Z",
"goVersion": "go1.15.8",
"compiler": "gc",
"platform": "linux/amd64"
}
K8sのバージョン情報が正しく取得でき、ロードバランサーが正常にセットアップされていることがわかります。リクエスト データ フロー: curl -> vip(nginx) -> apiserver
Nginx ログを見て、転送 apiserver IP を確認することもできます。
テール /var/log/nginx/k8s-access.log -f
192.168.31.71 192.168.31.71:6443 - [2021 年 4 月 2 日:19:17:57 +0800] 200 423
192.168.31.71 192.168.31.72:6443 - [02/04/2021:19:18:50 +0800] 200 423
6. Kubernetes ノードに参加する
192.168.16.82 (ノード) で実行されます。
クラスターに新しいノードを追加するには、kubeadm init によって出力された kubeadm join コマンドを実行します。
kubeadm join 192.168.16.88:16443 --token 9037x2.tcaqnpaqkra9vsbw \
--discovery-token-ca-cert-hash sha256:e6a724bb7ef8bb363762fbaa088f6eb5975e0c654db038560199a7063735a697
後続の他のノードも同様に追加されます。
注: デフォルトのトークンは 24 時間有効で、有効期限が切れると、トークンは使用できなくなります。この時点で、次のコマンドを使用して直接生成できるトークンを再作成する必要があります: kubeadm token create --print-join-command
7. ネットワーク コンポーネントを展開する
Calico は純粋な 3 層データ センター ネットワーク ソリューションであり、現在 Kubernetes の主流ネットワーク ソリューションです。
Calico をデプロイします。
kubectl apply -f calico.yaml
kubectl get pods -n kube-system
Calico Pod が実行されると、ノードの準備が整います。
kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master1 Ready control-plane,master 50m v1.20.0
k8s-master2 Ready control-plane,master 24m v1.20.0
k8s-node1 Ready <なし> 20m v1.20.0
8. ダッシュボードをデプロイする
ダッシュボードは、K8s リソースの基本的な管理に使用できる公式 UI です。
kubectl apply -f kubernetes-dashboard.yaml #デプロイメントの表示 kubectl get pods -n kubernetes-dashboard
アクセスアドレス：https://NodeIP:30001
サービス アカウントを作成し、デフォルトの cluster-admin 管理者クラスター ロールをバインドします。
kubectl create serviceaccount dashboard-admin -n kube-system
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
kubectl describe secrets -n kube-system $(kubectl -n kube- system get secret | awk '/dashboard-admin/{print $1}')
出力トークンを使用して、ダッシュボードにログインします。
