K8S/Kubernetes

1 部署dashboard

1. K8S证书

1.1. SSL和TLS

传输层安全性协议(Transport Layer Security，缩写：TLS)及其前身安全套接层(Secure Sockets Layer，缩写：SSL)是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。

SSL设计之初主要用于web通信过程中的密钥的非对称加密和校验，互联网工程任务组(Internet Engineering Task Force，缩写：IETF)将SSL标准化，并将其称为TLS(Transport Layer Security)。

1.2. 证书

1.2.1. 证书标准

X.509 数字证书标准，定义证书文件的结构和内容，详情参考 RFC5280。SSL 数字证书通常采用这种标准，一般由用户公共密钥和用户标识符组成，此外还包括版本号、证书序列号、CA 标识符、签名算法标识、签发者名称、证书有效期等信息。一个 X.509 标准的 SSL 数字证书包含(但不限于)以下的字段：

字段	说明
Suject Name	证书持有者的相关信息(国家/地区、组织、单位、CN)
Issuer Name	证书颁发者的相关信息(国家/地区、组织、单位、CN)
Common Name	Subject Name 和 Issuer Name 信息里都包含一个常用名称字段(Common Name, CN)，对于 CA 证书而言，该字段表示 CA 机构的名称，对于用户证书而言，通常是相应的域名。
Serial Number	CA 机构给该证书的唯一序列号
Not Valid Before	证书生效日期
Not Valid After	证书失效日期
Public Key	服务端公开的密钥(RSA 公钥)
Signature Algorithm	签名所使用的算法(SHA-1，SHA-256 等)
Signature	CA 机构给该证书的签名，用于验证证书是否被篡改

1.2.2. 证书编码格式

• PEM编码格式

Privacy Enhanced Mail 的缩写，以文本的方式进行存储。它的文件结构以 -----BEGIN XXX-----，并以 -----END XXX----- 结尾，中间 Body 内容为 Base64 编码过的数据！它也可以用来编码存储公钥(RSA PUBLIC KEY)、私钥(RSA PRIVATE KEY)、证书签名请求(CERTIFICATE REQUEST)等数据。Nginx/Apache等常用的Linux服务大多采用该格式。

• DER编码格式

Distinguished Encoding Rules 的缩写，以二进制方式进行存储，文件结构无法直接预览。一般 Java 和 Windows 服务器应用偏向于使用 DER 这种编码格式。

• 预览和转换证书内容

# OpenSSL
openssl x509 -in xxx.pem -text -noout  # 查看pem编码文件
openssl x509 -in xxx.der -inform der -text -noout  # 预览der编码文件
openssl x509 -in xxx.pem -outform der -out xxx.der # pem 转 der
openssl x509 -in xxx.der -inform der -outform pem -out xxx.pem  # der 转 pem

常见的证书文件后缀

.key    一般指的是私钥，通常用RSA算法比较多
.pem    采用pem编码格式的x.509证书格式
.der    采用der编码格式的x.509证书格式
.crt    证书文件,采用pem或者der编码格式的证书。一般常见于Unix系统，采用pem编码格式较多
.cer    证书文件,采用pem或者der编码格式的证书。一般常见于windows系统，采用der编码格式较多
.csr    证书前面请求文件，是向CA申请证书时使用

证书的创建和查看

# 创建证书
k8s集群安装: https://www.yuque.com/duduniao/ww8pmw/tr3hch
官方文档: https://kubernetes.io/zh/docs/concepts/cluster-administration/certificates

# 证书内容查看
openssl x509 -in xxx.pem -text -noout
openssl rsa -in xxx.key -text -noout

1.1 获取dashboard镜像

获取镜像和创建资源配置清单的操作,还是老规矩:7.200上操作

1.1.1 获取1.8.3版本的dsashboard

docker pull k8scn/kubernetes-dashboard-amd64:v1.8.3
docker tag  k8scn/kubernetes-dashboard-amd64:v1.8.3 harbor.od.com/public/dashboard:v1.8.3
docker push harbor.od.com/public/dashboard:v1.8.3

1.1.2 获取1.10.1版本的dashboard

docker pull loveone/kubernetes-dashboard-amd64:v1.10.1
docker tag  loveone/kubernetes-dashboard-amd64:v1.10.1 harbor.od.com/public/dashboard:v1.10.1
docker push harbor.od.com/public/dashboard:v1.10.1

1.1.3 为何要两个版本的dashbosrd

• 1.8.3版本授权不严格,方便学习使用
• 1.10.1版本授权严格,学习使用麻烦,但生产需要

1.2 创建dashboard资源配置清单

mkdir -p /data/k8s-yaml/dashboard

1.2.1 创建rbca授权清单

cat >/data/k8s-yaml/dashboard/rbac.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
    addonmanager.kubernetes.io/mode: Reconcile
  name: kubernetes-dashboard-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard-admin
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard-admin
  namespace: kube-system
EOF

1.2.2 创建depoloy清单

cat >/data/k8s-yaml/dashboard/dp.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  selector:
    matchLabels:
      k8s-app: kubernetes-dashboard
  template:
    metadata:
      labels:
        k8s-app: kubernetes-dashboard
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      priorityClassName: system-cluster-critical
      containers:
      - name: kubernetes-dashboard
        image: harbor.od.com/public/dashboard:v1.8.3
        resources:
          limits:
            cpu: 100m
            memory: 300Mi
          requests:
            cpu: 50m
            memory: 100Mi
        ports:
        - containerPort: 8443
          protocol: TCP
        args:
          # PLATFORM-SPECIFIC ARGS HERE
          - --auto-generate-certificates
        volumeMounts:
        - name: tmp-volume
          mountPath: /tmp
        livenessProbe:
          httpGet:
            scheme: HTTPS
            path: /
            port: 8443
          initialDelaySeconds: 30
          timeoutSeconds: 30
      volumes:
      - name: tmp-volume
        emptyDir: {}
      serviceAccountName: kubernetes-dashboard-admin
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
EOF

