主頁 > 作業系統 > 容器編排系統K8s之訪問控制--準入控制

容器編排系統K8s之訪問控制--準入控制

2021-01-02 06:14:29 作業系統

  前文我們聊到了k8s的訪問控制第二關RBAC授權插件的相關話題,回顧請參考:https://www.cnblogs.com/qiuhom-1874/p/14216634.html;今天我們來聊一下k8s上的訪問控制第三關準入控制相關話題;

  在說準入控制之前,我們先來回顧下之前的用戶認證和授權,在k8s上用戶認證和授權機制都是通過一個個插件進行功能的擴展,我們要要想使用某種用戶認證和授權機制,相應的我們應該去啟用對應的插件;對于用戶認證和授權這兩個機制來說,它們的作業邏輯都是一樣的,都是一票通過的機制,一票通過是指啟有多個插件,只要對應用戶來認證或做授權驗證,只要有其中的一個插件滿足要求,對應的用戶就能通過認證,同樣的道理驗證授權也是,在k8s上授權插件是顯式授權的,即只要滿足對應定義的授權規則,則對應的驗證授權就會被通過,反之沒有顯式授權的,即便認真通過權限驗證也是不能放行的;對于準入控制來說,在k8s上準入控制是通過準入控制器實作的,一個準入控制器就對應了一個插件,我們要使用對應的準入控制器,相應我們也要啟用對應的插件才行;在k8s上準入控制、用戶認證、授權默認都內置并啟用一些插件,我們可以直接撰寫對應的規則即可;準入控制和用戶認證、授權機制不同的是,準入控制的作業邏輯是一票否決機制,所謂一票否決是指在多個準入控制規則當中,只要不滿足其中一個規則,對應的請求就是拒絕操作的;對于準入控制來說,它有兩種型別,一種是變異型,一種是校驗型;所謂變異型是指我們在提交給apiserver進行資源創建時,默認沒有指定的對應欄位的資訊;它會給我們補上,或者我們定義資源的某些屬性的值不太規范,它會幫助我們修改對應的屬性的值為一個規范的值,然后提交給apiserver;這種準入控制器通常是幫助我們把對應提交的資源創建資訊,規范后提交給apiserver,使得我們提交資源的資訊是能夠滿足對應api規范;校驗型準入控制器是用來限制我們對應創建資源是否合理,是否滿足我們定義的規則,如果不滿足就直接拒絕我們創建;這種控制器主要用來限制我們對k8s上的資源的使用;

  在k8s上準入控制器的模塊有很多,其中比較常用的有LimitRanger、ResourceQuota、ServiceAccount、PodSecurityPolicy等等,對于前面三種準入控制器系統默認是啟用的,我們只需要定義對應的規則即可;對于PodSecurityPolicy這種準入控制器,系統默認沒有啟用,如果我們要使用,就必需啟用以后,對應規則才會正常生效;這里需要注意一點,對應psp準入控制器,一定要先寫好對應的規則,把規則和權限系結好以后,在啟用對應的準入控制器,否則先啟用準入控制器,沒有對應的規則,默認情況它是拒絕操作,在k8s上沒有顯式定義規則都是拒絕,這可能導致現有的k8s系統跑的系統級pod無法正常作業;所以對于psp準入控制器要慎用,如果規則和權限做的足夠精細,它會給我們的k8s系統安全帶來大幅度的提升,反之,可能導致整個k8s系統不可用;

  查看apiserver啟用的準入控制器

  提示:apiserver啟用準入控制插件需要使用--enable-admission-plugins選項來指定,該選項可以使用多個值,用逗號隔開表示啟用指定的準入控制插件;這里組態檔中顯式啟用了NodeRestrication這個插件;默認沒有寫在這上面的內置準入控制器,它也是啟用了的,比如LimitRanger、ResourceQuota、ServiceAccount等等;對于不同的k8s版本,內置的準入控制器和啟用與否請查看相關版本的官方檔案;對于那些沒有啟動的準入控制器,我們可以在上面選項中直接啟用,分別用逗號隔開即可;

  LimitRanger控制器

  LimitRanger準入控制器是k8s上一個內置的準入控制器,LimitRange是k8s上的一個標準資源,它主要用來定義在某個名稱空間下限制pod或pod里的容器對k8s上的cpu和記憶體資源使用;它能夠定義我們在某個名稱空間下創建pod時使用的cpu和記憶體的上限和下限以及默認cpu、記憶體的上下限;如果我們創建pod時定義了資源上下限,但不滿足LimitRange規則中定義的資源上下限,此時LimitRanger就會拒絕我們創建此pod;如果我們在LimitRange規則中定義了默認的資源上下限制,我們創建資源沒有指定其資源限制,它默認會使用LimitRange規則中的默認資源限制;同樣的邏輯LimitRanger可以限制一個pod使用資源的上下限,它還可以限制pod中的容器的資源上下限,比限制pod更加精準;不管是針對pod還是pod里的容器,它始終只是限制單個pod資源使用;

  LimitRange規則定義

[root@master01 ~]# cat LimitRang-demo.yaml
apiVersion: v1
kind: Namespace
metadata: 
  name: myns
---
apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-memory-limit-range
  namespace: myns
spec:
  limits:
  - default:
      cpu: 1000m
      memory: 1000Mi
    defaultRequest:
      cpu: 500m
      memory: 500Mi
    min:
      cpu: 500m
      memory: 500Mi
    max:
      cpu: 2000m
      memory: 2000Mi
    maxLimitRequestRatio:
      cpu: 4
      memory: 4
    type: Container
