工作中在调试集群中未包含bash sh等工具的pod往往比较麻烦，k8s提供了一个临时容器供我们添加到要调试的pod中进行工作。

什么是临时容器？

临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启， 因此不适用于构建应用程序。 临时容器使用与常规容器相同的 ContainerSpec 节来描述，但许多字段是不兼容和不允许的。

• 临时容器没有端口配置，因此像 ports，livenessProbe，readinessProbe 这样的字段是不允许的。
• Pod 资源分配是不可变的，因此 resources 配置是不允许的。
• 有关允许字段的完整列表，请参见 EphemeralContainer 参考文档。

临时容器是使用 API 中的一种特殊的 ephemeralcontainers 处理器进行创建的， 而不是直接添加到 pod.spec 段，因此无法使用 kubectl edit 来添加一个临时容器。

与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器。

使用临时容器需要开启 EphemeralContainers 特性门控， kubectl 版本为 v1.18 或者更高。

开启EphemeralContainers

master节点上操作

修改apiserver

我们能将 NFS (网络文件系统) 挂载到Pod 中,不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享，NFS 卷可以由多个pod同时挂载

注意： 在使用 NFS 卷之前，你必须运行自己的 NFS 服务器并将目标 share 导出备用。

虽然官方不是很推荐使用nfs存储作为pv,但是实际中我们有时候因为种种原因需要使用nfs类型的volume来存储数据。

下面介绍kubernetes中使用nfs作为存储卷的几种方式

1. 在deployment/statefulset中直接使用
2. 创建类型为nfs的持久化存储卷，用于为PersistentVolumClaim提供存储卷
3. 使用csi-driver-nfs提供StorageClass
4. 使用NFS Subdir External Provisioner提供StorageClass
5. 使用nfs-ganesha-server-and-external-provisioner提供StorageClass

我们事先在172.26.204.144机器上配置好了nfs server端，并共享了如下目录。

1
2
3
4

[root@node-02 ~]# showmount -e 172.26.204.144
Export list for 172.26.204.144:
/opt/nfs-deployment 172.26.0.0/16
/opt/kubernetes-nfs 172.26.0.0/16

在deployment/statefulset中直接使用

如下示例我们为nginx使用nfs作为存储卷持久化/usr/share/nginx/html目录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
      volumes:
      - name: data
        nfs:
          path: /opt/nfs-deployment
          server: 172.26.204.144

利用k8s审计日志生成RBAC规则

简介

很多时候我们在k8s上安装服务会遇到各种各样的权限问题，有时候为某个用户或者serviceaccount对象生成一个合适的role会比较头疼，这里推荐一个工具audit2rbac，它可以根据k8s的审计日志，为指定用户或者serviceaccount对象生成它们所需要的role.

audit2rbac下载地址： https://github.com/liggitt/audit2rbac/releases

前提要求

1、集群已经开启审计日志，且日志格式为json格式，开启审计日志可以参考https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#advanced-audit

2、建议日志级别设置为Metadata，还可以减少日志大小

使用

我们这里已经开启了审计日志，这里截取一小段日志内容如下：

1
2

{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"571b8d06-aa30-4aec-87cb-7bef2ef88d18","stage":"ResponseComplete","requestURI":"/apis/coordination.k8s.io/v1/namespaces/longhorn-system/leases/external-resizer-driver-longhorn-io","verb":"update","user":{"username":"system:serviceaccount:longhorn-system:longhorn-service-account","uid":"cdb0a05f-170d-4f02-aeec-88af904e68f7","groups":["system:serviceaccounts","system:serviceaccounts:longhorn-system","system:authenticated"]},"sourceIPs":["172.20.166.16"],"userAgent":"csi-resizer/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"leases","namespace":"longhorn-system","name":"external-resizer-driver-longhorn-io","uid":"81766194-e2e3-4edd-83d7-788a07562b91","apiGroup":"coordination.k8s.io","apiVersion":"v1","resourceVersion":"18772044"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2021-01-06T03:02:52.709670Z","stageTimestamp":"2021-01-06T03:02:52.710917Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"longhorn-bind\" of ClusterRole \"longhorn-role\" to ServiceAccount \"longhorn-service-account/longhorn-system\""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"0795fecc-38ea-46d7-a27d-6e73e6a27cd8","stage":"ResponseComplete","requestURI":"/apis/coordination.k8s.io/v1/namespaces/longhorn-system/leases/driver-longhorn-io","verb":"get","user":{"username":"system:serviceaccount:longhorn-system:longhorn-service-account","uid":"cdb0a05f-170d-4f02-aeec-88af904e68f7","groups":["system:serviceaccounts","system:serviceaccounts:longhorn-system","system:authenticated"]},"sourceIPs":["172.20.166.16"],"userAgent":"csi-provisioner/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"leases","namespace":"longhorn-system","name":"driver-longhorn-io","apiGroup":"coordination.k8s.io","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2021-01-06T03:02:52.713255Z","stageTimestamp":"2021-01-06T03:02:52.713894Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"longhorn-bind\" of ClusterRole \"longhorn-role\" to ServiceAccount \"longhorn-service-account/longhorn-system\""}}