1.2.3 创建service清单

cat >/data/k8s-yaml/dashboard/svc.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  selector:
    k8s-app: kubernetes-dashboard
  ports:
  - port: 443
    targetPort: 8443
EOF

1.2.4 创建ingress清单暴露服务

cat >/data/k8s-yaml/dashboard/ingress.yaml <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
  - host: dashboard.od.com
    http:
      paths:
      - backend:
          serviceName: kubernetes-dashboard
          servicePort: 443
EOF

1.3 创建相关资源

1.3.1 在任意node上创建

kubectl create -f http://k8s-yaml.od.com/dashboard/rbac.yaml
kubectl create -f http://k8s-yaml.od.com/dashboard/dp.yaml
kubectl create -f http://k8s-yaml.od.com/dashboard/svc.yaml
kubectl create -f http://k8s-yaml.od.com/dashboard/ingress.yaml

1.3.2 添加域名解析

vi /var/named/od.com.zone
dashboard          A    10.4.7.10
# 注意前滚serial编号

systemctl restart named

1.3.3 通过浏览器验证

在本机浏览器上访问http://dashboard.zq.com,如果出来web界面,表示部署成功

可以看到安装1.8版本的dashboard，默认是可以跳过验证的：

2 升级dashboard版本

跳过登录是不科学的，因为我们在配置dashboard的rbac权限时，绑定的角色是system:admin，这个是集群管理员的角色，权限很大，如果任何人都可跳过登录直接使用,那你就等着背锅吧

2.1 把版本换成1.10以上版本

在前面我们已经同时下载了1.10.1版本的docker镜像

2.1.1 在线修改直接使用

kubectl edit deploy kubernetes-dashboard -n kube-system

2.2.2 等待滚动发布

[root@hdss7-21 ~]# kubectl -n kube-system get pod|grep dashboard
kubernetes-dashboard-5bccc5946b-vgk5n   1/1     Running       0          20s
kubernetes-dashboard-b75bfb487-h7zft    0/1     Terminating   0          2m27s
[root@hdss7-21 ~]# kubectl -n kube-system get pod|grep dashboard
kubernetes-dashboard-5bccc5946b-vgk5n   1/1     Running   0          52s

2.2.3 刷新dashboard页面：

可以看到这里原来的skip跳过已经没有了，我们如果想登陆，必须输入token，那我们如何获取token呢：

2. DashBoard账户授权

Dashboard的登陆有两种形式，一种是使用 Token，另一种是使用 kube-config 文件，但是两种方式都需要使用ServiceAccount。

2.2 使用token登录

2.2.1 首先获取secret资源列表

kubectl get secret  -n kube-system

2.2.2 获取角色的详情

列表中有很多角色,不同到角色有不同的权限,找到想要的角色dashboard-admin后,再用describe命令获取详情

kubectl -n kube-system describe secrets kubernetes-dashboard-admin-token-85gmd

找到详情中的token字段,就是我们需要用来登录的东西

拿到token去尝试登录,发现仍然登录不了,因为必须使用https登录,所以需要申请证书

2.2.3 申请证书

申请证书在7.200主机上

创建json文件:

cd /opt/certs/
cat >/opt/certs/dashboard-csr.json <<EOF
{
    "CN": "*.od.com",
    "hosts": [
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "beijing",
            "L": "beijing",
            "O": "od",
            "OU": "ops"
        }
    ]
}
EOF

申请证书

cfssl gencert -ca=ca.pem \
      -ca-key=ca-key.pem \
      -config=ca-config.json \
      -profile=server \
      dashboard-csr.json |cfssl-json -bare dashboard

查看申请的证书

[root@hdss7-200 certs]# ll |grep dash
-rw-r--r-- 1 root root  993 May  4 12:08 dashboard.csr
-rw-r--r-- 1 root root  280 May  4 12:08 dashboard-csr.json
-rw------- 1 root root 1675 May  4 12:08 dashboard-key.pem
-rw-r--r-- 1 root root 1359 May  4 12:08 dashboard.pem

2.2.4 前端nginx服务部署证书

在7.11,7.12两个前端代理上,都做相同操作

拷贝证书:

mkdir /etc/nginx/certs
scp 10.4.7.200:/opt/certs/dashboard.pem /etc/nginx/certs
scp 10.4.7.200:/opt/certs/dashboard-key.pem /etc/nginx/certs

创建nginx配置

cat >/etc/nginx/conf.d/dashboard.zq.com.conf <<'EOF'
server {
    listen       80;
    server_name  dashboard.zq.com;

    rewrite ^(.*)$ https://${server_name}$1 permanent;
}
server {
    listen       443 ssl;
    server_name  dashboard.zq.com;

    ssl_certificate     "certs/dashboard.pem";
    ssl_certificate_key "certs/dashboard-key.pem";
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout  10m;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://default_backend_traefik;
        proxy_set_header Host       $http_host;
        proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
    }
}
EOF

重启nginx服务

nginx -t
nginx -s reload

2.2.5 再次登录dashboard

刷新页面后,再次使用前面的token登录,可以成功登录进去了

2.3 授权细则思考

登录是登录了，但是我们要思考一个问题，我们使用rbac授权来访问dashboard,如何做到权限精细化呢？比如开发，只能看，不能摸，不同的项目组，看到的资源应该是不一样的，测试看到的应该是测试相关的资源。