[root@master01 ~]# 

  提示:以上清單主要定義了兩個資源,一個創建myns名稱空間,一個是在對應myns名稱空間下定義了LimitRange資源;其中LimitRange資源的名稱為cpu-memory-limit-range,default欄位用來指定默認容器資源上限值;defaultRequest用來指定默認容器資源下限值;min欄位用來指定限制用戶指定的資源下限不能小于對應資源的值;max是用來限制用戶指定資源上限值不能大于該值;maxLimitRequestRatio欄位用來指定資源的上限和下限的比值;即上限是下限的多少倍;type是用來描述對應資源限制的級別,該欄位有兩個值pod和container;上述資源清單表示在該名稱空間下創建pod時,默認不指定其容器的資源限制,就限制對應容器最少要有0.5個核心的cpu和500M的記憶體;最大為1個核心cpu,1g記憶體;如果我們手動定義了容器的資源限制,那么對應資源限制最小不能小于cpu為0.5個核心,記憶體為500M,最大不能超過cpu為2個核心,記憶體為2000M;如果我們在創建pod時,只指定了容器的資源上限或下限,那么上限最大是下限的的4倍,如果指定cpu上限為2000m那么下限一定不會小于500m,如果只指定了cpu下限為500m那么上限最大不會超過2000m,對于記憶體也是同樣的邏輯;

  應用資源清單

[root@master01 ~]# kubectl apply -f LimitRang-demo.yaml
namespace/myns created
limitrange/cpu-memory-limit-range created
[root@master01 ~]# kubectl get limitrange -n myns
NAME                     CREATED AT
cpu-memory-limit-range   2021-01-01T08:01:24Z
[root@master01 ~]# kubectl describe limitrange cpu-memory-limit-range -n myns                      
Name:       cpu-memory-limit-range
Namespace:  myns
Type        Resource  Min    Max     Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---    ---     ---------------  -------------  -----------------------
Container   cpu       500m   2       500m             1              4
Container   memory    500Mi  2000Mi  500Mi            1000Mi         4
[root@master01 ~]# 

  提示:資源清單中如果指定了maxLimitRequestRatio,需要注意min中和max中的對應資源的單位,如果指定的倍數和max與min中指定的值比例不同,它這里會不會讓我們創建;如下提示

[root@master01 ~]# kubectl apply -f LimitRang-demo.yaml
namespace/myns unchanged
The LimitRange "cpu-limit-range" is invalid: spec.limits[0].maxLimitRequestRatio[memory]: Invalid value: resource.Quantity{i:resource.int64Amount{value:4, scale:0}, d:resource.infDecAmount{Dec:(*inf.Dec)(nil)}, s:"4", Format:"DecimalSI"}: ratio 4 is greater than max/min = 3.814697
[root@master01 ~]#

  提示:我們在資源中指定maxLimitRequestRatio,它內部就是使用max/min,所以對應的值必須符合max/min的值;

  驗證:在myns名稱空間下創建一個pod,默認不指定其資源限制,看看它是否會被limitrange規則自動附加其資源限制?

[root@master01 manifests]# cat pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
[root@master01 manifests]# kubectl apply -f pod-demo.yaml
pod/nginx-pod-demo created
[root@master01 manifests]# kubectl get pods -n myns
NAME             READY   STATUS    RESTARTS   AGE
nginx-pod-demo   1/1     Running   0          15s
[root@master01 manifests]# kubectl describe pod nginx-pod-demo -n myns
Name:         nginx-pod-demo
Namespace:    myns
Priority:     0
Node:         node01.k8s.org/192.168.0.44
Start Time:   Fri, 01 Jan 2021 16:12:53 +0800
Labels:       <none>
Annotations:  kubernetes.io/limit-ranger: LimitRanger plugin set: cpu, memory request for container nginx; cpu, memory limit for container nginx
Status:       Running
IP:           10.244.1.108
IPs:
  IP:  10.244.1.108
Containers:
  nginx:
    Container ID:   docker://4d566a239fe3f80e823352ff2eb0f4bc9e5ca1c107c62d87a5035e2d70e7d8f2
    Image:          nginx:1.14-alpine
    Image ID:       docker-pullable://nginx@sha256:485b610fefec7ff6c463ced9623314a04ed67e3945b9c08d7e53a47f6d108dc7
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 01 Jan 2021 16:12:54 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  1000Mi
    Requests:
      cpu:        500m
      memory:     500Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-n6tg5 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-n6tg5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-n6tg5
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  33s   default-scheduler  Successfully assigned myns/nginx-pod-demo to node01.k8s.org
  Normal  Pulled     32s   kubelet            Container image "nginx:1.14-alpine" already present on machine
  Normal  Created    32s   kubelet            Created container nginx
  Normal  Started    32s   kubelet            Started container nginx
[root@master01 manifests]# 

  提示:可以看到我們在myns名稱空間下創建的pod沒有指定其容器資源限制,創建pod后,其內部容器自動就有了默認的資源限制;其大小就是我們在定義LimitRange規則中的default和defaultRequite欄位中指定的資源限制;

  驗證:創建一個pod指定其cpu下限為200m,看看對應pod是否允許我們創建?

[root@master01 manifests]# cat pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo2
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    resources:   
      requests:
        cpu: 200m
[root@master01 manifests]# kubectl apply -f pod-demo.yaml 
Error from server (Forbidden): error when creating "pod-demo.yaml": pods "nginx-pod-demo2" is forbidden: [minimum cpu usage per Container is 500m, but request is 200m, cpu max limit to request ratio per Container is 4, but provided ratio is 5.000000]
[root@master01 manifests]# 

  提示:我們在創建資源清單中限制了容器使用cpu為200m,在應用資源清單時,它這里就不允許我們創建,其原因是我們指定的資源限制規則不滿足LimitRange這條準入控制規則,所以對應創建pod的請求被拒絕;這也意味著我們在創建pod時,指定容器資源限制不能低于LimitRange準入控制規則中的最低限制,否則對應pod不被允許創建;

  驗證:創建pod時指定其cpu最大限制為2500m,看看對應pod是否允許被創建?

[root@master01 manifests]# cat pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo2
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    resources:   
      limits:
        cpu: 2500m
[root@master01 manifests]# kubectl apply -f pod-demo.yaml
Error from server (Forbidden): error when creating "pod-demo.yaml": pods "nginx-pod-demo2" is forbidden: maximum cpu usage per Container is 2, but limit is 2500m
[root@master01 manifests]# 

  提示:可以看到在pod容器里指定對應的資源限制上限大于LimitRange準入控制規則中的max欄位的值時,對應pod是不被允許創建;

  驗證:給定pod容器的cpu上限或下限為對應范圍內的值看看對應pod是否允許被創建?