简介

Permission manager是一个简单便捷的RBAC管理界面工具，支持通过web界面创建用户，分配Namespace权限，并可以生成kubeconfig文件

项目地址https://github.com/sighupio/permission-manager.git

安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

[root@master-01 k8s]# git clone https://github.com/sighupio/permission-manager.git 
正克隆到 'permission-manager'...
remote: Enumerating objects: 2350, done.
remote: Counting objects: 100% (593/593), done.
remote: Compressing objects: 100% (395/395), done.
remote: Total 2350 (delta 388), reused 349 (delta 189), pack-reused 1757
接收对象中: 100% (2350/2350), 10.79 MiB | 3.57 MiB/s, done.
处理 delta 中: 100% (1427/1427), done.
[root@master-01 k8s]# cd permission-manager/
[root@master-01 permission-manager]# ls
cmd          development              Dockerfile  e2e-test  go.sum      internal    Makefile   reltag.sh  tests
deployments  development-compose.yml  docs        go.mod    helm_chart  LICENSE.md  README.md  statik     web-client
##部署文件位于deployments/kubernetes下
[root@master-01 permission-manager]# ls deployments/kubernetes/
deploy.yml  seeds
[root@master-01 permission-manager]# ls deployments/kubernetes/seeds/
crd.yml  seed.yml

#

创建namespace

1

kubectl create namespace permission-manager

创建一个secert存储一些配置

1
2
3
4
5
6
7
8
9
10
11
12

---
apiVersion: v1
kind: Secret
metadata:
  name: permission-manager
  namespace: permission-manager
type: Opaque
stringData:
  PORT: "4000" # port where server is exposed
  CLUSTER_NAME: "my-cluster" # name of the cluster to use in the generated kubeconfig file
  CONTROL_PLANE_ADDRESS: "https://apiserver.cluster.local:6443" # full address of the control plane to use in the generated kubeconfig file
  BASIC_AUTH_PASSWORD: "changeMe" # password used by basic auth (username is `admin`)

参数解释：

简介

RBAC Manager是Fairwinds公司开源的一个项目，旨在简化 Kubernetes 中的授权，它使用新的自定义资源来支持 RBAC 声明式配置的c rd。我们可以指定所需的状态，而不是直接管理role bindings 或 service accounts ，RBAC Manager将进行必要的更改以实现该状态。

这个项目有三个主要目标：

1. 为 RBAC 提供一种更易于理解和可扩展的声明式方法。
2. 减少身份验证所需的配置量。
3. 使用 CI/CD 实现 RBAC 配置更新的自动化。

安装

安装我们可以使用helm安装或者使用直接使用yaml文件安装

helm安装

1
2

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install fairwinds-stable/rbac-manager --name rbac-manager --namespace rbac-manager

yaml文件安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[root@master-01 deploy]# git clone https://github.com/FairwindsOps/rbac-manager.git
[root@master-01 deploy]# cd rbac-manager/deploy
#我们先查看一下有哪些文件
[root@master-01 deploy]# ls
0_namespace.yaml  1_rbac.yaml  2_crd.yaml  3_deployment.yaml
##部署
[root@master-01 deploy]# kubectl apply -f ./
namespace/rbac-manager created
serviceaccount/rbac-manager created
clusterrole.rbac.authorization.k8s.io/rbac-manager created
clusterrolebinding.rbac.authorization.k8s.io/rbac-manager created
customresourcedefinition.apiextensions.k8s.io/rbacdefinitions.rbacmanager.reactiveops.io created
deployment.apps/rbac-manager created
[root@master-01 deploy]# kubectl -n rbac-manager  get pod
NAME                            READY   STATUS    RESTARTS   AGE
rbac-manager-664c9df47f-sjwwh   1/1     Running   0          48s

