Month: March 2021

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已经上传成功了

Linux network namespace

如果你熟悉docker的namespace隔离机制，你应该知道docker的network也是通过 namespace隔离的

要了解kubernetes的网络原理，不得不提到 linux 的network namespace

Linux的 namespace 的作用是 隔离内核资源，命名空间会给其中的进程造成两个错觉

1. 它是系统内唯一的进程

2. 它独享系统的所有资源

network namespace是从 2.6 开始引入的，作用是隔离 Linux 系统的设备，ip 地址、端口、路由表 和 防火墙规则等网络资源

创建一个名为 netns1 的 新命名空间

sudo ip netns add netns1

当 ip 命令 创建了一个 新命名空间 之后，系统会在 /var/run/netns 目录下生成一个新的挂载点

挂载点的作用在于一方面是为了方便 命名空间管理，另一个方面是使 命名空间  可以在没有进程运行时也能继续存在

删除命令并不会直接删除这个命名空间，它只是移除了挂载点，这样只要命名空间中仍然有进程运行，它就会一直存在

当 namespace 中的进程 涉及到网络通信时，它就需要一个虚拟网络设备 ，一个全新的 namespace 会附带创建一个 本地回环地址，上面的截屏中我们已经看到了。

不过需要注意的是，默认创建的网卡并没有默认启动

sudo ip netns exec netns1 ip link set dev lo up

仅有一个回环网卡是无法与外部通信的，之前在旧版本的 docker 上我使用过 veth pair，这里是一样的套路

veth pair 总是成对出现的，报文从一端进去，从另一端出来

这里我在宿主机上 创建两个端点， veth_left 和 veth_right

然后把 veth_left 绑定到 netns1 , 把 veth_right 绑定到（留给，默认就是在宿主机上创建的）当前宿主机

lizhe@ubuntu:~$ sudo ip link add veth_left type veth peer name veth_right
lizhe@ubuntu:~$ sudo ip link set veth_left netns netns1
lizhe@ubuntu:~$ 
lizhe@ubuntu:~$ sudo ip netns exec netns1 ifconfig veth_left 10.1.1.1/24 up
lizhe@ubuntu:~$ sudo ifconfig veth_right 10.1.1.2/24 up

ping 10.1.1.1

sudo ip netns exec netns1 ping 10.1.1.2

命名空间内 和 命名空间外 都可以互相ping通

之前我们说 命名空间 的作用是 隔离

那么路由表 和 防火墙 呢

sudo ip netns exec netns1 route

sudo ip netns exec netns1 iptables -L

我们试着使用 NAT 让 netns1 可以访问外网

开启 linux kernel ip forwarding

sudo sysctl net.ipv4.ip_forward=1 