[root@master01 manifests]# cat pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo2
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    resources:   
      requests:
        cpu: 700m
[root@master01 manifests]# kubectl apply -f pod-demo.yaml
pod/nginx-pod-demo2 created
[root@master01 manifests]# kubectl describe pod nginx-pod-demo2 -n myns
Name:         nginx-pod-demo2
Namespace:    myns
Priority:     0
Node:         node03.k8s.org/192.168.0.46
Start Time:   Fri, 01 Jan 2021 16:33:39 +0800
Labels:       <none>
Annotations:  kubernetes.io/limit-ranger: LimitRanger plugin set: memory request for container nginx; cpu, memory limit for container nginx
Status:       Running
IP:           10.244.3.119
IPs:
  IP:  10.244.3.119
Containers:
  nginx:
    Container ID:   docker://4a576eda79e0f2a377ca9d058ee6e64decf45223b720b93c3291eed9c2a920d1
    Image:          nginx:1.14-alpine
    Image ID:       docker-pullable://nginx@sha256:485b610fefec7ff6c463ced9623314a04ed67e3945b9c08d7e53a47f6d108dc7
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 01 Jan 2021 16:33:40 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  1000Mi
    Requests:
      cpu:        700m
      memory:     500Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-n6tg5 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-n6tg5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-n6tg5
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  23s   default-scheduler  Successfully assigned myns/nginx-pod-demo2 to node03.k8s.org
  Normal  Pulled     23s   kubelet            Container image "nginx:1.14-alpine" already present on machine
  Normal  Created    22s   kubelet            Created container nginx
  Normal  Started    22s   kubelet            Started container nginx
[root@master01 manifests]# 

  提示:從上面的示例可以看到,我們給定資源下限,對應資源上限它會用默認值給填充;

  ResourceQuota準入控制器

  ResourceQuota準入控制器也是k8s上內置的準入控制器,默認該控制器是啟用的狀態,它主要作用是用來限制一個名稱空間下的資源的使用;相對于LimitRanger準入控制器相比,它能防止在一個名稱空間下的pod被過多創建時,導致過多占用k8s上的資源;簡單講它是用來在名稱空間級別限制用戶的資源使用;不同于LimitRanger準入控制器,Resourcequota準入控制器限制的是某個名稱空間下的資源,而LimitRanger準入控制器限制的是單個pod或pod中的容器的資源使用;

  ResourceQuota資源的創建

[root@master01 ~]# cat resourcequota-demo.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-demo
  namespace: myns
spec:
  hard:
    pods: "5"
    requests.cpu: "5"
    requests.memory: 5Gi
    limits.cpu: "4"
    limits.memory: 10Gi
    count/deployments.apps: "5"
    count/deployments.extensions: "5"
    persistentvolumeclaims: "5"
[root@master01 ~]# 

  提示:ResourceQuota的定義其kind型別為ResourceQuota,群組為核心群組v1;其中spec.hard欄位是用來定義對應名稱空間下的資源限制規則;pods用來限制在對應名稱空間下的pod數量,requests.cpu欄位用來限制對應名稱空間下所有pod的cpu資源的下限總和;requests.memory用來限制對應名稱空間下pod的記憶體資源的下限總和;limits.cpu用來限制對應名稱空間下的podcpu資源的上限總和,limits.memory用來限制對應名稱空間下pod記憶體資源上限總和;count/deployments.apps用來限制對應名稱空間下apps群組下的deployments的個數,count/deployments.extensions用來限制對應名稱空間下extensions群組下的deployments的數量;以上配置清單表示,在myns名稱空間下運行的pod數量不能超過5個,或者所有pod的cpu資源下限總和不能大于5個核心,記憶體資源下限總和不能大于5G,或者cpu上限資源總和不能大于4個核心,記憶體上限總和不能超過10G,或者apps群組下的deployments控制器不能超過5個,exetensions群組下的deploy控制器不能超過5個,pv個數不能超過5個;以上條件中任意一個條目不滿足,都將無法在對應名稱空間創建對應的資源;

  應用資源清單

[root@master01 ~]# kubectl apply -f resourcequota-demo.yaml
resourcequota/quota-demo created
[root@master01 ~]# kubectl get resourcequota -n myns
NAME         AGE   REQUEST                                                                                                                                                      LIMIT
quota-demo   33s   count/deployments.apps: 0/5, count/deployments.extensions: 0/5, persistentvolumeclaims: 0/5, pods: 2/5, requests.cpu: 1200m/5, requests.memory: 1000Mi/5Gi   limits.cpu: 2/4, limits.memory: 2000Mi/10Gi
[root@master01 ~]# kubectl describe resourcequota quota-demo -n myns    
Name:                         quota-demo
Namespace:                    myns
Resource                      Used    Hard
--------                      ----    ----
count/deployments.apps        0       5
count/deployments.extensions  0       5
limits.cpu                    2       4
limits.memory                 2000Mi  10Gi
persistentvolumeclaims        0       5
pods                          2       5
requests.cpu                  1200m   5
requests.memory               1000Mi  5Gi
[root@master01 ~]# 

  提示:可以看到應用資源清單以后,對應名稱空間下的資源使用情況可以通過查看resourcequota資源的詳細資訊就能了解到;從上述resourcequota資源的詳細資訊中可以看到,當前myns中pod的cpu資源上限已經使用了2顆核心,對應記憶體的上限是了2000M;

  驗證:在myns下創建2個cpu資源上限為2000m的pod,看看對應pod是否被允許創建?

[root@master01 manifests]# cat pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo3
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    resources:   
      limits:
        cpu: 2000m
