水平自动扩容和缩容HPA；API资源对象NetworkPolicy；Kubernetes用户安全控制；Kubernetes创建普通用户示例

水平自动扩容和缩容HPA；API资源对象NetworkPolicy；Kubernetes用户安全控制；Kubernetes创建普通用户示例

水平自动扩容和缩容HPA（本部分操作适合K8s版本>=1.23.x)

HPA全称是Horizontal Pod Autoscaler，翻译成中文是POD水平自动伸缩，HPA可以基于CPU利用率对replication controller、deployment和replicaset中的pod数量进行自动扩缩容（除了CPU利用率也可以基于其他应程序提供的度量指标custom metrics进行自动扩缩容）。pod自动缩放不适用于无法缩放的对象，比如DaemonSets。

HPA由Kubernetes API资源和控制器实现。资源决定了控制器的行为。控制器会周期性的获取目标资源指标（如，平均CPU利用率），并与目标值相比较后来调整Pod副本数量。

创建测试Deployment

vi php-apache.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: tanglinux/hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m  ##限制Pod CPU资源最多使用500m
          requests:
            cpu: 200m  ##K8s要保证Pod使用的最小cpu资源为200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

kubectl apply -f php-apache.yaml

安装merics-server（通过它才能获取到具体的资源使用情况）

下载yaml文件

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml

修改YAML文件

vi high-availability-1.21+.yaml

将image: k8s.gcr.io/metrics-server/metrics-server:v0.6.2 修改为 image: tanglinux/metrics-server:v0.6.2

在image: 这行上面增加一行: - --kubelet-insecure-tls

应用此YAML文件

kubectl apply -f high-availability-1.21+.yaml

创建HPA

vi hpa-php-apache.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1  ##最小Pod数为1
  maxReplicas: 10  ##最大Pod数为10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50  ##当Pod的CPU使用率超过50%时，需要自动扩容

应用YAML

kubectl apply -f hpa-php-apache.yaml

模拟php-apache Pod CPU使用率增加

再开一个终端，执行
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

回到原来终端查看hap和po

kubectl get deployment,po,hpa |egrep 'NAME|php-apache' ##php-apache Pod副本会逐渐增加，hpa的TARGETS列CPU使用率会越来越高，当超过50%就会自动生成新的Pod副本

API资源对象NetworkPolicy

NetworkPolicy用来控制Pod与Pod之间的网络通信，它也支持针对Namespace进行限制。基于白名单模式，符合规则的对象通过，不符合的拒绝。

应用场景举例：

• Pod A不能访问Pod B；
• 开发环境所有Pod不能访问测试命名空间的Pod；
• 提供对外访问时，限制外部IP；

官方NetworkPolicy YAML示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.1.0/24
        - namespaceSelector:
            matchLabels:
              project: myproject
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 6379
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 5978

说明：必需字段：apiVersion、 kind 和 metadata 字段。

podSelector：定义目标Pod的匹配标签，即哪些Pod会生效此策略；

policyTypes：表示给定的策略是应用于目标Pod的入站流量（Ingress）还是出站流量（Egress），或两者兼有。 如果NetworkPolicy未指定policyTypes则默认情况下始终设置Ingress。

ingress：定义入流量限制规则，from用来定义白名单对象，比如网段、命名空间、Pod标签，Ports定义目标端口。

egress：定义出流量限制规则，定义可以访问哪些IP和端口

案例一：

需求：tang命名空间下所有Pod可以互相访问，也可以访问其他命名空间Pod，但其他命名空间不能访问tang命名空间Pod。

首先创建几个Pod：

kubectl run busybox --image=busybox -- sleep 3600  ## default命名空间里创建busybox Pod
kubectl run busybox --image=busybox -n tang -- sleep 3600    ## tang命名空间里创建busybox Pod
kubectl run web --image=nginx:1.23.2 -n tang  ## tang命名空间里创建web pod

怎么查看ip：

kubectl get po -o wide

在没有创建NetworkPolicy的情况下测试：

kubectl exec busybox -n tang -- ping 10.18.213.18  ##tang命名空间的busybox ping default命名空间的busybox IP 
kubectl exec busybox -n tang -- ping 10.18.235.162 ##tang命名空间的busybox ping tang命名空间的web IP
kubectl exec busybox -- ping 10.18.235.162 ##default命名空间的busybox ping tang命名空间的web IP

创建networkpolicy的YAML

vi deny-all-namespaces.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-namespaces
  namespace: tang
spec:
  podSelector: {} # 为空，表示匹配本命名空间所有Pod
  policyTypes:
  - Ingress
  ingress:
    - from:
      - podSelector: {} # 为空，表示匹配该命名空间所有Pod，即允许该命名空间所有Pod访问，没有定义namespaceSelector，也就是说不允许其它namespace的Pod访问。

应用YAML

