Author: studyk8s

Rancher 网站证书配置

在使用helm在已经存在的Kubernetes集群上安装 rancher HA 时，

有3种https模式可选，如果可以使用的话，LET’S ENCRYPT 模式无疑是最简单的方式，LET’S ENCRYPT甚至可以通过cert-manager在证书过期之前，自动更新免费证书，非常的方便。

但是有的时候收到网络环境，或者是客户的额外要求时，就需要手动更新或者设置证书

此处在安装时选择的是 RANCHER-GENERATED CERTIFICATES

在这种模式下 rancher 会自己创建mockup的自管理证书

可以看到 Not secure 提示 以及自管理的证书的细节

我们知道 rancher的网页服务本身就是基于 ingress 暴露的

所以只需要把证书配置到对应的 ingress 上就可以了

上图中可以看到 这个ingress 使用的 cert 是 tls-rancher-ingress

来创建一个新证书的 secret

然后重新指定rancher ingress的cert配置

更新证书

./rke cert rotate

证书已经更新

Kubernetes Downward API

在Kubernetes环境中，因为容器是被动态分配到节点上的，也就是说在容器启动之前，无法知道运行环境的具体信息

那如何在程序中获得当前容器的 pod ip 呢？又或者是 当前容器的 内存限制呢？

Kubernetes 使用 Downward API 通过环境变量和文件，将有关Pod的元数据注入到容器和集群中。

apiVersion: v1
kind: Pod
metadata:
  name: getpodip
spec:
  containers:
  - image: nginx
    name: getpodip
    env: 
    - name: POD_IP
      valueFrom:
        fieldRef: 
          fieldPath: status.podIP
    - name: MEM_LIMITS
      valueFrom:
        resourceFieldRef: 
          containerName: getpodip
          resource: limits.memory

不过由于环境变量无法在容器启动之后更改，也可以将信息挂载到磁盘卷上，这样每次修改之后，程序可以通过重新读取文件内容，更新这些信息

apiVersion: v1
kind: Pod
metadata:
  name: getpodip
spec:
  containers:
  - image: nginx
    name: getpodip
    volumeMounts:
      - name: pod-info
        mountPath: /pod-info
        readOnly: true
      - name: pod-resource
        mountPath: /pod-resource
        readOnly: true
  volumes:
    - name: pod-info
      downwardAPI:
        items:
          - path: POD_IP
            fieldRef: 
              fieldPath: metadata.name
    - name: pod-resource
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: getpodip
              resource: limits.cpu
              divisor: 1m
          - path: "cpu_request"
            resourceFieldRef:
              containerName: getpodip
              resource: requests.cpu
              divisor: 1m
          - path: "mem_limit"
            resourceFieldRef:
              containerName: getpodip
              resource: limits.memory
              divisor: 1Mi
          - path: "mem_request"
            resourceFieldRef:
              containerName: getpodip
              resource: requests.memory
              divisor: 1Mi

不过不知道为什么这里 metadata.name 无法替换为 status.podIP

The Pod "getpodip" is invalid: 
* spec.volumes[0].downwardAPI.fieldRef.fieldPath: Unsupported value: "status.podIP": supported values: "metadata.annotations", "metadata.labels", "metadata.name", "metadata.namespace", "metadata.uid"
* spec.containers[0].volumeMounts[0].name: Not found: "pod-info"

• Env vars using valueFrom.fieldRef:
  •  spec.nodeName – the node’s name
  •  status.hostIP – the node’s IP
  •  metadata.name – the pod’s name
  •  metadata.namespace – the pod’s namespace
  •  status.podIP – the pod’s IP address
  •  spec.serviceAccountName – the pod’s service account name
  •  metadata.uid – the pod’s UID
  •  metadata.labels[”] – the value of the pod’s label (for example, metadata.labels[‘mylabel’])
  •  metadata.annotations[”] – the value of the pod’s annotation (for example, metadata.annotations[‘myannotation’])
• DownwardAPI volumes via items of fieldRef:
  •  spec.nodeName – the node’s name
  •  status.hostIP – the node’s IP
  •  metadata.name – the pod’s name
  •  metadata.namespace – the pod’s namespace
  •  status.podIP – the pod’s IP address
  •  spec.serviceAccountName – the pod’s service account name
  •  metadata.uid – the pod’s UID
  •  metadata.labels- the value of the pod’s label (for example, metadata.labels[‘mylabel’])
  •  metadata.annotations – the value of the pod’s annotation (for example, metadata.annotations[‘myannotation’])

Kubernetes Secret 安全么

如果要在 kubernetes 保存密码，你一定会想到要使用 secret

  docker-registry Create a secret for use with a Docker registry
  generic         Create a secret from a local file, directory or literal value
  tls             Create a TLS secret