[root@master01 manifests]# kubectl apply -f pod-demo.yaml
pod/nginx-pod-demo3 created
[root@master01 manifests]# kubectl describe resourcequota quota-demo -n myns
Name:                         quota-demo
Namespace:                    myns
Resource                      Used    Hard
--------                      ----    ----
count/deployments.apps        0       5
count/deployments.extensions  0       5
limits.cpu                    4       4
limits.memory                 3000Mi  10Gi
persistentvolumeclaims        0       5
pods                          3       5
requests.cpu                  3200m   5
requests.memory               1500Mi  5Gi
[root@master01 manifests]# cat pod-demo2.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo4
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    resources:   
      limits:
        cpu: 2000m
[root@master01 manifests]# kubectl apply -f pod-demo2.yaml
Error from server (Forbidden): error when creating "pod-demo2.yaml": pods "nginx-pod-demo4" is forbidden: exceeded quota: quota-demo, requested: limits.cpu=2,requests.cpu=2, used: limits.cpu=4,requests.cpu=3200m, limited: limits.cpu=4,requests.cpu=5
[root@master01 manifests]# 

  提示:可以看到在創建第一個pod時,對應pod成功創建,在創建第二個pod時,對應pod就能正常創建,其原因是對應myns名稱空間下正常處于運行狀態的pod的cpu資源上限總和已經和resourcequota準入控制規則中的limit.cpus欄位的值一樣了,再次創建pod時,myns名稱空間下的pod的cpu資源上限總和大于limit.cpus的值,所以不滿足resourcequota準入控制規則,所以第二個pod就不允許被創建;

  示例:使用resourcequota資源限制名稱空間下的storage資源

[root@master01 ~]# cat resourcequota-storage-demo.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-storage-demo
  namespace: default
spec:
  hard:
    requests.storage: "5Gi"
    persistentvolumeclaims: "5"
    requests.ephemeral-storage: "1Gi"
    limits.ephemeral-storage: "2Gi"
[root@master01 ~]# 

  提示:requests.storage用來限制對應名稱空間下的存盤下限總和,persistenvolumeclaims用來限制pvc總數量,requests.ephemeral-storage用來現在使用本地臨時存盤的下限總容量;limits.ephemeral-storage用來限制使用本地臨時存盤上限總容量;以上配置表示在default名稱空間下非停止狀態的容器存盤下限總容量不能超過5G,pvc的數量不能超過5個,本地臨時存盤下限容量不能超過1G,上限不能超過2G;

  應用配置清單

[root@master01 ~]# kubectl apply -f resourcequota-storage-demo.yaml
resourcequota/quota-storage-demo created
[root@master01 ~]# kubectl get resourcequota                        
NAME                 AGE   REQUEST                                                                                     LIMIT
quota-storage-demo   7s    persistentvolumeclaims: 3/5, requests.ephemeral-storage: 0/1Gi, requests.storage: 3Gi/5Gi   limits.ephemeral-storage: 0/2Gi
[root@master01 ~]# kubectl describe resourcequota quota-storage-demo
Name:                       quota-storage-demo
Namespace:                  default
Resource                    Used  Hard
--------                    ----  ----
limits.ephemeral-storage    0     2Gi
persistentvolumeclaims      3     5
requests.ephemeral-storage  0     1Gi
requests.storage            3Gi   5Gi
[root@master01 ~]# 

  驗證:在default名稱空間下,再創建3個pvc看看對應資源是否被允許創建?

[root@master01 ~]# cat pvc-v1-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nfs-pv-v4
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 500Mi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nfs-pv-v5
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 500Mi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nfs-pv-v6
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 500Mi
[root@master01 ~]# kubectl apply -f pvc-v1-demo.yaml
persistentvolumeclaim/pvc-nfs-pv-v4 created
persistentvolumeclaim/pvc-nfs-pv-v5 created
Error from server (Forbidden): error when creating "pvc-v1-demo.yaml": persistentvolumeclaims "pvc-nfs-pv-v6" is forbidden: exceeded quota: quota-storage-demo, requested: persistentvolumeclaims=1, used: persistentvolumeclaims=5, limited: persistentvolumeclaims=5
[root@master01 ~]# 

  提示:可以看到現在在default名稱空間下創建3個pvc時,對應前兩個被成功創建,第三個被拒絕了;原因是defualt名稱空間下的pvc資源數量已經達到resourcequota準入控制規則中定義的數量,所以不予創建;

  示例:創建resourcequota準入控制規則,并限定其生效范圍

[root@master01 ~]# cat resourcequota-scopes-demo.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-scopes-demo
  namespace: myns
spec:
  hard:
    pods: "5"
  scopes: ["BestEffort"]
[root@master01 ~]# 

  提示:限制resourcequota準入控制規則生效范圍,可以使用scopes欄位來指定對應的范圍;該欄位為一個串列,默認不指定是指所有狀態的pod;其中BsetEffort表示匹配對應pod的QOS(服務質量類別)值為BestEffort的pod ;NotBestEffort表示匹配對應pod的QOS值不是BestEffort的pod;Terminating表示匹配對應Pod狀態為Terminating狀態的pod;NotTerminating表示匹配狀態不是Terminating狀態的pod;上述清單規則表示只對pod的服務質量類別為BestEffort的pod生效;其他型別的pod不記錄到對應規則中;即只能在對應名稱空間下創建5個服務質量類別為BestEffort類別的pod;

  應用配置清單

[root@master01 ~]# kubectl apply -f resourcequota-scopes-demo.yaml
resourcequota/quota-scopes-demo created
[root@master01 ~]# kubectl get quota -n myns
NAME                AGE   REQUEST     LIMIT
quota-scopes-demo   12s   pods: 0/5   
[root@master01 ~]# 

  提示:限制pod的服務質量類別為BestEffort,只能對pod資源施加,其它資源都不支持;

  PodSecurityPolicy準入控制器

  PodSecurityPolicy準入控制器主要用來設定pod安全相關的策略,比如是否允許對應pod共享宿主機網路名稱空間,是否允許pod允許為特權模式等等;

  示例:定義psp準入控制器規則

