【Kubernetes】k8s的安全管理详细说明【SA配置、k8s安装dashboard、资源限制（resource、limit、resourcequota）】
文章目录环境准备token验证&&kubeconfig验证role和clusterrole赋权sa【Service Account】sa总结1、service account到底是什么？2、在k8s集群中为什么需要service account？3、创建出来的sa可以直接就使用吗？4、sa有意义了，我们怎样去使用它？查看sa创建sa【secret】给sa授权使用sa安装dashbo
·
环境准备
- 首先需要有一套完整的集群
[root@master ~]# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
master Ready master 114d v1.21.0 192.168.59.142 <none> CentOS Linux 7 (Core) 3.10.0-957.el7.x86_64 docker://20.10.7
node1 Ready <none> 114d v1.21.0 192.168.59.143 <none> CentOS Linux 7 (Core) 3.10.0-957.el7.x86_64 docker://20.10.7
node2 Ready <none> 114d v1.21.0 192.168.59.144 <none> CentOS Linux 7 (Core) 3.10.0-957.el7.x86_64 docker://20.10.7
[root@master ~]#
[root@master ~]# kubectl cluster-info
Kubernetes control plane is running at https://192.168.59.142:6443
CoreDNS is running at https://192.168.59.142:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://192.168.59.142:6443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
[root@master ~]#
- 然后单独准备一台同网段的虚机用来当客户端使用
[root@master2 ~]# ip a | grep 59
inet 192.168.59.151/24 brd 192.168.59.255 scope global noprefixroute ens33
[root@master2 ~]#
# 安装命令
[root@master2 ~]#yum install -y kubelet-1.21.0-0 --disableexcludes=kubernetes
#--disableexcludes=kubernetes 禁掉除了这个之外的别的仓库
# 启动服务
[root@master2 ~]#systemctl enable kubelet && systemctl start kubelet
#让其kubectl能使用tab
[root@master2 ~]# head -n3 /etc/profile
# /etc/profile
source <(kubectl completion bash)
[root@master2 ~]#
# 现在呢是没有集群信息的，报错内容可能会有不一样
[root@master2 ~]# kubectl get nodes
No resources found
[root@master2 ~]#
token验证&&kubeconfig验证
内容过多，分开发布，token验证&&kubeconfig验证去这篇博客：
【Kubernetes】k8s的安全管理详细说明【k8s框架说明、token验证和kubeconfig验证详细说明】
role和clusterrole赋权
内容过多，分开发布，token验证&&kubeconfig验证去这篇博客：
【Kubernetes】k8s的安全管理详细说明【role赋权和clusterrole赋权详细配置说明】
sa【Service Account】
sa总结
1、service account到底是什么？
- 在k8s中，service account是给集群中的进程使用的，当集群中的pod/进程需要跟apiserver申请调用资源时使用时使用的；我们用户是不会去使用它的；举个很形象的例子，就像nginx服务中的nginx账号一样，我们一般是不会使用su去登录它并且使用它的；如下，就能很直观的明白了：
# For more information on configuration, see:
# * Official English Documentation: http://nginx.org/en/docs/
# * Official Russian Documentation: http://nginx.org/ru/docs/
user nginx; #这里这个账户就叫nginx，就是给nginx这个进程、服务使用的
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
- 但是不同的是，linux中的nginx服务，我们使用yum -y install下载nginx服务时，系统会默认帮我们创建一个叫做nginx的账户；
- 但是在k8s中，任何进程任何pod在被创建出来的同时，如果我们不指定使用自己创建的service account的话，系统会默认给我们使用default账户去创建资源
2、在k8s集群中为什么需要service account？
- 原因很简单，在创建新的资源的同时，限制它们的权限；
- 因为在我们创建新的资源时，如果不指定使用哪个sa去创建的话，默认就是使用default服务账户，但是default这个服务账号权限特别大，任何操作都能执行，在公司中我们是不允许这样的事情发生的；主要的原因就是为了保护资源，防止误删
- 所以这个时候我们就需要用到service account了，对资源限制权限，给它我们想给的权限，这样就能有效的保护好我们资源
3、创建出来的sa可以直接就使用吗？
-
但是一个sa创建出来了有什么用呢？这个问题值得深思
-
在任何地方一个账号创建出来了，单单从账号本身是没有任何意义的；就像我们去银行开银行卡需要开户一样的，虽然说银行都是有vip和普通用户的，但是单纯的只看账号的话，账号就是一长串的数字而已；在k8s中也是一样的，如果单单只看sa这个账户的话，一个sa被创建出来了，并没有很大的意义的。
-
回归到生活中，为什么银行里面有vip会员，还有更多的普通账户呢？那是因为他们在账户的钱多，钱多了也就变成vip了；那么这跟我们k8s中的sa又有什么关系呢？答案是：有关系的。
-
在k8s集群中的sa，也是需要“充钱”进去才能变成“vip”的，这里面的”钱“，就是我们在集群中所说的角色role了，创建一个角色，赋予它一定的权限；但是我们需要将它跟我们所创建出来的角色绑定在一起，那这个sa就会变成”vip“了，那么这个sa的意义就有了。
4、sa有意义了，我们怎样去使用它？
- 现在是万事俱备只欠东风了，账号有了，权限也有了，那么我们怎样去使用它呢？
- 很简单，只要我们在创建新资源的时候（比如说pod、deployment），在yaml文件中指定使用你想指定的sa账户，就可以了；
- 指定了服务账户之后，我们把pod创建出来了，我们在使用这个pod时，这个pod就有了我们指定的账户的权限了，这样就能达到我们在公司中的需求了。
查看sa
- sa一般和secret对应存在【而sa好像是在启用token的时候就默认存在一个default的了】
[root@master sefe]# kubectl get sa
NAME SECRETS AGE
default 1 2d23h
[root@master sefe]# kubectl get secret
NAME TYPE DATA AGE
default-token-6l8sp kubernetes.io/service-account-token 3 2d23h
[root@master sefe]#
创建sa【secret】
- 前面说过，sa和secret成对存在的，我们创建sa的时候就会自动生成一个secret，而后面，我们也是编辑secret罢了
- 先创建一个sa1 吧
[root@master sefe]# kubectl create sa sa1
serviceaccount/sa1 created
[root@master sefe]# kubectl get sa
NAME SECRETS AGE
default 1 2d23h
sa1 1 4s
[root@master sefe]#
[root@master sefe]# kubectl get secret
NAME TYPE DATA AGE
default-token-6l8sp kubernetes.io/service-account-token 3 2d23h
sa1-token-xg5c9 kubernetes.io/service-account-token 3 12s
[root@master sefe]#
- 上面可以看到自动生成了一个secret
而这个secret呢其实是有一个token秘钥的，这个作用继续往下看，后面就知道了
[root@master sefe]# kubectl describe secrets sa1-token-xg5c9
Name: sa1-token-xg5c9
Namespace: safe
Labels: <none>
Annotations: kubernetes.io/service-account.name: sa1
kubernetes.io/service-account.uid: 4ad27b03-f0af-4c88-8c80-0eb109ff15d2
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1066 bytes
namespace: 4 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IlM4MTVVSE5kXzVhZXdMaVN2VDBNcDdvdXV4S25aSmJ0aDVFV3Vhc2FFVVkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJzYWZlIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhMS10b2tlbi14ZzVjOSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJzYTEiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI0YWQyN2IwMy1mMGFmLTRjODgtOGM4MC0wZWIxMDlmZjE1ZDIiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6c2FmZTpzYTEifQ.IxLPLq3_izwtCL2wANNQlIYCQtG5NvtR73GKJ_rh71mW6QJxyI0XiMyfbsMBlfnN_66EIqRSmFxzD-P_vsEiw9mgBa2-j_D5sdq-p2n8eehNGMlnoXDmZZvR1oGHfrErDtUMMFbSlsWEjY65KCByjumvTNf73TIC5PCzuUnRmHxKx3leZ_jWNMchSMqtgyRqv9uuXK6lRc9prxGmiBu4SLeYMepQXWXFknY-4fvQxx3zCnaGtMCdX8NYsICIQhtI_8c6C_hivSvib2z3SJJ0FGEvnHJMntcXh11qXyTxg8MuJ5ro0M4yR_RvBMj1qDPkwevj7r_uiT5wJFS4h6jUrQ
[root@master sefe]#
给sa授权
- 语法：
kubectl create clusterrolebinding 自定义名称 --clusterrole=cluster-admin【admin权限，也可以自定义clusterrole】 --serviceaccount=命名空间:sa名称 - 给sa授权呢，其实和clusterrole授权是一样的。
如下：我们创建一个cbindx的clusterrole，并且直接给admin权限，作用是对 上面创建的sa1授权
[root@master sefe]# kubectl create clusterrolebinding cbindx --clusterrole=cluster-admin --serviceaccount=safe:sa1
clusterrolebinding.rbac.authorization.k8s.io/cbindx created
[root@master sefe]#
[root@master sefe]# kubectl get clusterrolebindings.rbac.authorization.k8s.io cbindx
NAME ROLE AGE
cbindx ClusterRole/cluster-admin 25s
[root@master sefe]#
使用sa
- 上面说过，sa其实是对pod做限制的，所以我们上面创建好sa和授权完毕以后，我们只要在pod文件中增加一行
serviceAccount: sa_name即可 - 如：我给这个pod使用sa的权限，然后创建
[root@master sefe]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod1
name: pod1
spec:
#nodeName: node2
nodeSelector:
ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod1
resources: {}
serviceAccount: sa1
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]#
[root@master sefe]# cat -n pod1.yaml | grep service
18 serviceAccount: sa1
[root@master sefe]#
# 创建
[root@master sefe]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@master sefe]#
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod1 1/1 Running 0 3s
[root@master sefe]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod1 1/1 Running 0 12s 10.244.104.41 node2 <none> <none>
[root@master sefe]#
# 这里面也可以看到已经使用sa创建该pod了
[root@master sefe]# kubectl edit pod pod1
43 serviceAccount: sa1
44 serviceAccountName: sa1
- 为什么我们说使用sa创建的pod，该pod中的权限是和sa绑定的呢，我们进入容器就可以看到上传创建sa后的secret中的token了
注：下面中的token和我们 在上面创建中看到的token不一致，是正常的
root@pod1:/# df | grep servic
tmpfs 16380928 12 16380916 1% /run/secrets/kubernetes.io/serviceaccount
root@pod1:/# cd /run/secrets/kubernetes.io/serviceaccount
root@pod1:/run/secrets/kubernetes.io/serviceaccount# ls
ca.crt namespace token
root@pod1:/run/secrets/kubernetes.io/serviceaccount# cat token
eyJhbGciOiJSUzI1NiIsImtpZCI6IlM4MTVVSE5kXzVhZXdMaVN2VDBNcDdvdXV4S25aSmJ0aDVFV3Vhc2FFVVkifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjY3NzE5NjU5LCJpYXQiOjE2MzYxODM2NTksImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJzYWZlIiwicG9kIjp7Im5hbWUiOiJwb2QxIiwidWlkIjoiNTVmNjQzNWMtMDYwYy00OGU2LTllZTYtYzk3OTQwZjA2N2IxIn0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJzYTEiLCJ1aWQiOiI0YWQyN2IwMy1mMGFmLTRjODgtOGM4MC0wZWIxMDlmZjE1ZDIifSwid2FybmFmdGVyIjoxNjM2MTg3MjY2fSwibmJmIjoxNjM2MTgzNjU5LCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6c2FmZTpzYTEifQ.DnxdMJrGChaccCUvfQVx2bPP1hOu044eTGNZ2l6BjrwAotbhRr2WlXdJOYTE9ArDD8EuaymQttzJOtvsUSIqI99ZcBjUfwkGWlK8dhJOI-DZ4SWHjax_U-5tuKSZb-JpyXySGfEKzhenCX7Jv8vXJ81LIOm0HOHxLiSx4Y4jYjzbXcHoR8BFtfLAA0NftvkNwgGQ8JdLwerfiNsw3H0EbCUpYVRZagDPCOGFNs_d8bjPKSRy9WQzCr6IEECAeONDaPK1ufUO13KLjddgDvBHGnFZ6OfEZzkQWbnkt-Urb33bH8Du0So0EsX4DfYb5P-Yn-0UJm89x25xK3qgQTfiGwroot@pod1:/run/secrets/kubernetes.io/serviceaccount#
- 这么做 的意义是就是，如果sa给的权限很少，那么这个pod中的功能也就会被限制。
安装dashboard
说明
-
Dashboard 是基于网页的 Kubernetes 用户界面。 你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。 你可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源 （如 Deployment，Job，DaemonSet 等等）。 例如，你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。
-
Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。
镜像和dashboard的yaml文件获取
-
这是我自己下载的文件，包含下面所有用到的yaml文件和镜像【也可以继续往下看，自己下载的哈】
k8s-dashboard镜像和yaml文件.rar
-
dashboard的yaml文件我们可以去官网获取最新的，也可以看看官方的介绍，不管yaml文件是不是最新的，下面的方法都是一样的哈
部署 Dashboard UI
官网里面呢，有一个网址，这个就是dashboard的获取地址了，反正地址就是这个，可以在windows上直接打开，然后复制到虚拟机里面，也可以在linux里面wget或curl【但是这个网站是国外的，需要添加解析，有点难访问，而且解析并不是配置后一直能用，这个破网址就折腾了我一上午，艹】
#这个yaml文件呢有306行，这里面集成了dashboard的所有内容，包含ns这些
[root@master sefe]# cat dashboard.yaml | wc -l
306
[root@master sefe]#
- 需要用到2个镜像，可以自己docker pull 也可以打包我上传的。
这个版本不是最新的【可以继续用这个，也可以去找最新的】
[root@ccx ~]# docker pull registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
v1.0.1: Pulling from kube-iamges/metrics-scraper
4689bc3c8a60: Pull complete
d6f7da934d73: Pull complete
ee60d0f2a8a1: Pull complete
Digest: sha256:3b1cb436dbc2c02aabd7d29e3d9b3f8b4dfc1eb50dbcc63640213ef1139235dd
Status: Downloaded newer image for registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
[root@ccx ~]#
[root@ccx ~]# docker pull kubernetesui/dashboard:v2.0.0-beta8
v2.0.0-beta8: Pulling from kubernetesui/dashboard
5cd0d71945f0: Pull complete
Digest: sha256:fc90baec4fb62b809051a3227e71266c0427240685139bbd5673282715924ea7
Status: Downloaded newer image for kubernetesui/dashboard:v2.0.0-beta8
docker.io/kubernetesui/dashboard:v2.0.0-beta8
[root@ccx ~]#
- 上面2个镜像弄完以后呢，需要导入到所有node节点
因为我的集群是没有外网的，所以我在上面有外网的机器上docker pull以后，上传到我服务器的，如果你是下载的我的镜像，你也需要这么做。
#拷贝到所有node节点
[root@master sefe]# scp dashboard* node1:~
root@node1's password:
dashboard-metrics_v1.0.1.tar 100% 38MB 19.1MB/s 00:02
dashboard_v2.0.0.tar 100% 87MB 18.3MB/s 00:04
dashboard.yaml 100% 7807 2.7MB/s 00:00
[root@master sefe]# scp dashboard* node2:~
root@node2's password:
dashboard-metrics_v1.0.1.tar 100% 38MB 20.5MB/s 00:01
dashboard_v2.0.0.tar 100% 87MB 19.8MB/s 00:04
dashboard.yaml 100% 7807 2.6MB/s 00:00
[root@master sefe]#
# node1解压镜像
[root@node1 ~]# docker load -i dashboard
dashboard-metrics_v1.0.1.tar dashboard_v2.0.0.tar dashboard.yaml
[root@node1 ~]# docker load -i dashboard_v2.0.0.tar
954115f32d73: Loading layer 91.22MB/91.22MB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/dashboard:v2.0.0-beta8
[root@node1 ~]# docker load -i dashboard-metrics_v1.0.1.tar
89ac18ee460b: Loading layer 238.6kB/238.6kB
878c5d3194b0: Loading layer 39.87MB/39.87MB
1dc71700363a: Loading layer 2.048kB/2.048kB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
[root@node1 ~]#
# node2解压镜像
[root@node2 ~]# docker load -i dashboard-metrics_v1.0.1.tar
89ac18ee460b: Loading layer 238.6kB/238.6kB
878c5d3194b0: Loading layer 39.87MB/39.87MB
1dc71700363a: Loading layer 2.048kB/2.048kB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
[root@node2 ~]# docker load -i dashboard_v2.0.0.tar
954115f32d73: Loading layer 91.22MB/91.22MB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/dashboard:v2.0.0-beta8
[root@node2 ~]#
dashboard配置测试
yaml文件编辑
- 这主要修改imges相关的内容【NodePort后面用另外一种方式修改】
- 1、修改镜像名称，用我们上面下载的2个镜像名称
- 2、修改imagePullPolicy策略为本地获取，第二个imagePullPolicy是手动增加的
[root@master sefe]# grep image dashboard.yaml
image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/dashboard:v2.0.0-beta8
#image: kubernetesui/dashboard:v2.2.0
#imagePullPolicy: Always
imagePullPolicy: IfNotPresent
#image: kubernetesui/metrics-scraper:v1.0.6
image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
imagePullPolicy: IfNotPresent
[root@master sefe]#
生成dashboard的pod
- 生成yaml文件和查看该pod【状态需要为running为正常】
[root@master sefe]# kubectl apply -f dashboard.yaml
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created
[root@master sefe]#
[root@master sefe]# kubectl get pods -n kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
dashboard-metrics-scraper-684f96bd4-bhq4c 1/1 Running 0 66s
kubernetes-dashboard-5d66bcd8fd-hbqhw 1/1 Running 0 66s
[root@master sefe]#
- 前面说过这个会自动生成一个ns空间，所以我们现在查看这个ns下的所有pod
[root@master sefe]# kubectl get all -n kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
pod/dashboard-metrics-scraper-684f96bd4-bhq4c 1/1 Running 0 17s
pod/kubernetes-dashboard-5d66bcd8fd-hbqhw 1/1 Running 0 17s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/dashboard-metrics-scraper ClusterIP 10.101.25.25 <none> 8000/TCP 17s
service/kubernetes-dashboard ClusterIP 10.107.102.121 <none> 443/TCP 17s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/dashboard-metrics-scraper 1/1 1 1 17s
deployment.apps/kubernetes-dashboard 1/1 1 1 17s
NAME DESIRED CURRENT READY AGE
replicaset.apps/dashboard-metrics-scraper-684f96bd4 1 1 1 17s
replicaset.apps/kubernetes-dashboard-5d66bcd8fd 1 1 1 17s
[root@master sefe]#
修改dashboard的svc类型并测试
- 修改前呢是
ClusterIP，现在我们要将这个修改为NodePort
#首先需要查看dashboard的名称
[root@master sefe]# kubectl get svc -n kubernetes-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dashboard-metrics-scraper ClusterIP 10.101.25.25 <none> 8000/TCP 2m59s
kubernetes-dashboard ClusterIP 10.107.102.121 <none> 443/TCP 2m59s
# 然后编辑这个名称，注意，这是在下面固定的命名空间下的
[root@master sefe]# kubectl edit svc kubernetes-dashboard -n kubernetes-dashboard
#修改下面这一行内容，然后wq保存退出
...
type: NodePort #修改这行为这个内容【倒数第三行】
status:
loadBalancer: {}
~
:wq
[root@master sefe]#
# 修改完毕以后呢，就可以看到PORT中的dashboard多了一个TCP端口号了，如这31526
[root@master sefe]# kubectl get svc -n kubernetes-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dashboard-metrics-scraper ClusterIP 10.101.25.25 <none> 8000/TCP 5m54s
kubernetes-dashboard NodePort 10.107.102.121 <none> 443:31526/TCP 5m54s
- 然后
crul -k https://master主机ip:svc端口测试看是否有内容【有内容为正常】
[root@master sefe]# curl -k https://192.168.59.142:31526
<!--
Copyright 2017 The Kubernetes Authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Kubernetes Dashboard</title>
<link rel="icon"
type="image/png"
href="assets/images/kubernetes-logo.png" />
<meta name="viewport"
content="width=device-width">
<link rel="stylesheet" href="styles.dd2d1d3576191b87904a.css"></head>
<body>
<kd-root></kd-root>
<script src="runtime.380dd4d7ab4891f91b7b.js" defer></script><script src="polyfills-es5.65f1e5151c840cf04c3e.js" nomodule defer></script><script src="polyfills.8623bbc9d68876cdaaaf.js" defer></script><script src="scripts.7d5e232ea538f2c0f8a7.js" defer></script><script src="main.3036e86b43f81b098e24.js" defer></script></body>
</html>
[root@master sefe]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
[root@master sefe]#
- 并且此时呢，我们就可以t通过
https://master主机ip:svc端口在浏览器中访问dashboard了【第一次访问需要接收并添加列外】
使用token登录，token获取继续往下看
访问报错Internet Explorer增强安全配置。。。
- 报错内容如下
我这系统是server2012，普通windows可能没有这种报错。。。反正有的话这么处理就是了
- 处理方法
打开服务器管理器，点击本地服务器，可以看到IE增强安全配置是启用状态，点击将IE增强安全配置修改为禁用状态，再重新打开IE浏览器，可以正常访问网页，不再弹出该弹窗。
端口通但浏览器无法访问
- 如下，dashboard映射的端口通，但浏览器就是无法访问【此时linux中是可以正常访问的】
- 原因和解决方法
- 原因是：使用的浏览器是IE内核，这玩意不支持IE内核
- 解决方法：换firefox浏览器即可【火狐浏览器】
查看token值并登陆
- 上面我们网址登录的时候看到了可以选择token登陆
现在我们查看token
之前我们说过每当创建一个sa就会自动生成一个secrets，而token是记录在secrets中的。
#先查看secrets
[root@master sefe]# kubectl get secrets -n kubernetes-dashboard
NAME TYPE DATA AGE
default-token-4pqr6 kubernetes.io/service-account-token 3 129m
kubernetes-dashboard-certs Opaque 0 129m
kubernetes-dashboard-csrf Opaque 1 129m
kubernetes-dashboard-key-holder Opaque 2 129m
kubernetes-dashboard-token-6bnkg kubernetes.io/service-account-token 3 129m
[root@master sefe]#
[root@master sefe]# kubectl get sa -n kubernetes-dashboard
NAME SECRETS AGE
default 1 130m
kubernetes-dashboard 1 130m
[root@master sefe]#
# sa对应的token格式呢是：xx-token-xx
#我们现在查看这个secrets的详细即可看到token内容
[root@master sefe]# kubectl describe kubernetes-dashboard-token-6bnkg -n kubernetes-dashboard
error: the server doesn't have a resource type "kubernetes-dashboard-token-6bnkg"
[root@master sefe]# kubectl describe secrets kubernetes-dashboard-token-6bnkg -n kubernetes-dashboard
Name: kubernetes-dashboard-token-6bnkg
Namespace: kubernetes-dashboard
Labels: <none>
Annotations: kubernetes.io/service-account.name: kubernetes-dashboard
kubernetes.io/service-account.uid: b9f8b781-3eb6-47e6-a6cb-ff5cb4372683
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1066 bytes
namespace: 20 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IlM4MTVVSE5kXzVhZXdMaVN2VDBNcDdvdXV4S25aSmJ0aDVFV3Vhc2FFVVkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZC10b2tlbi02Ym5rZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImI5ZjhiNzgxLTNlYjYtNDdlNi1hNmNiLWZmNWNiNDM3MjY4MyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlcm5ldGVzLWRhc2hib2FyZDprdWJlcm5ldGVzLWRhc2hib2FyZCJ9.tQ-_K-rsXRNIbHJRff0XiEVD9sr7qi_hEFTTgeaD0D8iLzELCDVqiDoVp95SHQyUi3-kbestzxm5C-djUd45loJpZNId3jpmNhW5sKQ4nrxqmT575SDoQSm98_3nAw0r80iuFfxJhA0puH6hltZzf4yTN6cJKetEiwkFmFOi7UWQMfNoJREppdaMFUK96O_SIEHvIHsHl2qcvw5ZttFHcE2w5FVOPYbB0JIoWxyRAZGonyshraYrPGnKwfkUTn18UYlHksP8oJEhT2Y05X9wlp-H0n-0GEjdcFl03ov3WrXxdhgBhJhPq62fztRC6S2voyjHuD-JbvGdLNtpX7QFGA
[root@master sefe]#
- 复制这个token值，然后复制到浏览器中【很长，注意要复制完】
- 现在登陆进去以后呢，是没有内容的，而且一直有警告，是正常的，因为没有给sa授权
SA授权并验证
- 先授权吧
#dashboard自定义名称
#cluster-admin给admin权限
#kubernetes-dashboard:kubernetes-dashboard两个都是sa名称【中间有冒号】
[root@master sefe]# kubectl create clusterrolebinding dashboard --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:kubernetes-dashboard
clusterrolebinding.rbac.authorization.k8s.io/dashboard created
[root@master sefe]#
[root@master sefe]# kubectl describe clusterrolebindings.rbac.authorization.k8s.io dashboard
Name: dashboard
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: cluster-admin
Subjects:
Kind Name Namespace
---- ---- ---------
ServiceAccount kubernetes-dashboard kubernetes-dashboard
[root@master sefe]#
- 现在我们刷新浏览器，就可以看到dashboard已经有内容并且告警也没有 了
至此dashboard就配置完了，dashboard的功能其实挺多的，连集群的使用率都能看到，更多功能自行摸索吧。。。
资源限制
测试说明【含释放缓存内存方法】
- 我们用cenos镜像来做测试吧，然后准备一个内存消耗的文件【脚本也行，可以自行随便准备一个】
#node节点有centos
[root@node2 ~]# docker images | grep cen
hub.c.163.com/library/centos latest 328edcd84f1b 4 years ago 193MB
[root@node2 ~]#
# 内存消耗rpm包
[root@master sefe]# ls | grep mem
memload-7.0-1.r29766.x86_64.rpm
[root@master sefe]#
- 测试资源限制前呢，我们先来看看资源没有被限制的时候是什么样子的【条件不方便呢也可以不用做这些测试，比较这个呢，是比较简单直观的东西，不想弄可以不弄，看看我弄的过程就行了，应该很好理解的，而且这个代码也就那么点，真实环境限制也不容易出错。】
#有pod，先删了吧
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod1 1/1 Running 0 41m
[root@master sefe]# kubectl delete pod pod1
pod "pod1" deleted
[root@master sefe]#
# 我们用centos镜像来做测试，如下，创建好pod并安装好内存消耗的包
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
#nodeName: node2
#nodeSelector:
# ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: hub.c.163.com/library/centos
command: ["sh","-c","sleep 1000000"]
imagePullPolicy: IfNotPresent
name: pod2
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]#
[root@master sefe]# kubectl apply -f pod2.yaml
pod/pod2 created
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 1/1 Running 0 5s
[root@master sefe]#
[root@master sefe]# kubectl cp memload-7.0-1.r29766.x86_64.rpm pod2:/opt
[root@master sefe]# kubextl exec -it pod2 -- bash
bash: kubextl: command not found...
[root@master sefe]# kubectl exec -it pod2 -- bash
[root@pod2 /]# ls /opt
memload-7.0-1.r29766.x86_64.rpm
[root@pod2 /]# rpm -ivh /opt/memload-7.0-1.r29766.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:memload-7.0-1.r29766 ################################# [100%]
[root@pod2 /]#
- 基本环境弄好了，我们现在开始消耗内存看看
我下面是在多个窗口中，注意看主机名 的变化
# 这个pod是在node2上
[root@master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod2 1/1 Running 0 7m18s 10.244.104.42 node2 <none> <none>
[root@master ~]#
# 可以看到node2现在消耗了1G内存
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 28 0 1 29
Swap: 0 0 0
[root@node2 ~]#
#现在回到容器内部开始占用内容，因为我这虚机是32G内存，所以我占用多一点吧
#容器中占用了10G
[root@pod2 /]# memload 10240
Attempting to allocate 10240 Mebibytes of resident memory...
# 回到node2，可以看到10G确实可以被占用的
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 28 0 1 29
Swap: 0 0 0
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 4 24 0 1 25
Swap: 0 0 0
[root@node2 ~]#
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 7 22 0 1 23
Swap: 0 0 0
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 8 21 0 1 22
Swap: 0 0 0
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 11 18 0 1 19
Swap: 0 0 0
[root@node2 ~]#
- 上面呢是可以正常释放的，现在我们释放掉占用的这10G
#容器ctrl+c即可释放
[root@pod2 /]# memload 10240
Attempting to allocate 10240 Mebibytes of resident memory...
Allocated 10000 pages
^C
[root@pod2 /]#
# 回到node2看是否已经被释放，然后再释放下缓存内存
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 28 0 1 29
Swap: 0 0 0
[root@node2 ~]# echo 3 > /proc/sys/vm/drop_caches
[root@node2 ~]#
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 29 0 0 29
Swap: 0 0 0
[root@node2 ~]#
- 支持资源占用测试呢，就完了反正是没有限制的时候想弄多少弄多少
现在，我们吧这pod删了吧。
[root@pod2 /]# exit
exit
command terminated with exit code 130
[root@master sefe]# kubectl delete pod pod2
pod "pod2" deleted
[root@master sefe]#
yaml文件中限制【resource字段限制】
作用： 用来限制每个pod的资源
代码参数说明
- 就不多累赘了，反正资源限制就是这个字面意思，应该很好理解，而这个也不过是实现限制的一种方式罢了，所以没有必要过于深究原理，直接说操作吧。
- 我放一段代码吧，在代码中做参数说明应该更容易理解一点
为了看着方便，我删了其他自动内容，只保留resource部分
#没有资源限制的时候呢，是这样子的
resources: {}
#限制以后呢，｛｝没了，成下面样子了
#内存可以cpu都是可以选的，可以单独存在，也可以同时存在
resources:
requests: # ---容器所在节点 资源的最小值
memory: "256Mi" #内存限制，单位是M【G的单位是Gi】
cpu: "500m" #cpu限制，单位是微核心【下面会单独对微核心做说明】
limits: # ---容器消耗资源最大值
memory: "512Mi"#内存限制，单位是M【G的单位是Gi】
cpu: "1000m"#cpu限制，单位是微核心【下面会单独对微核心做说明】
- 微核心说明：
在kubernetets系统上，1个单位的CPU相当于虚拟机上的一颗虚拟CPU（vCPU）或者物理机上的一个超线（HyperThread，或者称一个逻辑CPU），它支持分数计量方式，一个核心（1 core）相当于1000个微核心（millicores），因此500m相当于是0.5个核心，即二分之一个核心。
测试说明【内存】
最小值限制
- 这个最小值呢存在一个逻辑问题，就是说如果设置的最小值大于了能部署的node节点内存，那么该pod就不会被创建成功，状态会一直处于pending状态
如，我现在的内存是32G，我现在指定最小内存100G创建pod试试
# 前面说过，这些限制是可以单独存在的，所以我这只限制最低内存
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
#nodeName: node2
#nodeSelector:
# ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: hub.c.163.com/library/centos
command: ["sh","-c","sleep 1000000"]
imagePullPolicy: IfNotPresent
name: pod2
resources:
requests:
memory: 100Gi
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]#
[root@master sefe]# kubectl apply -f pod2.yaml
pod/pod2 created
[root@master sefe]#
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 0/1 Pending 0 3s
[root@master sefe]#
[root@master sefe]# kubectl delete pod pod2
pod "pod2" deleted
[root@master sefe]#
最大值限制
- 现在呢，我限制内存的最大值为5G，也就是说，该pod最多能使用5G内存
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
#nodeName: node2
#nodeSelector:
# ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: hub.c.163.com/library/centos
command: ["sh","-c","sleep 1000000"]
imagePullPolicy: IfNotPresent
name: pod2
resources:
requests:
memory: 1Gi
cpu: 100m
limits:
memory: 5Gi
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]# kubectl apply -f pod2.yaml
pod/pod2 created
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 0/1 ContainerCreating 0 3s
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 1/1 Running 0 5s
[root@master sefe]#
[root@master ~]# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod2 1/1 Running 0 3m3s 10.244.104.19 node2 <none> <none>
[root@master ~]#
- 现在测试看是否真是这样
[root@master sefe]# kubectl cp memload-7.0-1.r29766.x86_64.rpm pod2:/opt
[root@master sefe]# kubectl exec -it pod2 -- bash
[root@pod2 /]# rpm -ivh /opt/memload-7.0-1.r29766.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:memload-7.0-1.r29766 ################################# [100%]
[root@pod2 /]#
# 先占用2G，没问题
[root@pod2 /]# memload 2048
Attempting to allocate 2048 Mebibytes of resident memory...
#node2也确实被占用了
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 3 27 0 0 27
Swap: 0 0 0
[root@node2 ~]#
# 现在占用6G试试【会失败，因为最多只能占用5G】
#可以看到被killed了，占用失败，没问题
[root@pod2 /]# memload 6000
Attempting to allocate 6000 Mebibytes of resident memory...
Killed
[root@pod2 /]#
- 正常区间的限制呢，我就不说了，根据实际大小来控制的话，是不会有意外的。
测试说明【cpu】【使用率计算】
- 注意：内存和cpu限制规则和逻辑是完全一样，所以我就不对cpu单独说明了，有不会的看看上面内存方法吧
- 需要注意的就是，占用cpu微核心数量的时候需要简单计算一下【计算微核心的逻辑呢，看完就懂了】
- 因为cpu是微核心为单位，所以呢，我这说明一下为核心的计算吧
[root@master sefe]# lscpu| grep CPU
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 16
On-line CPU(s) list: 0-15
CPU family: 6
Model name: Intel(R) Xeon(R) CPU E7-4820 v3 @ 1.90GHz
CPU MHz: 1895.436
NUMA node0 CPU(s): 0-15
[root@master sefe]#
[root@master sefe]# kubectl top nodes
W1106 16:48:46.634284 47766 top_node.go:119] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master 478m 2% 2048Mi 6%
node1 248m 1% 1265Mi 3%
node2 174m 1% 857Mi 2%
[root@master sefe]#
- 以上面的master为例，总共是16颗cpu，那么总公就有16000m的微核心
所以使用率就是478/16000=0.0298，但是top呢是只显示整数的
LimitRange的方式限制
作用： 用来限制每个pod的资源
一个LimitRange资源对象可以提供的功能
- 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
- 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
- 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
- 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。
LimitRange资源参数使用说明
-
(1) 在LimitRange中，Pod和Container都可以设置
min、max和maxLimitRequestRatio这三个参数
而Container还可以设置defaultRequest和defaultLimit这两个参数，而Pod不可以设置这两个参数。 -
Container下的参数解释【一般使用这个】
min是Pod中所有容器的Requests值的下限max是Pod中所有容器的Limits值的上限defaultRequest是Pod中所有未指定Requests值的容器的默认Requests值defaultLimit是Pod中所有未指定Limits值的容器的默认Limits值maxLimitRequestRatio用于限定Pod中所有容器的Limits值与Requests值得比例上限
-
Pod下得参数解析
min是Pod中所有容器的Requests值的总和下限max是Pod中所有容器得Limits值的总和上限maxLimitRequestRatio用于限定Pod中所有容器的Limits值总和与Requests值总和的比例上限
-
再说一遍，创建的limit是对命名空间生效的【如果不指定ns，则默认当前的ns空间生效】，在创建limit的ns中，所有pod都会应用这个资源限制规则。
创建和查看Limit
- 这个呢，实际上也就是一个yaml文件，格式如下，具体使用呢，可以根据上面的资源参数使用说明中套过来哈，我这只是做一些简单的说明罢了
#最基本的limit文件格式 如下【可以同时存在多样】
#具体怎么使用看需求吧，限制格式看上面资源使用说明
[root@master sefe]# cat limit.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: mem-min-max-demo-lr
#namespace: ns1
spec:
limits:
- max:
memory: 5Gi
min:
memory: 512Mi
type: Container
[root@master sefe]#
# 创建limit
[root@master sefe]# kubectl apply -f limit.yaml
limitrange/mem-min-max-demo-lr created
[root@master sefe]#
# 查看limit
[root@master sefe]# kubectl get -f limit.yaml
NAME CREATED AT
mem-min-max-demo-lr 2021-11-06T09:11:43Z
# 查看limit详情【另一种查看方式】
[root@master sefe]# kubectl describe limits mem-min-max-demo-lr
Name: mem-min-max-demo-lr
Namespace: safe
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container memory 512Mi 5Gi 5Gi 5Gi -
[root@master sefe]#
测试说明【内存】
- 这个因为是定义的规则，所以在当前命名空间中的所有pod都生效，所以就正儿八经的值测试最大值了，最小值如果大于node内存的话，创建pod的状态也会成pending。
[root@master sefe]# cat limit.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: mem-min-max-demo-lr
#namespace: ns1
spec:
limits:
- max:
memory: 5Gi
min:
memory: 512Mi
type: Container
[root@master sefe]#
[root@master sefe]# kubectl apply -f limit.yaml
limitrange/mem-min-max-demo-lr created
[root@master sefe]#
[root@master sefe]# kubectl get limitranges limit.yaml
Error from server (NotFound): limitranges "limit.yaml" not found
[root@master sefe]# kubectl get -f limit.yaml
NAME CREATED AT
mem-min-max-demo-lr 2021-11-06T09:11:43Z
[root@master sefe]# kubectl describe limits mem-min-max-demo-lr
Name: mem-min-max-demo-lr
Namespace: safe
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container memory 512Mi 5Gi 5Gi 5Gi -
[root@master sefe]#
- 如上，我创建了一个最大内存为5G的limit，现在测试是否生效
得从创建pod开始啊，因为定义了limit，所以呢就不需要resource了
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
#nodeName: node2
#nodeSelector:
# ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: hub.c.163.com/library/centos
command: ["sh","-c","sleep 1000000"]
imagePullPolicy: IfNotPresent
name: pod2
resources: {}
# resources:
# requests:
# memory: 1Gi
# cpu: 100m
# limits:
# memory: 5Gi
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]#
[root@master sefe]# kubectl apply -f pod2.yaml
pod/pod2 created
[root@master sefe]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod2 1/1 Running 0 9s 10.244.104.43 node2 <none> <none>
[root@master sefe]#
# 包准备
[root@master sefe]#
[root@master sefe]# kubectl cp memload-7.0-1.r29766.x86_64.rpm pod2:/opt
[root@master sefe]# kubectl exec -it pod2 -- bash
[root@pod2 /]# rpm -ivh /opt/memload-7.0-1.r29766.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:memload-7.0-1.r29766 ################################# [100%]
[root@pod2 /]#
[root@pod2 /]#
#现在限制3G试试，没问题
[root@pod2 /]# memload 3096
Attempting to allocate 3096 Mebibytes of resident memory...
#确实被占用3g
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 4 26 0 0 26
Swap: 0 0 0
[root@node2 ~]#
# 现在现在6G试试，正常会报错【因为定义了最大值为5G】
#和预期一样，该方法限制资源没问题。
[root@pod2 /]# memload 6000
Attempting to allocate 6000 Mebibytes of resident memory...
Killed
[root@pod2 /]#
- 好了，测试就到这吧，具体限制逻辑呢，可以根据自己需求来多做测试，不会有意外的。
测试说明【cpu】【使用率计算】
- 注意：内存和cpu限制规则和逻辑是完全一样，所以我就不对cpu单独说明了，有不会的看看上面内存方法吧
- 需要注意的就是，占用cpu微核心数量的时候需要简单计算一下【计算微核心的逻辑呢，看完就懂了】
- 因为cpu是微核心为单位，所以呢，我这说明一下为核心的计算吧
[root@master sefe]# lscpu| grep CPU
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 16
On-line CPU(s) list: 0-15
CPU family: 6
Model name: Intel(R) Xeon(R) CPU E7-4820 v3 @ 1.90GHz
CPU MHz: 1895.436
NUMA node0 CPU(s): 0-15
[root@master sefe]#
[root@master sefe]# kubectl top nodes
W1106 16:48:46.634284 47766 top_node.go:119] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master 478m 2% 2048Mi 6%
node1 248m 1% 1265Mi 3%
node2 174m 1% 857Mi 2%
[root@master sefe]#
- 以上面的master为例，总共是16颗cpu，那么总公就有16000m的微核心
所以使用率就是478/16000=0.0298，但是top呢是只显示整数的
resource和limit优先级说明
- 如果容器【resource】内没有声明最大值最小值则使用limit设置的
- 如果容器【resource】里声明了请求和限制大于或者小于 limitrange里的max或者min，都会导致pod创建不成功。
- 容器【resource】申请的资源不能超过limit
如下图，应该很好理解吧。
resourcequota配额限制
作用： 用来限制项目里可以使用多少资源
说明
-
Resource Quotas（资源配额，简称quota）是对namespace进行资源配额，限制资源使用的一种策略。 K8S是一个多用户架构，当多用户或者团队共享一个K8S系统时，SA使用quota防止用户（基于namespace的）的资源抢占，定义好资源分配策略。
-
Quota应用在Namespace上，默认情况下，没有Resource Quota的，需要另外创建Quota，并且每个Namespace最多只能有一个Quota对象。
-
使用注意实现
- 在使用前需确认apiserver的配置文件中的KUBE_ADMISSION_CONTROL是否有ResourceQuota，如果没有需要添加并重启apiserver。
- Quota依赖于资源管理器，可以使用资源对象limits或者在创建资源对象是为pod设置资源限制（resources），如果不设置，资源对象无法创建。
- 当该namespace中的任意个额度达到预设Quota时，将无法创建资源对象。
限制参数说明
- ResourceQuota可以限制的配额包括，pod的cpu/内存、pod数量、service数量、rc数量、pvc数量等
#计算资源：
limits.cpu、requests.cpu、limits.memory、requests.memory
#存储资源，包括存储资源的总量以及指定storage class的总量
requests.storage：#存储资源总量，如500Gi
persistentvolumeclaims：#pvc的个数
.storageclass.storage.k8s.io/requests.storage
.storageclass.storage.k8s.io/persistentvolumeclaims
#对象数，即可创建的对象的个数【就是可选参数】
pods,replicationcontrollers,configmaps,secrets，persistentvolumeclaims，services,services.loadbalancers,services.nodeports
创建resourcequota
- 这个创建方式和 limit一样，都是通过yaml文件来创建的
- 现在呢来创建一个最简单的auota【具体的参数看上面限制参数说明】
如：最高只允许当前命名空间创建4个pod和4个svc
注：这个没有最小值的概念，定义的值就是最大值
[root@master sefe]# cat quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
pods: "4"
services: "4"
[root@master sefe]#
[root@master sefe]# kubectl apply -f quota.yaml
resourcequota/compute-resources created
[root@master sefe]#
查看resourcequota和其详情
# 查看详情
[root@master sefe]# kubectl describe -f quota.yaml
Name: compute-resources
Namespace: safe
Resource Used Hard
-------- ---- ----
pods 1 4
services 0 4
# 查看项目【另一种查看方式】
[root@master sefe]# kubectl get -f quota.yaml
NAME AGE REQUEST LIMIT
compute-resources 6m23s pods: 1/4, services: 0/4
[root@master sefe]#
测试
- 上面创建了quota，最大值 创建4个svc，现在测试一下是否对头
[root@master sefe]# kubectl get -f quota.yaml
NAME AGE REQUEST LIMIT
compute-resources 6m23s pods: 1/4, services: 0/4
[root@master sefe]#
[root@master sefe]# kubectl expose --name=svc1 pod pod1 --port=80
Error from server (NotFound): pods "pod1" not found
[root@master sefe]# kubectl expose --name=svc1 pod pod2 --port=80
service/svc1 exposed
[root@master sefe]# kubectl expose --name=svc2 pod pod2 --port=80
service/svc2 exposed
[root@master sefe]# kubectl expose --name=svc3 pod pod2 --port=80
service/svc3 exposed
[root@master sefe]# kubectl expose --name=svc4 pod pod2 --port=80
service/svc4 exposed
# 现在呢4个创完了，可以看到已经达到最大值了
[root@master sefe]# kubectl describe resourcequota
Name: compute-resources
Namespace: safe
Resource Used Hard
-------- ---- ----
pods 1 4
services 4 4
[root@master sefe]#
# 再创建就会报错，限制没问题
[root@master sefe]# kubectl expose --name=svc5 pod pod2 --port=80
Error from server (Forbidden): services "svc5" is forbidden: exceeded quota: compute-resources, requested: services=1, used: services=4, limited: services=4
[root@master sefe]#
#这些svc删了吧
[root@master sefe]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc1 ClusterIP 10.110.89.33 <none> 80/TCP 4m7s
svc2 ClusterIP 10.98.243.94 <none> 80/TCP 4m3s
svc3 ClusterIP 10.110.209.40 <none> 80/TCP 3m58s
svc4 ClusterIP 10.105.54.80 <none> 80/TCP 3m53s
[root@master sefe]#
[root@master sefe]#
[root@master sefe]# kubectl delete svc svc1
service "svc1" deleted
[root@master sefe]# kubectl delete svc svc2
service "svc2" deleted
[root@master sefe]# kubectl delete svc svc3
service "svc3" deleted
[root@master sefe]# kubectl delete svc svc4
service "svc4" deleted
[root@master sefe]#
#上面的限制也删了吧，毕竟限制实验完了
[root@master sefe]# kubectl delete -f quota.yaml
resourcequota "compute-resources" deleted
[root@master sefe]# kubectl delete -f limit.yaml
limitrange "mem-min-max-demo-lr" deleted
[root@master sefe]#
- 这就是 就基本的使用了，可以根据自己的情况做实际限制，参数固定的，不会有意外。
auota和limit混合使用实例
- 主要是想表达，是可以混用的，下面放了一个列子，更多的限制呢可以根据自己的需求修改，反正方法就是这样子的。
kubectl delete -f resourcequota.yaml
cat << EOF > resourcequota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
namespace: lykops
name: lykops
labels:
project: lykops
app: resourcequota
version: v1
spec:
hard:
pods: 50
requests.cpu: 0.5
requests.memory: 512Mi
limits.cpu: 5
limits.memory: 16Gi
configmaps: 20
persistentvolumeclaims: 20
replicationcontrollers: 20
secrets: 20
services: 50
EOF
kubectl create -f resourcequota.yaml
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献17条内容
所有评论(0)