将 netns1 的默认路由设为 veth_right ( 宿主机的veth ） 的 IP 地址

sudo ip netns exec netns1 route add default gw 10.1.1.2

确认一下网卡名称，这里是 ens33

配置 SNAT，将从 myspace 发出的网络包的 soruce IP address 替换为 ens33 的 IP 地址

sudo iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o ens33 -j MASQUERADE

在默认 FORWARD 规则为 DROP 时显式地允许 veth1 和 eth0 之间的 forwarding

lizhe@ubuntu:~$ sudo iptables -t filter -A FORWARD -i eth0 -o veth_right -j ACCEPT
lizhe@ubuntu:~$ sudo iptables -t filter -A FORWARD -o eth0 -i veth_right -j ACCEPT

sudo iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o ens33 -j MASQUERADE

最后我们来检查一下 route 并确认结果

每个 Linux 进程都拥有一个属于自己的 /proc/PID/ns ， 这个目录下的每个文件都代表一个类型的namespace

在内核版本3.8之前，只包含 ipc、net 和 uts 的硬链接

在内核版本3.8之后，每个文件都是一个特殊的符号链接文件。

这些符号链接的其中一个用途是 确定两个进程是否同属于 同一个 namespace，
如果两个进程在同一个namespace中，那么这两个进程的 /proc/PID/ns 目录下对应的符号链接文件的 inode， 就是 【】 中的数字，将会是一样的。

另外一个作用是，通过文件描述符，在不需要进程存在的情况下也能保持 namespace 存在。

CrashLoopBackOff

CrashLoopBackOff 状态表示 Kubelet 还没有放弃，它意味着在崩溃之后Kubelet会增加下次重启的间隔时间

间隔时间会按照 10秒，20秒，40秒，80秒，160秒，最终收敛于 300 秒

一旦间隔时间到达 300 秒，Kubelet 将会以固定的 300 秒 为间隔时间对容器进行无限重启

Api server 认证机制

在CoreDNS一节中，虽然我安装 coredns的尝试失败了，但是我们仍然可以看到 dns 组件是如何安装的

安装过程中有一个错误

failed with No API token found for service account “coredns” 

我们选择禁用 ServiceAccount 简单粗暴的规避了这个错误

将：KUBE_ADMISSION_CONTROL=”–admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota”

改为：KUBE_ADMISSION_CONTROL=”–admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota”

所以这一节我打算研究一下 ServiceAccount

当你从集群外部访问 apiserver 的时候，使用的是 kubectl 命令行，此时是不需要service account 的，但是当我们从一个pod内部访问它，这种情况下往往没有 kubectl 可用，因此，想要从一个pod内部访问 api server ，就需要 service account

如果你查看当前集群中所有的 service 你可以看到一定会有一个叫做 kubernetes 的 service ，类型是 clusterIP 实际上这个 service 就是 api server

为了测试上面的内容，我要创建一个 ubuntu pod ，然后用它尝试连接 api server

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ub2

  labels:

    app: ub2

spec:

  replicas: 1

  selector:

    matchLabels:

      app: ub2

  template:

    metadata:

      labels:

        app: ub2

    spec:

      containers:

      - name: ub2

        image: libaibai/ub2:latest

        command: ["/bin/bash","-c","sleep 3600"]

        ports:

        - containerPort: 80

然后我们使用这个pod来尝试访问 apiserver

api server 的 cert 存放在 secret 中

这个文件会被映射到每个pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

但是你不能直接使用这个 cert 来通过验证，下面出现的401 和 上面出现的 401 一样都是 客户端 忽略 或 信任了 服务器端之后的结果

但是服务器并没有授权客户端

如果客户端不信任服务器端是这样的

需要得到 api server 的授权，要使用

/var/run/secrets/kubernetes.io/serviceaccount/token

curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ikxsc0ZlMElUY3FLanNONGRoYzMtTGJDWXZjZWE2WXVkR2pOajdtNXNHTTAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tZzZzdzYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjQ1NzY1NzdkLTNkNGYtNDUyMS1iNDdkLWY5MmJhOGUxNjg3MyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.SAdvtBm1v4-YzD7qTC4KOdt6PDY4vAyptGzQkGNP17BqAqDNi9-dbrfJdYEFgof7nyMZH_TCMhi1FXMZJwQ5zOKXeS_YKruJuvJ1iXLwW2MoVy-conJmkoMU-SRcsy8tjv5KkLEZa9adIRG_8jHGc4zSRvs-5YkApsIYYOMFcUbhIVjyMt_rXIeb900hj1e5AhcaSQ19gy2paQkcCbaFnxq7dsgSbpsy011QDe-FzaWv7yY8xI3PJj-JIRgrDxV4WbtalJ5V5IrNcFhHyB7hxawZKvexIJ_ndPewacA42vIUoemAYCQYXm3Bio_ynd-gTQJQzo0YBGxSxfrHnIaHsQ"  https://10.43.0.1:443 

返回状态码变成了403，这是因为我们的集群使用了 RBAC

Kubernetes 将连接到 api server 的客户端分为两种

真实的人
pod 中的应用 （ service account ）

正常用户 和 service account 都可以属于一个或者多个组

常用组：

system:unauthenticated 用于所有认证插件都不会认证认证客户端身份的请求

system:authenticated 组会自动分配给一个成功通过认证的用户

system:serviceaccounts 包含所有在系统中的 ServiceAccount

system:serviceaccounts:<namespace> 组包含了所有在特定命名空间中的 ServiceAccount

下面来做实验

首先是失败实验

我们在 lizhe namespace 下面创建一个 ubuntu 实例，

然后尝试在没有 授予权限的情况下访问 api server

果然得到了403

下面是正确的实验

给定权限

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

删除的话：

kubectl delete clusterrolebindings permissive-binding

再调用一次 curl

ServiceAccount 和 pod、secret、configmap 一样都是资源，资源的话一定存在于某个 namespace 中

我们尝试新建一个 namespace，可以看到，新的namespace （ lizhe2 ） 自动持有了一个 service account

每个pod 都会与一个 serviceaccount 关联，但是多个pod可以使用同一个serviceaccount

每个pod会被分配一个在这个pod namespace中的单一 serviceaccount

在pod的描述文件中，可以将一个service account 赋给一个pod，如果没有显示地指定 service account，pod会使用所在 namespace 的默认 service account

创建一个新的namespace lizhe10

在其下创建 ubuntu10

实验一

当 ubuntu10 使用默认的 service account （ 由 lizhe10 提供的 ） 时，得到了403 ，无法访问 api server

实验二

给 pod 赋值其他 namespace 下的 service account -> 失败

pod ubuntu10 在 namespace lizhe10 下

sa lizhesa 在 namespace lizhe 下

给 ubuntu10 赋 lizhesa 失败

实验三

在 lizhe10 这个 namespace 下创建一个 sa ， 叫做 lizhesa10

把这个 新建的 sa lizhesa10 赋给 ubuntu10

此时，如果你尝试使用 lizhe10 这个 sa 去访问 api server，会得到 403

然后我们为 lizhesa10 赋权限

语法是这样的，之前我们用的是 group 

 $ clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] 