[root@master01 psp]# cat psp-privileged.yaml 
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: privileged
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
[root@master01 psp]# 

  提示:PodSecurityPolicy是k8s的標準資源,其型別為PodSecurityPolicy,群組版本為policy/v1beta1;其中spec欄位用來定義對pod的相關安全屬性的定義;privileged用來定義對應pod是否允許運行為特權模式;allowPrivilegeEscalation用來指定是否運行對應容器子行程特權;allowedCapabilities用來指定允許使用內核中的Capabilities功能,“*”表示所有;volumes用來指定可以使用的卷型別串列,*表示可以使用支持的任意型別的的卷;hostNetwork表示是否允許共享宿主機網路名稱空間;hostPorts用來指定可以使用宿主機埠范圍,min限制埠下限,max限制埠上限;hostIPC表示是否允許共享宿主機的IPC,hostPID表示是否共享宿主機的PID;runAsUser用來指定對應pod允許以那個用戶身份運行,RunAsAny表示可以以任意用戶身份運行;以上清單主要定義了一個特權psp準入控制規則,通常這類psp應該有應用在對所有系統級pod使用;一般的普通用戶創建的pod不應該擁有上述權限;

  psp準入控制規則相關屬性說明

  示例:定義一個非特權psp準入控制法則

[root@master01 psp]# cat psp-restricted.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'docker/default'
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  readOnlyRootFilesystem: false
[root@master01 psp]# 

  提示:定義好上述psp準入控制資源以后,我們還應該把對那個對應準入控制資源系結到不同的角色上,以實作不同角色擁有不同的psp準入控制法則的使用權限;

  示例:定義clusterrole分別關聯不同的psp準入控制資源

[root@master01 psp]# cat clusterrole-with-psp.yaml 
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp:restricted
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - restricted
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp:privileged
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - privileged
[root@master01 psp]# 

  提示:以上定義了兩個clusterrole,一個名為psp:restricted,該角色主要關聯非特權psp資源,其資源名為restricted;第二個clusterrole名為psp:privileged,該角色主要關聯特權psp資源;其對應psp資源名稱為privileged;

  示例:創建clusterrolebinding關聯相關用戶和組

[root@master01 psp]# cat clusterrolebinding-with-psp.yaml 
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: restricted-psp-user
roleRef:
  kind: ClusterRole
  name: psp:restricted
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:authenticated
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: privileged-psp-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:privileged
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:node
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:kube-system
[root@master01 psp]# 

  提示:以上配置主要創建了兩個clusterrolebinding,第一個cluserrolebinding主要把在k8s上認證通過的用戶的權限系結到psp:restricted這個角色上,讓其擁有對應的權限,即通過認證的用戶擁有非特權psp準入控制法則權限;第二個clusterrolebinding主要系結了三類用戶,第一類是system:masters組上的用戶,第二類是system:node組上的用戶,第三類是system:serviceaccounts:kube-system組上的用戶;這三個組都是系統級別用戶,主要是系統及pod和組件使用的組;所以這些用戶應該擁有特權psp準入控制法則,對應通過clusterrolebinding系結到psp:privileged這個角色;

  應用上述資源清單

[root@master01 psp]# kubectl apply -f psp-privileged.yaml 
podsecuritypolicy.policy/privileged created
[root@master01 psp]# kubectl apply -f psp-restricted.yaml 
podsecuritypolicy.policy/restricted created
[root@master01 psp]# kubectl apply -f clusterrole-with-psp.yaml 
clusterrole.rbac.authorization.k8s.io/psp:restricted created
clusterrole.rbac.authorization.k8s.io/psp:privileged created
[root@master01 psp]# kubectl apply -f clusterrolebinding-with-psp.yaml 
clusterrolebinding.rbac.authorization.k8s.io/restricted-psp-user created
clusterrolebinding.rbac.authorization.k8s.io/privileged-psp-user created
[root@master01 psp]# 

  提示:應用順序先應用psp準入控制資源,然后在應用clusterrole資源,最后應用clusterrolebinding資源;

  啟用psp準入控制器

  提示:編輯/etc/kubernetes/manifests/kube-apiserver.yaml檔案,找到--enable-admission-plugins選項,在最后加上PodSecurityPolicy用逗號隔開;然后保存退出;對應psp準入控制器就啟用了;

  驗證:把tom用戶設定為myns名稱空間下的管理員,然后使用tom用戶的組態檔在myns下創建一個pod,該pod使用hostNetwork:true選項來共享宿主機網路名稱空間,看看是否能夠正常將pod創建出來?

  設定tom用戶為myns名稱空間下的管理員

[root@master01 ~]# cat tom-rolebinding-myns-admin.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tom-myns-admin
  namespace: myns
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: tom
  
[root@master01 ~]# kubectl apply -f tom-rolebinding-myns-admin.yaml
rolebinding.rbac.authorization.k8s.io/tom-myns-admin created
[root@master01 ~]# kubectl get rolebinding -n myns
NAME             ROLE                AGE
tom-myns-admin   ClusterRole/admin   10s
[root@master01 ~]# 

  驗證tom用戶證書資訊不是在system:master組內