介绍

我们之前已经介绍了如何最小化安装kubesphere 以及 接入自定义的prometheus监控，这里看一下kubeshere中的多租户，多租户是我们实际生产使用中很需要的一个功能，这样能满足我们不同用户去登陆kubesphere平台，比如我们开发，运维，测试同学都需要登陆kubesphere平台，并且我们需要为不同身份的同学配置不同的权限，当公司内需要访问kubesphere的同学比较多时，管理员再去手动的为用户创建账号就比较呆板了，KubeSphere 包含一个内置的 OAuth 服务和帐户系统。用户通过获取 OAuth 访问令牌以对 API 进行身份验证，我们可以通过接入ldap或者oidc来提供身份认证信息。

多租户方案

认证鉴权链路

使用

集群内已经最小化安装kubesphere，安装可以参考kubesphere 3.1.1 接入自定义 Prometheus

我们这里使用oidc身份提供者进行认证，通过dex接入到我们的gitlab中，使用我们gitlab中的用户完成认证。

安装dex

简介

cert-manager 是一个云原生证书管理开源项目，用于在 Kubernetes 集群中自动管理和颁发来自各种颁发源的 TLS 证书，它可以从各种受支持的来源颁发证书，包括 Let’s Encrypt、HashiCorp Vault和Venafi以及私有 PKI，它将确保证书定期有效和更新，并在到期前的适当时间尝试更新证书。

架构

Issuers/ClusterIssuers：定义使用 什么证书颁发机构 (CA) 来去颁发证书，Issuers和ClusterIssuers区别是issuers是一个名称空间级别的资源， 只能用来签发自己所在 namespace 下的证书，ClusterIssuer是个集群级别的资源 可以签发任意 namespace 下的证书

Certificate：定义所需的 X.509 证书，该证书将更新并保持最新。Certificate是一个命名空间资源，当Certificate被创建时，它会去创建相应的CertificateRequest资源来去申请证书。

安装

安装cert-manager相对比较简单，这里安装的cert-manager版本为v1.4，注意该版本要求kubectl版本>= v1.19.0-rc.1

所有资源（CustomResourceDefinitions和 cert-manager、cainjector 和 webhook 组件）都包含在一个 YAML 清单文件中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

wget https://github.com/jetstack/cert-manager/releases/download/v1.4.0/cert-manager.yaml
root@i-tsfhx8p6:~/qke-k8s/cert-manager# vi cert-manager.yaml
root@i-tsfhx8p6:~/qke-k8s/cert-manager# kubectl apply -f cert-manager.yaml 
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io created
namespace/cert-manager unchanged
serviceaccount/cert-manager-cainjector created
serviceaccount/cert-manager created
serviceaccount/cert-manager-webhook created
clusterrole.rbac.authorization.k8s.io/cert-manager-cainjector created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-issuers created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-clusterissuers created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-certificates created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-orders created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-challenges created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-ingress-shim created
clusterrole.rbac.authorization.k8s.io/cert-manager-view created
clusterrole.rbac.authorization.k8s.io/cert-manager-edit created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-approve:cert-manager-io created
clusterrole.rbac.authorization.k8s.io/cert-manager-controller-certificatesigningrequests created
clusterrole.rbac.authorization.k8s.io/cert-manager-webhook:subjectaccessreviews created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-cainjector created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-issuers created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-clusterissuers created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-certificates created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-orders created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-challenges created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-ingress-shim created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-approve:cert-manager-io created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-controller-certificatesigningrequests created
clusterrolebinding.rbac.authorization.k8s.io/cert-manager-webhook:subjectaccessreviews created
role.rbac.authorization.k8s.io/cert-manager-cainjector:leaderelection created
role.rbac.authorization.k8s.io/cert-manager:leaderelection created
role.rbac.authorization.k8s.io/cert-manager-webhook:dynamic-serving created
rolebinding.rbac.authorization.k8s.io/cert-manager-cainjector:leaderelection created
rolebinding.rbac.authorization.k8s.io/cert-manager:leaderelection created
rolebinding.rbac.authorization.k8s.io/cert-manager-webhook:dynamic-serving created
service/cert-manager created
service/cert-manager-webhook created
deployment.apps/cert-manager-cainjector created
deployment.apps/cert-manager created
deployment.apps/cert-manager-webhook created
mutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created
validatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