kubectl apply -f deny-all-namespaces.yaml

测试：

kubectl exec busybox -n tang -- ping 10.18.235.161  ##tang命名空间的busybox ping default命名空间的busybox IP
kubectl exec busybox -n tang -- ping 10.18.235.162 ##tang命名空间的busybox ping tang命名空间的web IP
kubectl exec busybox -- ping 10.18.235.162 ##default命名空间的busybox ping tang命名空间的web IP

将刚刚创建的所有资源删除：

kubectl delete po busybox  --force
kubectl delete po busybox -n tang --force
kubectl delete po web -n tang
kubectl delete -f deny-all-namespaces.yaml

案例二：

通过PodSelector限制

vi pod-selector.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-to-app
  namespace: tang
spec:
  podSelector:
    matchLabels:
      app: test
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: dev
      ports:
        - protocol: TCP
          port: 80

应用YAML

kubectl apply -f pod-selector.yaml

创建测试pod

kubectl run web01 --image=nginx:1.23.2 -n tang -l 'app=test'  #创建Pod时，指定label
kubectl get pod web01 -n tang --show-labels # 查看label
kubectl describe po web01 -n tang|grep -i label # 查看label
# 如果label创建错了，也可以修改，在本实验中不需要做如下操作 
# kubectl label pod busybox app=test123 --overwrite 
kubectl run app01 --image=nginx:1.23.2 -n tang -l 'app=dev' 
kubectl run app02 --image=nginx:1.23.2 -n tang  

查看web01的IP

kubectl describe po web01 -n tang |grep -i ip

怎么查看ip：

kubectl get po -n tang -o wide

测试

kubectl exec -n tang app01 -- curl 10.18.213.20
kubectl exec -n tang app02 -- curl 10.18.108.139

测试成功后，删除掉刚刚创建的资源

kubectl delete po app01 -n tang
kubectl delete po app02 -n tang
kubectl delete po web01 -n tang
kubectl delete -f pod-selector.yaml

案例三：

限制namespace

vi allow-ns.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ns
  namespace: tang
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: test
      ports:
        - protocol: TCP
          port: 80

应用YAML

kubectl apply -f allow-ns.yaml

创建测试ns

kubectl create ns test

创建测试pod

kubectl run web01 --image=nginx:1.23.2 -n tang
kubectl run web02 --image=nginx:1.23.2 -n test
kubectl run web03 --image=nginx:1.23.2 
kubectl run web04 --image=nginx:1.23.2 -n tang

查看web01的IP

kubectl describe po web01 -n tang |grep -i ip

查看ns label

kubectl get ns --show-labels

给ns设置标签

kubectl label namespace test name=test

测试：

kubectl -n test exec web02 -- curl 10.18.235.172  #可以访问
kubectl exec web03 -- curl 10.18.235.172 #不可以访问
kubectl -n tang exec web04 -- curl 10.18.235.172  #不可以访问，即使同一个命名空间也无法访问

Kubernetes用户安全控制

1）安全控制三阶段

三阶段： 认证（Authentication）、授权（Authorization）、准入控制（Admission Control）

① 所谓认证，就是先验证用户的身份是否合法，比如看看其证书是否合法有效，看看其Token是否正确；

② 所谓授权，就是看看这个用户是否有权限来访问或者操作K8s的资源；

③ 所谓准入控制，就是检查对应客户端的请求是否符合对应请求或操作API规范，检查传递参数是否是正确的。比如创建Pod，它会检查提交的信息是否符合创建Pod的规范，如果不符合规范就拒绝。另外，准入控制还会帮助我们把我们没有明确指定的字段信息，通过默认值的方式把对应的字段填充到客户端请求中，然后把填充好的信息一并由APIserver把客户端请求更新到对应资源在etcd中的对应信息上。

2）K8s认证（Authentication）

两种认证方式：

① Kubeconfig 这种是基于https ca证书认证，咱们命令行管理K8s用的就是这种认证

② Token 这种通过一个Token来识别用户，比如前面我们讲dashboard时，有创建一个serviceaccount，然后再获取其token

3）K8s授权（Authorization）

授权模式：

• AlwaysDeny：表示拒绝所有的请求，一般用于测试
• AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略
• ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制（老版本采用的方式，也就是定义属性的访问类型，如果用户拥有这个属性就能访问对应的资源。需要定义一长串的属性，并且ABAC修改完之后并不能生效，现在淘汰了）
• Webbook：通过调用外部 REST 服务对用户进行授权（在集群外部对集群鉴权）
• RBAC（Role-Based Access Control）：基于角色的访问控制，现行的默认规则（拥有角色就代表拥有访问资源某些权限）

查看你的K8s授权模式：

cat /etc/kubernetes/manifests/kube-apiserver.yaml |grep authorization-mode
    - --authorization-mode=Node,RBAC