[root@master01 ~]# cat /tmp/myk8s.config |grep  client-certificate-data|awk {'print $2'}|base64 -d|openssl x509 -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            f4:39:a9:5d:2f:01:09:2b
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Dec 29 16:29:59 2020 GMT
            Not After : Dec 29 16:29:59 2021 GMT
        Subject: CN=tom, O=myuser
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:02:e8:0d:ca:d5:3f:36:42:20:5c:16:6c:dd:
                    2a:be:53:f3:b7:14:8e:ca:9f:f4:45:4a:61:97:df:
                    3c:e8:c2:cd:2f:d8:80:85:29:3d:87:b1:9b:5e:9b:
                    dd:60:0b:5f:60:46:8f:71:8b:49:1a:a6:48:94:f8:
                    15:0c:f2:98:3c:ab:3a:7c:28:c4:64:76:bf:03:90:
                    53:f7:2b:6d:18:b5:9b:53:d2:7b:e1:9e:56:bd:c6:
                    41:a7:99:0a:20:d9:d3:1b:f2:3d:f8:84:bb:8a:22:
                    c7:66:1f:8e:7a:ee:e7:06:27:90:06:ce:23:69:eb:
                    c7:42:69:13:d3:bd:2a:c2:5f:bd:1d:2c:0a:19:ca:
                    f4:d6:a2:d4:47:73:bb:4e:5a:01:75:37:ba:2f:2b:
                    78:5f:70:3b:ce:5b:46:25:fb:c8:3f:8a:7b:15:ea:
                    85:aa:b0:b9:28:85:1a:fd:4a:7e:f2:92:40:bd:00:
                    2a:6c:08:84:eb:7b:dc:5b:e0:13:71:d3:af:75:e3:
                    6a:23:e1:a5:78:a2:03:ba:bf:e6:1b:bb:37:cc:11:
                    aa:aa:d2:66:10:22:8f:31:a3:4d:f8:79:d2:05:d7:
                    c9:9a:8c:ce:59:7c:30:7e:f1:2d:9a:4a:53:94:cc:
                    83:47:91:ea:6d:4f:01:9c:c9:3d:c6:9d:85:e0:41:
                    5c:ff
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         41:47:71:e6:60:70:5b:b0:5f:9c:47:2d:05:07:fd:93:6d:1b:
         16:c3:fd:c8:d4:2e:45:b3:fd:d0:4c:e7:19:b4:80:86:ae:8f:
         01:5b:26:f7:01:00:3a:e0:0f:b7:ce:6e:0a:a2:e2:84:2c:86:
         cd:d8:cb:42:3a:c6:bd:b0:50:72:2e:35:fb:02:5e:78:0c:ce:
         fa:3d:28:bc:96:63:d0:83:30:93:6f:59:4d:94:27:8d:ea:5c:
         1e:19:1b:35:29:87:cf:76:3b:60:4d:8d:f2:b7:37:9a:5a:b6:
         7c:58:ae:dd:f0:7a:fd:de:b9:9f:77:bb:fb:9c:42:d8:50:bc:
         2f:50:5c:9b:56:4b:90:89:14:c9:52:6d:64:59:dd:3f:53:b1:
         e4:32:91:d5:98:fb:83:fa:78:23:45:0f:53:92:f0:1a:58:81:
         03:f3:a3:b4:0a:83:d3:7c:ef:04:e8:ee:27:df:e8:4f:68:dc:
         df:46:ef:6b:45:7b:c0:bb:55:fd:82:c6:d9:3b:66:26:14:4a:
         fe:79:7d:a1:24:43:ba:20:19:6b:b3:d8:0f:2f:30:2b:d3:22:
         e6:f9:a9:88:38:98:7b:d6:c4:41:17:62:8d:05:6e:1f:c3:e2:
         44:dc:35:a2:7f:ed:70:2f:68:75:50:61:74:41:d2:86:dd:75:
         18:21:a1:c9
[root@master01 ~]# 

  提示:可以看到tom用戶的證書中O=myuser,并非system:master;

  使用tom用戶的組態檔在myns名稱空間下創建pod

[root@master01 manifests]# cat pod-demo3.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo3
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
  hostNetwork: true
[root@master01 manifests]# kubectl apply -f pod-demo3.yaml --kubeconfig=/tmp/myk8s.config
Error from server (Forbidden): error when creating "pod-demo3.yaml": pods "nginx-pod-demo3" is forbidden: PodSecurityPolicy: unable to admit pod: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used]
[root@master01 manifests]# 

  提示:可以看到tom用戶在myns名稱空間下創建pod并共享宿主機網路名稱空間,被apiserver拒絕了;這是因為我們剛才啟用了psp準入控制器,對應規則明確規定不在system:master組或system:serviceaccounts:system-kube組或system:node組的所有用戶都不能創建pod共享宿主機名稱空間;

  使用system:master組上的用戶創建pod共享宿主機網路名稱空間,看看是否可以?

  驗證:kubectl的證書,看看對應的組是否是system:master