secret分为以上3种，我们来创建一个 generic 类型的 secret 来保存一个密码

kubectl create secret generic secretname --from-literal="mykey=myvalue"

通过以下命令，可以简单查看这个 secret

kubectl get secret secretname -o jsonpath='{.data}'

secret保存base64编码的数据，并在解码后将其作为环境变量或挂载卷提供给pod使用

所以经常有人误认为secret是安全的，然而base64编码不是加密方法，从安全角度上看，它和纯文本没有区别。

echo 'bXl2YWx1ZQ==' | base64 --decode

实际上，secret的安全性在于

• 只有运行了需要访问secret的pod的节点，才会拥有 secret
• 在节点上，secret存储在tmpfs内存中，永远不会写入物理内存，而且会随着 pod 一起删除

tmpfs有以下优势：

1。动态文件系统的大小，/dev /shm/需要注意的一个是容量问题，在linux下，它默认最大为内存的一半大小，使用df -h命令可以看到。但它并不会真正的占用这块内存，如果/dev/shm/下没有任何文件，它占用的内存实际上就是0字节；如果它最大为1G，里头放有 100M文件，那剩余的900M仍然可为其它应用程序所使用，但它所占用的100M内存，是绝不会被系统回收重新划分的
2。tmpfs 的另一个主要的好处是它闪电般的速度。因为典型的 tmpfs 文件系统会完全驻留在 RAM 中，读写几乎可以是瞬间的。
3。tmpfs 数据在重新启动之后不会保留，因为虚拟内存本质上就是易失的。所以有必要做一些脚本做诸如加载，绑定的操作。

这里我创建一个 nginx 部署，挂载刚刚创建的secret

这个pod被分配在节点2上

Secret 的大小不能超过1MB，不能用于存储太大的数据，也不适合作为非配置类型的数据。

因为Base64编码，存储的数据大约只能有700kb

Build docker image from a Kubernetes installed Jenkins

因为默认的 jnlp image 是不包含 docker 命令的，所以这里需要自己先打一个安装docker 的 jnlp

FROM jenkins/jnlp-slave:latest

USER root
RUN apt update && apt install -y curl
RUN curl https://releases.rancher.com/install-docker/20.10.sh | sh
RUN usermod -aG docker jenkins

USER jenkins
ENTRYPOINT ["/usr/local/bin/jenkins-agent"]

这里为了方便我放开了 docker.sock的全部权限

sudo chmod 777 /var/run/docker.sock

关于jenkins的安装请参考

NFS Provisioner

Install Jenkins on Kubernetes

编写pipeline

pipeline {
    agent {
        kubernetes {
            label 'jenkins-slave'
            yaml '''
apiVersion: v1
kind: Pod
metadata:
  name: jenkins-slave
spec:
  containers:
    - name: jnlp
      image: libaibai/lz-jnlp-slave:4.6.1
      securityContext:
        privileged: true
      imagePullPolicy: IfNotPresent
      env:
      - name: JENKINS_URL
        value: http://10.43.113.251:8080
      - name: JENKINS_AGENT_WORKDIR
        value: /tmp
      volumeMounts:
        - mountPath: /var/run/docker.sock
          name: docker-sock
        - name: jenkins-docker-cfg
          mountPath: /root/.docker
      workingDir: /home/jenkins
      resources:
          limits:
            cpu: 100m
            memory: 200Mi
  restartPolicy: Never
  volumes:
    - name: docker-sock
      hostPath:
        path: /var/run/docker.sock
    - name: jenkins-docker-cfg
      projected:
        sources:
        - secret:
            name: regcred
            items:
              - key: .dockerconfigjson
                path: config.json
'''
        }
    }
    stages{
        stage('get code'){
            steps{
                echo 'getted the code...'
                sh "/usr/bin/docker info"
                timeout(time: 2, unit: 'HOURS'){
                    dir('sourcecodes') {
                        git credentialsId: '0559259b-d672-457f-8d2e-d3925c412d70', url: 'https://github.com/zl86790/kanikotest.git'
                    }
                    sh "docker build -f /home/jenkins/agent/workspace/helloworld2/sourcecodes/Dockerfile -t libaibai/useless ."
                }
            }
        }
        stage('push image'){
            steps{
                echo 'push image...'
                sh "/usr/bin/docker info"
                timeout(time: 2, unit: 'HOURS'){
                    withDockerRegistry([ credentialsId: "3182bbdd-fd4d-4497-b262-c882b7ac0ee9", url: "" ]) {
                        sh "docker push libaibai/useless"
                    }
                }
            }
        }
     }
}     

NFS Provisioner

这里使用的是 ranchercharts/kubernetes_incubator-nfs-provisioner:v2.2.1-k8s1.12

rancher 提供的这个 helm 会把 share 路径固定到 node 节点的 /srv