这次我们使用 service account

kubectl create clusterrolebinding permissive-binding-lizhesa10 --clusterrole=cluster-admin --serviceaccount=lizhe10:lizhesa10 

生效之后你就可以得到正确的 response了

下面是一些题外话

如果使用 describe 命令，查看这个 sa ，可以看到 它携带了一个 token

kubectl describe sa lizhesa10 -n lizhe10 

这个token实际上就是你在 pod 中得到的那个 token

RBAC 授权插件将用户角色作为决定用户是否能执行操作的关键因素。

主体 （ 人、sa 或者 group ） 和 一个或者多个 role 关联，每个 role 被允许在特定的资源上执行特定的 动作

如果一个用户有多个角色，他们可以做任何角色允许的动作。

RBAC 通过创建 四种 特定的 Kubernetes 资源来完成

Role 和 ClusterRole

它们指定了在资源上可以执行哪些动作

RoleBinding 和 ClusterRoleBinding 

它们将上述角色绑定到特定的 用户、组 或者 sa 上

之前我们使用过

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

意思是 创建了一个 名为 permissive-binding 的 类型是  clusterrolebinding  的绑定 到 clusterrole ，绑定的对象是一个组 该组作用域为 lizhe namespace

RoleBinding与ClusterRoleBinding

RoleBinding
RoleBinding可以将同一namespace中的subject（用户）绑定到某个具有特定权限的Role下，则此subject即具有该Role定义的权限。

ClusterRoleBinding
ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject与ClusterRole绑定，授予权限。

Role与ClusterRole

Role
Role对象只能用于授予对某一namespace中资源的访问权限。

ClusterRole
ClusterRole对象可以授予整个集群范围内资源访问权限， 也可以对以下几种资源的授予访问权限：

• 集群范围资源（例如节点，即node）
• 非资源类型endpoint（例如”/healthz”）
• 跨所有namespaces的范围资源（例如pod，需要运行命令kubectl get pods --all-namespaces来查询集群中所有的pod)