[root@master01 ~]# cat /etc/kubernetes/admin.conf |grep client-certificate-data|awk {'print $2'}|base64 -d |openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 886870692518705366 (0xc4ecc322d4838d6)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Dec  8 06:38:54 2020 GMT
            Not After : Dec  8 06:38:56 2021 GMT
        Subject: O=system:masters, CN=kubernetes-admin
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c0:4f:cc:45:9b:4a:19:00:a4:af:68:13:f4:39:
                    b0:4c:a8:67:85:af:b3:f7:04:7e:de:16:4b:62:2c:
                    d4:e8:c8:b3:26:39:d2:9a:8e:00:71:ef:82:ff:d3:
                    ad:1a:89:f2:9b:2a:7b:84:c5:5c:85:5a:d0:c5:6e:
                    89:9d:96:e7:ec:db:92:50:f7:4f:a1:d8:14:2e:48:
                    33:de:05:48:f1:aa:36:d1:d3:9c:bf:6d:b9:6b:75:
                    ce:66:a5:72:52:6c:bb:6c:2b:96:98:da:e1:99:1b:
                    d4:51:3d:5d:d4:fa:76:d9:18:c7:d2:37:95:ad:3c:
                    e7:af:87:21:75:1b:96:bb:64:51:f5:ae:44:ba:43:
                    e1:d5:5d:39:57:a1:f0:04:e5:39:6c:af:8c:a6:7e:
                    eb:4f:98:5d:07:ce:da:89:91:08:34:db:67:0b:09:
                    0c:59:3b:16:b0:13:f7:13:b8:fb:6f:54:d1:c9:e5:
                    ce:27:a6:09:af:cc:9d:b5:1e:0a:9c:b4:d2:64:76:
                    cd:35:67:9e:b5:a6:ba:d8:44:e9:c9:e8:0d:fb:c7:
                    00:06:4a:ce:72:67:a7:0e:56:57:8c:75:2a:c7:0f:
                    bb:4a:d9:0c:ec:a1:27:3a:ce:92:13:e4:bf:d1:31:
                    c8:be:20:58:a0:d6:43:f7:21:8a:cb:e3:fe:5e:1d:
                    d9:2d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication
            X509v3 Authority Key Identifier: 
                keyid:BE:53:44:7A:0F:3D:B0:99:37:F3:D3:52:BE:C1:75:E6:EF:81:DD:13

    Signature Algorithm: sha256WithRSAEncryption
         35:ea:55:af:57:62:46:26:e9:60:59:82:c2:52:55:45:23:f3:
         f9:2a:2a:78:28:6c:26:6a:32:c9:df:75:17:ca:44:0f:7f:2a:
         ae:a5:7b:e5:d0:99:3e:97:27:1d:13:a9:5f:d7:09:29:c8:d9:
         68:a6:c1:c5:e3:28:14:6e:0f:c8:32:4b:06:8a:6b:fe:ba:ce:
         e4:59:b6:70:d4:11:71:cf:e9:c2:dc:da:86:9c:12:82:82:58:
         78:83:32:ac:ff:99:6e:1f:07:e0:9d:02:86:dc:e2:e4:30:a1:
         36:f1:43:cb:a1:13:1c:27:87:19:89:15:38:25:0a:29:dd:66:
         6b:ed:7e:8c:fe:95:8e:10:77:5f:70:47:98:a0:37:4f:9e:57:
         6a:66:35:9c:dc:64:f5:1a:01:cd:45:6e:01:bc:15:6f:6f:cd:
         f6:51:f4:8e:28:14:77:9e:50:42:42:e2:a8:42:76:b5:f9:c8:
         87:bb:a5:3e:64:ce:1c:88:6d:31:99:53:c6:8f:88:f1:72:7c:
         5a:d6:dc:fe:7e:fa:26:d2:e0:f3:b8:47:d5:8b:c7:b2:88:80:
         16:53:38:31:96:19:9a:73:98:c8:c3:30:13:23:71:b7:1d:d4:
         c9:00:c0:b0:99:bf:24:f3:cf:c6:76:27:d2:6e:3a:5f:fc:5c:
         55:25:98:e2
[root@master01 ~]# 

  提示:可以看到對應證書資訊中的O=system:master,說明使用kubectl工具加載/etc/kubernetes/admin.config檔案,在apiserver上認證會被是被為system:master組上的成員;

  使用kubectl 加載/etc/kubernetes/admin.conf 創建pod共享宿主機上的網路名稱空間;

[root@master01 manifests]# cat pod-demo3.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo3
  namespace: myns
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
  hostNetwork: true
[root@master01 manifests]# kubectl apply -f pod-demo3.yaml --kubeconfig=/etc/kubernetes/admin.conf
pod/nginx-pod-demo3 created
[root@master01 manifests]# kubectl get pod -n myns --kubeconfig=/etc/kubernetes/admin.conf
NAME              READY   STATUS    RESTARTS   AGE
nginx-pod-demo3   1/1     Running   0          20s
[root@master01 manifests]# 

  提示:可以看到使用system:master組上用戶的證書在myns名稱空間下就能夠正常創建共享宿主機網路名稱空間的pod;通過上面的示例可以看到對應psp準入控制規則的設定是生效的;

轉載請註明出處,本文鏈接:https://www.uj5u.com/caozuo/243447.html

標籤:其他

上一篇:Linux服務器上搭建測驗環境(war包+tomcat)