这个 helm 最方便的地方在于，它可以直接帮你创建一个 storage class

创建一个1GB的PVC 来测试这个 class

创建一个 pod

apiVersion: v1
kind: Pod
metadata:
  name: test-storageclass-pod
  namespace: lizhe
spec:
  containers:
  - name: busybox
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    command:
    - "/bin/sh"
    - "-c"
    args:
    - "sleep 3600"
    volumeMounts:
    - name: nfs-pvc
      mountPath: /mnt
  restartPolicy: Never
  volumes:
  - name: nfs-pvc
    persistentVolumeClaim:
      claimName: test-nfs-pvc

mount 成功

Install Jenkins on Kubernetes

由于helm的存在，似的Jenkins在Kubernetes上的安装极为简单

这里需要修改 global.storageClass

在 NFS Provisioner 一节中，我们已经创建了一个 NFS 服务并且自动安装了一个 storage class

这里可以看到 Jenkins 已经初始化了一个 8GB 大小的 PVC，并且使用了节点机的 SRV

创建一个 nodeport

bitnami版本的 jenkins 其实有一个大坑

默认的 jenkins 用户一般都是 admin，特殊情况下有 root，但是 bitnami 初始化的用户名竟然是

user

最后，你终于可以登录了

Kaniko on Kubernetes Jenkins

kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster.

kaniko doesn’t depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. This enables building container images in environments that can’t easily or securely run a Docker daemon, such as a standard Kubernetes cluster.

kaniko is meant to be run as an image: gcr.io/kaniko-project/executor. We do not recommend running the kaniko executor binary in another image, as it might not work.

https://github.com/GoogleContainerTools/kaniko

在之前安装的jenkins上配置 cloud，添加kubernetes，测试连接会得到以下错误

提示没有足够的权限来操作pods

这里我们需要添加RBAC权限配置，可以参考 Api server 认证机制

kubectl create clusterrolebinding permissive-binding --clusterrole=cluster-admin --group=system:serviceaccounts:jenkins

创建RBAC权限之后，jenkins有了集群的管理权限

创建jenkins从 git 上 clone 代码用的账户

因为 kaniko 会直接将build好的 image push 到明明的目标仓库，所以这里需要创建 dockerhub 使用的regcred

kubectl create secret docker-registry regcred --docker-server=https://index.docker.io/v1/ --docker-username=YOURNAME --docker-password=YOURPASSWORD --docker-email=YOUREMAIL@ADDRESS -n jenkins

创建一个叫 helloworld 的 pipeline job

def label = "mypod-${UUID.randomUUID().toString()}"
podTemplate(label: label, yaml: """
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:debug
    imagePullPolicy: Always
    command:
    - /busybox/cat
    tty: true
    volumeMounts:
      - name: jenkins-docker-cfg
        mountPath: /root
  volumes:
  - name: jenkins-docker-cfg
    projected:
      sources:
      - secret:
          name: regcred
          items:
            - key: .dockerconfigjson
              path: .docker/config.json
"""
) {
    node(label) {
    stage('Build with Kaniko') {
      sh label: '', script: 'free -m'
      timeout(time: 2, unit: 'HOURS'){
        dir('sourcecodes') {
          git credentialsId: '0559259b-d672-457f-8d2e-d3925c412d70', url: 'https://github.com/zl86790/kanikotest.git'
        }
      }


      container(name: 'kaniko', shell: '/busybox/sh') {
        withEnv(['PATH+EXTRA=/busybox:/kaniko']) {
          sh '''#!/busybox/sh
          pwd
          ls /home/jenkins/agent/workspace/helloworld/sourcecodes/
          /kaniko/executor -f /home/jenkins/agent/workspace/helloworld/sourcecodes/Dockerfile -c `pwd` --destination=libaibai/kanikotest:test0.1
          '''
        }
      }
    }
  }
}

尝试启动一个job

出现无法reach到服务器的错误

tcpSlaveAgentListener/: Host is unreachable (Host unreachable)

这里主要是我的 k8s2.me 是一个 /etc/hosts 填写的本地DNS，所以解析不到，换成clusterip

再次尝试启动 job

提示 tcpSlaveAgentListener 404 找不到

java.io.IOException: http://10.43.113.251:8080/tcpSlaveAgentListener/ is invalid: 404 Not Found

然后我们去打开这个 agent

再次启动job

还是错误，端口50000 连不上

SEVERE: http://10.43.113.251:8080/ provided port:50000 is not reachable

java.io.IOException: http://10.43.113.251:8080/ provided port:50000 is not reachable

这个错误就比较容易处理了，在 clusterip 的 service 上，把50000端口暴露出来

再次启动job，终于成功了

在job执行结束后，可以看到 pod 被remove掉了

可以看到image已经上传成功了