kubesphere 3.1.1 接入自定义 Prometheus

千呼万唤始出来，KubeSphere 3.1.1 终于可以接入自定义 Prometheus 了，以前虽然也支持集成自己的prometheus,但是我们来看下KubeSphere 3.1.1 之前集成自己的prometheus的步骤

1. 卸载 KubeSphere 的自定义 Prometheus 堆栈
2. 安装您自己的 Prometheus 堆栈
3. 将 KubeSphere 自定义组件安装至您的 Prometheus 堆栈
4. 更改 KubeSphere 的 monitoring endpoint

这个步骤，给我的感觉就一个，脱裤子放屁，一点都不优雅，接下来我们试一下使用最新的KubeSphere 3.1.1直接接入自定义的Prometheus

首先这个kubernetes集群里已经安装了prometheus-operator ，位于monitoring 这个namaspace

最小化部署kubesphere

下载配置文件

1
2

wget https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
wget https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml

官方默认提供的cluster-configuration.yaml是一个最小化安装的配置文件，下面是修改后的文件：

文章中使用harbor版本为v2.2.0

因为种种原因(甲方爸爸牛逼）导致 harbor 无法直接使用证书提供https访问，于是被迫采用阿里云的负载均衡slb，使用slb的https方式代理访问后端的http协议的harbor ,证书配置到slb上，如下：

user---->slb（HTTPs）-->harbor（http) --> core/protal/registry

使用这种方式我们配置harbor.yml文件时，需要把https段配置注释，否则会发生http自动重定向到https，导致循环重定向，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Configuration file of Harbor

# The IP address or hostname to access admin UI and registry service.
# DO NOT use localhost or 127.0.0.1, because Harbor needs to be accessed by external clients.
hostname: XXXXX.XXX.XXX:8443

# http related config
http:
  # port for http, default is 80. If https enabled, this port will redirect to https port
  port: 8443

# https related config
#https:
  # https port for harbor, default is 443
 # port: 8443
  # The path of cert and key files for nginx
  #certificate: /your/certificate/path
  #private_key: /your/private/key/path

我们的gitlab ci 是使用google的kaniko进行镜像的打包上传：

1

/kaniko/executor --context="$PWD" --dockerfile="$PWD/Dockerfile" --destination="$HARBOR_IMAGE_TAG"

使用过程中发现有时候会出现

我手动执行push命令发现如下报错

简介

Kubernetes 默认情况下使用 cAdvisor 来收集容器的各项指标，足以满足大多数人的需求，但还是有所欠缺，比如缺少对以下几个指标的收集：

• OOM kill
• 容器重启的次数
• 容器的退出码

missing-container-metrics 这个项目弥补了 cAdvisor 的缺陷，新增了以上几个指标，集群管理员可以利用这些指标迅速定位某些故障。例如，假设某个容器有多个子进程，其中某个子进程被 OOM kill，但容器还在运行，如果不对 OOM kill 进行监控，管理员很难对故障进行定位。

安装

官方提供了helm chart方式来进行安装，我们先添加helm仓库

1

helm repo add missing-container-metrics https://draganm.github.io/missing-container-metrics

把这个chart下载到本地，我们需要修改value.yaml文件

1
2
3
4
5

[root@master-01 addons]# helm pull missing-container-metrics/missing-container-metrics
[root@master-01 addons]# ls
blackbox        dingtalk  harbor_exporter                      mysql-exporter    prometheusalert  rules                          servicemonitor  victoriametrics
blackbox-probe  etcd      missing-container-metrics-0.1.1.tgz  process-exporter  redis-exporter   scheduler-controller-svc.yaml  ssl-exporter
[root@master-01 addons]# tar xf  missing-container-metrics-0.1.1.tgz 

可配置项