下一篇:Gnome Bug:無法點擊、永不消逝的授權對話框

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • CA和證書

    1、在 CentOS7 中使用 gpg 創建 RSA 非對稱密鑰對 gpg --gen-key #Centos上生成公鑰/密鑰對(存放在家目錄.gnupg/) 2、將 CentOS7 匯出的公鑰,拷貝到 CentOS8 中,在 CentOS8 中使用 CentOS7 的公鑰加密一個檔案 gpg -a ......

    uj5u.com 2020-09-10 00:09:53 more
  • Kubernetes K8S之資源控制器Job和CronJob詳解

    Kubernetes的資源控制器Job和CronJob詳解與示例 ......

    uj5u.com 2020-09-10 00:10:45 more
  • VMware下安裝CentOS

    VMware下安裝CentOS 一、軟硬體準備 1 Centos鏡像準備 1.1 CentOS鏡像下載地址 下載地址 1.2 CentOS鏡像下載程序 點擊下載地址進入如下圖的網站,選擇需要下載的版本,這里選擇的是Centos8,點擊如圖所示。 決定選擇Centos8后,選擇想要的鏡像源進行下載,此 ......

    uj5u.com 2020-09-10 00:12:10 more
  • 如何使用Grep命令查找多個字串

    如何使用Grep 命令查找多個字串 大家好,我是良許! 今天向大家介紹一個非常有用的技巧,那就是使用 grep 命令查找多個字串。 簡單介紹一下,grep 命令可以理解為是一個功能強大的命令列工具,可以用它在一個或多個輸入檔案中搜索與正則運算式相匹配的文本,然后再將每個匹配的文本用標準輸出的格式 ......

    uj5u.com 2020-09-10 00:12:28 more
  • git配置http代理

    git配置http代理 經常遇到克隆 github 慢的問題,這里記錄一下幾種配置 git 代理的方法,解決 clone github 過慢。 目錄 git配置代理 git單獨配置github代理 git配置全域代理 配置終端環境變數 git配置代理 主要使用 git config 命令 git單獨 ......

    uj5u.com 2020-09-10 00:12:33 more
  • Linux npm install 裝包時提示Error EACCES permission denied解

    npm install 裝包時提示Error EACCES permission denied解決辦法 ......

    uj5u.com 2020-09-10 00:12:53 more
  • Centos 7下安裝nginx,使用yum install nginx,提示沒有可用的軟體包

    Centos 7下安裝nginx,使用yum install nginx,提示沒有可用的軟體包。 18 (flaskApi) [root@67 flaskDemo]# yum -y install nginx 19 已加載插件:fastestmirror, langpacks 20 Loading ......

    uj5u.com 2020-09-10 00:13:13 more
  • Linux查看服務器暴力破解ssh IP

    在公網的服務器上經常遇到別人爆破你服務器的22埠,用來挖礦或者干其他嘿嘿嘿的事情~ 這種情況下正確的做法是: 修改默認ssh的22埠 使用設定密鑰登錄或者白名單ip登錄 建議服務器密碼為復雜密碼 創建普通用戶登錄服務器(root權限過大) 建立堡壘機,實作統一管理服務器 統計爆破IP [root ......

    uj5u.com 2020-09-10 00:13:17 more
  • CentOS 7系統常見快捷鍵操作方式

    Linux系統中一些常見的快捷方式,可有效提高操作效率,在某些時刻也能避免操作失誤帶來的問題。 ......

    uj5u.com 2020-09-10 00:13:31 more
  • CentOS 7作業系統目錄結構介紹

    作業系統存在著大量的資料檔案資訊,相應檔案資訊會存在于系統相應目錄中,為了更好的管理資料資訊,會將系統進行一些目錄規劃,不同目錄存放不同的資源。 ......

    uj5u.com 2020-09-10 00:13:35 more
最新发布
  • vim的常用命令

    Vim的6種基本模式 1. 普通模式在普通模式中,用的編輯器命令,比如移動游標,洗掉文本等等。這也是Vim啟動后的默認模式。這正好和許多新用戶期待的操作方式相反(大多數編輯器默認模式為插入模式)。 2. 插入模式在這個模式中,大多數按鍵都會向文本緩沖中插入文本。大多數新用戶希望文本編輯器編輯程序中一 ......

    uj5u.com 2023-04-20 08:43:21 more
  • vim的常用命令

    Vim的6種基本模式 1. 普通模式在普通模式中,用的編輯器命令,比如移動游標,洗掉文本等等。這也是Vim啟動后的默認模式。這正好和許多新用戶期待的操作方式相反(大多數編輯器默認模式為插入模式)。 2. 插入模式在這個模式中,大多數按鍵都會向文本緩沖中插入文本。大多數新用戶希望文本編輯器編輯程序中一 ......

    uj5u.com 2023-04-20 08:42:36 more
  • docker學習

    ###Docker概述 真實專案部署環境可能非常復雜,傳統發布專案一個只需要一個jar包,運行環境需要單獨部署。而通過Docker可將jar包和相關環境(如jdk,redis,Hadoop...)等打包到docker鏡像里,將鏡像發布到Docker倉庫,部署時下載發布的鏡像,直接運行發布的鏡像即可。 ......

    uj5u.com 2023-04-19 09:26:53 more
  • 設定Windows主機的瀏覽器為wls2的默認瀏覽器

    這里以Chrome為例。 1. 準備作業 wsl是可以使用Windows主機上安裝的exe程式,出于安全考慮,默認情況下改功能是無法使用。要使用的話,終端需要以管理員權限啟動。 我這里以Windows Terminal為例,介紹如何默認使用管理員權限打開終端,具體操作如下圖所示: 2. 操作 wsl ......

    uj5u.com 2023-04-19 09:25:49 more
  • docker學習

    ###Docker概述 真實專案部署環境可能非常復雜,傳統發布專案一個只需要一個jar包,運行環境需要單獨部署。而通過Docker可將jar包和相關環境(如jdk,redis,Hadoop...)等打包到docker鏡像里,將鏡像發布到Docker倉庫,部署時下載發布的鏡像,直接運行發布的鏡像即可。 ......

    uj5u.com 2023-04-19 09:19:04 more
  • Linux學習筆記

    IP地址和主機名 IP地址 ifconfig可以用來查詢本機的IP地址,如果不能使用,可以通過install net-tools安裝。 Centos系統下ens33表示主網卡;inet后表示IP地址;lo表示本地回環網卡; 127.0.0.1表示代指本機;0.0.0.0可以用于代指本機,同時在放行設 ......

    uj5u.com 2023-04-18 06:52:01 more
  • 解決linux系統的kdump服務無法啟動的問題

    問題:專案麒麟系統服務器的kdump服務無法啟動,沒有相關日志無法定位問題。 1、查看服務狀態是關閉的,重啟系統也無法啟動 systemctl status kdump 2、修改grub引數,修改“crashkernel”為“512M(有的機器數值太大太小都會導致報錯,建議從128M開始試,或者加個 ......

    uj5u.com 2023-04-12 09:59:50 more
  • 解決linux系統的kdump服務無法啟動的問題

    問題:專案麒麟系統服務器的kdump服務無法啟動,沒有相關日志無法定位問題。 1、查看服務狀態是關閉的,重啟系統也無法啟動 systemctl status kdump 2、修改grub引數,修改“crashkernel”為“512M(有的機器數值太大太小都會導致報錯,建議從128M開始試,或者加個 ......

    uj5u.com 2023-04-12 09:59:01 more
  • 你是不是暴露了?

    作者:袁首京 原創文章,轉載時請保留此宣告,并給出原文連接。 如果您是計算機相關從業人員,那么應該經歷不止一次網路安全專項檢查了,你肯定是收到過資訊系統技術檢測報告,要求你加強風險監測,確保你提供的系統服務堅實可靠了。 沒檢測到問題還好,檢測到問題的話,有些處理起來還是挺麻煩的,尤其是線上正在運行的 ......

    uj5u.com 2023-04-05 16:52:56 more
  • 細節拉滿,80 張圖帶你一步一步推演 slab 記憶體池的設計與實作

    1. 前文回顧 在之前的幾篇記憶體管理系列文章中,筆者帶大家從宏觀角度完整地梳理了一遍 Linux 記憶體分配的整個鏈路,本文的主題依然是記憶體分配,這一次我們會從微觀的角度來探秘一下 Linux 內核中用于零散小記憶體塊分配的記憶體池 —— slab 分配器。 在本小節中,筆者還是按照以往的風格先帶大家簡單 ......

    uj5u.com 2023-04-05 16:44:11 more