要約
昨年、Raspberry Piを使用してk8sクラスターを構築しましたが、当時はこれについてあまり知らなかったため、単純なクラスターを構築し、ネットワークプラグインをインストールし、単純なダッシュボードのみをインストールし、実際のデプロイは行いませんでした。以前の記事へのリンク:RaspberryPi4Bを使用してk8sクラスターを構築する方法を教えてください
最近、気まぐれに、アプリケーションをテストしてデプロイするためのビルディングブロックを備えた新しいシャーシを作成しました。今日は、参考のために最近経験したすべてのプロセスと問題を要約します。
事前問題の処理
ネットワークプラグインの交換
前回の記事では、ネットワークプラグインのcolicoがインストールされている、つまり、colicoプラグインポッドが起動しないことが最近判明しました。長い間試しても成功しなかったので、再インストールしてインストールしただけです。前のチュートリアルによると、ファンネルプラグインのみを再インストールできます。
Webプラグインを削除します
最初にネットワークプラグインを削除します
kubectl delete -f calico.yaml
复制代码
この時点で、tunl0仮想ネットワークカードが残っています。何度も試し、実際の状況に応じて変更できる1つのコマンドに多くのシェルコマンドを組み合わせたため、ifconfigを使用して表示およびアンインストールできます。
ifconfig tunl0 down;ip link delete tunl0;rm -f /etc/cni/net.d/*;kubectl delete -f calico.yaml;systemctl start kubelet; systemctl start docker
复制代码
クラスターのリセット
3台のマシンでクラスター初期化コマンドを実行します。
kubeadm reset
复制代码
3台のマシンが構成ファイルを削除します。
rm -rf $HOME/.kube;rm -rf /etc/cni/net.d
复制代码
dockerとkubeletを再起動すると、ファイアウォールルールがクリアされます。
systemctl daemon-reload;systemctl stop kubelet; systemctl stop docker; iptables --flush; iptables -tnat --flush;systemctl start kubelet; systemctl start docker
复制代码
クラスターのインストール
前の記事のように、マスターノードのインストールについてはここでは詳しく説明しません。
sudo kubeadm init --image-repository=registry.aliyuncs.com/google_containers --kubernetes-version=v1.20.0 --apiserver-advertise-address=192.168.2.181 --pod-network-cidr=192.168.0.0/16 --ignore-preflight-errors=all
复制代码
ノードノード参加コマンド
kubeadm join 192.168.2.181:6443 --token jqll23.kc3nkji7vxkaefro --discovery-token-ca-cert-hash sha256:1b475725b680ed8111197eb8bfbfb69116b38a8d2960d51d17af69188b6badc2 --ignore-preflight-errors=all
复制代码
すべてのノードコマンドを表示します。
kubectl get pods --all-namespaces
复制代码
マシンの再起動後にコマンドを実行すると、エラーが報告されることがあります。サーバーlocalhost:8080への接続が拒否されました-正しいホストまたはポートを指定しましたか?
解決策:理由:kubernetesマスターがマシンにバインドされていません。また、クラスターは初期化時にバインドされません。この時点でローカルマシンに環境変数を設定することで、問題を解決できます。
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> /etc/profile
source /etc/profile
复制代码
この問題は、起動時に自動的に実行されるスクリプトに配置するsource /etc/profile
ことで完全に解決できます。
ポッド実行エラー、ログを確認
何度も試しましたが、ネットワークプラグインをインストールした後、ポッドが正常に実行されないことがよくあります。次のコマンドを使用して、ログの理由を表示できます。
kubectl logs -f test-k8s-68bb74d654-9wwbt -n kube-system
复制代码
test-k8s-68bb74d654-9wwbt
特定のポッド名です
ネットワークプラグインをインストールする
公式のyamlファイルを使用する
curl -sSL https://raw.githubusercontent.com/coreos/flannel/v0.12.0/Documentation/kube-flannel.yml | kubectl apply -f -*
复制代码
没想到直接成功了,之前都是无法连接10.1244.***.**的报错.
查看所有pod
kubectl get pods --all-namespaces
复制代码
现在是第一个应用安装完成了,pod名称test-k8s的应用就是我安装的应用,它命名空间是default的,跟其他的不同。
查看所有Node
kubectl get node --all-namespaces
复制代码
跟上个命令一样的,改了一个地方
安装第一个应用
制作镜像
安装应用就应该写一个yaml文件,和一个可用的镜像,我参考的是B站的广州云科
的视频教程,但是他的测试的应用是基于X86平台的,镜像直接运行报错如下:
所以只有自己重新制作镜像,先找到项目地址:test-k8s 把代码全部克隆到树莓派机器上:
要弄一个镜像仓库提供给集群拉取,然后我自己测试使用的阿里云的容器镜像服务,要设置成开放的仓库,允许所有的人拉取这个镜像
别人的DockerFile已经写好了我们直接使用docker build命令打包镜像(现在为了重新推送测试,我把所有镜像都和容器删掉) 主要根据阿里云的教程就行了,如下:
打包&推送到阿里云
先本地打包,打包镜像名为k8s,-t
为镜像标签的简写,tag的意思。可以在构建中设置多个标签
docker build -t test-k8s .
复制代码
镜像打一个新tag
docker tag test-k8s:latest registry.cn-shenzhen.aliyuncs.com/koala9527/testapp:latest
复制代码
推送
docker push registry.cn-shenzhen.aliyuncs.com/koala9527/testapp:latest
复制代码
到现在这个镜像就在阿里云的容器镜像服务中了,镜像地址为: registry.cn-shenzhen.aliyuncs.com/koala9527/testapp:latest
写第一个应用的yaml文件
文件名testapp.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
# 部署名字
name: test-k8s
spec:
replicas: 3
# 用来查找关联的 Pod,所有标签都匹配才行
selector:
matchLabels:
app: test-k8s
# 定义 Pod 相关数据
template:
metadata:
labels:
app: test-k8s
spec:
# 定义容器,可以多个
containers:
- name: test-k8s # 容器名字
image: registry.cn-shenzhen.aliyuncs.com/koala9527/testapp:v1 # 镜像
resources:
requests:
cpu: 100m
复制代码
这里稍微解释复习一下这些资源描述文件中字段得意思,虽然上篇文章也有解释
apiVersion
:api版本,我的理解就是资源控制的相关版本控制,k8s里的功能在高速迭代,不同的资源控制器使用不同的api版本,不同版本集群支持的api不同,写的yaml文件需要配合真实的集群环境,资源控制器类型就是用kind
字段指定。
可以使用kubectl api-versions
查看集群的api版本
kind
:控制器类型,集群里面的所有资源都被k8s高度抽象化,kind就是表明这些资源的类型,Deployment
就是一个定义一个多副本的无状态资源对象。
name: test-k8s
:指定资源控制器的名字为test-k8s replicas
:初始化指定的pod的个数 matchLabels
:选择器标签,要用其他资源控制指定这个资源的时候用这个标签值
template
这个字段下面就是包含这个pod的相关数据,app: test-k8s
指定pod的名字,image
pod的镜像拉取地址,requests
申请的CPU资源,0.1m等于0.1个CPU资源。
部署应用
kubectl apply -f testapp.yaml
复制代码
这时候就有3个pod了 可以使用 kubectl get pod -o wide
查看pod详细信息,主要是看下IP:
kubectl get pod -o wide
复制代码
登录其中一个pod访问另一个pod试试(这里是进入第一个pod访问第二个pod):
kubectl exec -it test-k8s-68b9f5c6c7-hn25x -- bash
curl 10.244.1.173:8080
复制代码
效果如图: 可以看到输出了正确的pod得名称
但是这时候只能在pod之前进行互相访问,上篇文章有说pod可以一个单独的物理机,共用一个网络,要供集群外访问就要新建一个另外的资源,下面接着说。
新建service资源控制器
yaml文件
service的特性:
- Service 通过 label 关联对应的 Pod
- Servcie 生命周期不跟 Pod 绑定,不会因为 Pod 重创改变 IP
- 提供了负载均衡功能,自动转发流量到不同 Pod
- 可对集群外部提供访问端口
- 集群内部可通过服务名字访问
所有的资源都是通过yaml文件描述,写一个描述servie的yaml文件,文件名为service.yaml
apiVersion: v1
kind: Service
metadata:
name: test-k8s
spec:
selector:
app: test-k8s
type: NodePort
ports:
- port: 8080 # 本 Service 的端口,内部访问
targetPort: 8080 # 容器端口,也就是test-k8s这个应用的
nodePort: 31000 #暴露出集群的端口
复制代码
值得说的是service这个资源控制的中type
这个关键字类型,这里指定的是NodePort
类型,在每个Node上开放一个端口,可以访问,如果不指定这个type,默认的类型就是ClusterIp
,这个就是不允许集群外访问的,只允许集群内部访问,其他还有LoadBalance
类型,负载均衡的意思,一般是云厂商提供的这个资源类型,不常见。
还要注意NodePort暴露的端口固定范围为: 30000-32767
应用Service:
和应用Deployment一样:
kubectl apply -f service.yaml
复制代码
查看k8s中Service资源
kubectl get svc
复制代码
测试效果
这个机器的内网IP为192.168.2.187,刚才设置的端口为31000
动态扩缩容
安装资源指标查看工具
使用动态扩缩容之前需要安装一个资源指标获取工具,用来监控集Node,Pod资源占用CPU,运行内存情况,名为metrics-server
,集群默认不会安装这个,安装十分简单,在官方的GitHub下载安装:
wget <https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml>
kubectl apply -f components.yaml
复制代码
后面出错了,其相关pod不能启动,需要替换yaml文件内的一段内容,替换成如下,具体原因不清楚:
接下里就可以使用top
命令查看pod和node CPU和运行内存资源占用情况
安装水平自动伸缩服务
控制pod的动态扩缩容又是一个资源控制器,叫HorizontalPodAutoscaler
,字面意思是水平自动伸缩,跟service.yaml一样简单,文件名:hpa.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
namespace: default
name: test-k8s-scaler
labels:
app: test-k8s-scaler
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: test-k8s
minReplicas: 2
maxReplicas: 100
targetCPUUtilizationPercentage: 45
复制代码
水平自動スケーリングコントローラーのメタデータのデータは、コントローラーの基本情報を表します。spacのデータは、scaleTargetRef
監視するリソースminReplicas
の指定、レプリカの最小数のmaxReplicas
指定、およびレプリカの数の指定に使用されます。この最小値レプリカの数は、レプリカの初期定義を上書きします。数量、targetCPUUtilizationPercentage
スケーリングがトリガーされたときのCPUインジケーターを指定し、k8sには複雑なアルゴリズムがあり(「Kubernetesin Action」の本で簡単に説明されています)、これらのポッドのリソース使用量を監視します。一定の間隔で自動的に調整します。ここでは、ポッドのCPU使用率が45%を超えている限り、拡張戦略がトリガーされて拡張がトリガーされ、他のインジケーターを監視用に指定できますが、通常はCPUと実行中のメモリです。
kubectl apply -f hpa.yaml
この自動スケーリングコントローラーを使用してインストールします
kubectl get hpa
この水平自動スケーリングコントローラーの基本的な状態は、次を使用して表示することもできます。
ABストレステストによる自動スケーリング
ダウンロードアドレスWindowsに直接ダウンロードして解凍し、binディレクトリに入力して次のコマンドを実行します。
./ab.exe -n 10000 -c 100 http://192.168.2.181:31000/
复制代码
これは、合計1wのリクエスト、100のスレッドのリクエストと実行を同時に行うことwatch kubectl get hpa,pod
、自動スケーリングのリアルタイムモニタリング、およびポッド数の詳細なパラメータを意味します。
リクエストが完了してから数分後、ポッドの数は2に戻り、この時点ですべてのテストが完了します。
要約する
デモアプリケーションはクラスターにデプロイできます。プロセス全体は複雑ではなく、複雑な脳を燃やす機能もありません。K8sの水平方向の拡大と縮小は私にとって最も魅力的な場所なので、アプリケーションが正常にデプロイされた後、最初のステップはこれを達成することです。関数の準備ができたら、Gitlabを使用して実際のCI/CD用のアプリケーションを自動的にデプロイします。コマンドを手動で入力する必要はありません。コードを送信してブランチをマージしてトリガーしますデプロイメントコマンド、またはそれを使用するための実際のサービスを提供できる他のアプリケーションをインストールしてみてください。実際に機能します。ここをご覧いただきありがとうございます。