RBAC 授权模式

RBAC（Role-Based Access Control）基于角色的访问控制，在 Kubernetes 1.5 中引入，现行版本成为默认标准。相对其它访问控制方式，拥有以下优势：

• 对集群中的资源（pod deploy cpu…）和非资源（元信息如pod状态）均拥有完整的覆盖
• 整个 RBAC 完全由几个 API 对象完成，同其它 API 对象一样，可以用 kubectl 或 API 进行操作
• 可以在运行时进行调整，无需重启API Server即可生效

RBAC 的 API 资源对象说明

RBAC资源对象：Subject（包括：User, Group, ServiceAccount）Role（角色）、ClusterRole（集群角色）、RoleBinding（角色绑定）、ClusterRoleBinding（集群角色绑定）

主体（subject）

• User：用户

• Group：用户组

• ServiceAccount：服务账号

角色

• Role：授权特定命名空间的访问权限

• ClusterRole：授权所有命名空间的访问权限

角色绑定

• RoleBinding：将角色绑定到主体（即subject）

• ClusterRoleBinding：将集群角色绑定到主体

4）K8s准入控制（Adminssion Control）

Adminssion Control实际上是一个准入控制器插件列表，发送到API Server的请求都需要经过这个列表中的每个准入控制器插件的检查，检查不通过，则拒绝请求。

查看可以启用的准入控制器列表：

kubectl exec kube-apiserver-tanglinux01 -n kube-system -- kube-apiserver -h | grep '  --enable-admission-plugins'

查看当前K8s启用的准入控制器：

grep 'admission' /etc/kubernetes/manifests/kube-apiserver.yaml
或者 
ps aux|grep apiserver|grep admission

更改准入控制器：

vi /etc/kubernetes/manifests/kube-apiserver.yaml  #找到--enable-admission-plugins那一行，直接修改

以下为admission控制器列表以及说明

Kubernetes创建普通用户示例

需求1：创建一个Role和ServiceAccount并把他们绑定起来。ServiceAccount有get、list、watch的权限

创建YAML文件

cat  > testsa.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: testsa

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: testsa-role
rules:
- apiGroups:  # api组，例如apps组，空值表示是核心API组，像namespace、pod、service、pv、pvc都在里面
  - ""
  resources: #资源名称（复数），例如pods, deployments, services
  - pods
  verbs: # 允许的操作，这里允许get, list, watch
  - get
  - list
  - watch

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: testsa-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: testsa-role
subjects:
- kind: ServiceAccount
  name: testsa
EOF

应用此YAML

kubectl apply -f testsa.yaml

生成token

kubectl create token testsa

需求2：

给user1用户授权tang命名空间Pod读取权限

① 生成ca证书

cd /etc/kubernetes/pki/

openssl genrsa -out user1.key 2048
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1"
openssl x509 -req -in user1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user1.crt -days 3650

② 生成kubeconfig授权文件

# 设置集群
kubectl config set-cluster myk8s \
--certificate-authority=/etc/kubernetes/pki/ca.crt \
--embed-certs=true \
--server=https://192.168.222.101:6443 \
--kubeconfig=/root/user1.kubecfg

# 查看user1配置，users和context都为空
kubectl config view --kubeconfig=/root/user1.kubecfg

# 设置客户端认证
kubectl config set-credentials user1 \
--client-key=user1.key \
--client-certificate=user1.crt \
--embed-certs=true \
--kubeconfig=/root/user1.kubecfg

# 查看user1配置，users有内容了
kubectl config view --kubeconfig=/root/user1.kubecfg

# 设置context
kubectl config set-context user1@myk8s \
--cluster=myk8s \
--user=user1 \
--kubeconfig=/root/user1.kubecfg

# 查看user1配置，context已经有内容了
kubectl config view --kubeconfig=/root/user1.kubecfg

# 切换context
kubectl config use-context user1@myk8s --kubeconfig=/root/user1.kubecfg

③ 创建角色

cat > user1-role.yaml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: tang
  name: user1-role
rules:
- apiGroups:  
  - ""
  resources:  
  - pods
  verbs: 
  - get
  - list
  - watch
EOF

kubectl apply -f user1-role.yaml

④ 将用户与角色绑定

cat > user1-rolebinding.yaml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: user1-rolebinding
  namespace: tang
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: user1-role
subjects:
- kind: User
  name: user1
  apiGroup: rbac.authorization.k8s.io
EOF

kubectl apply -f user1-rolebinding.yaml

⑤ 创建系统用户并使用user1的配置

useradd tang
mkdir /home/tang/.kube
cp /root/user1.kubecfg /home/tang/.kube/config
chown -R tang.tang /home/tang/.kube/

⑥ 切换到普通用下并访问k8s

su - tang
$ kubectl get po
$ kubectl get po -n tang
$ kubectl get deploy -n tang