linuxea:kubernetes Role交叉绑定与内置绑定(33) 延续上一篇Role和Cluster Role示例,其中绑定都是role绑定rolebinding，clusterrole绑定clusterrolebinding，现在使用rolebinding绑定clusterrole，这样以来权限就会降级到rolebinding所在的权限我们先切换到kubernetes-admin用户下[root@linuxea role]# kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes".交叉绑定延续上一篇Role和Cluster Role示例,其中创建的clusterrole的权限是list,get， 这些权限是集群级别的，也就是说所有的namespace都有给的get和list权限此时，我们使用rolebinding绑定clusterrole，clusterrole的名称是linuxea-cluster-read。需要说明的是，此前的创建的pods-read只针对当前名称空间有list和get权限。如下图如此此时clusterrole与rolebinding绑定，最终降级到是role角色的名称空间内的get，list权限。[root@linuxea role]# kubectl create rolebinding pods-read --clusterrole=linuxea-cluster-read --user=linuxea --dry-run -o yaml >> ./role-clusterrole.yaml如下： kind: RoleBinding,但是roleRef的kind是ClusterRole[root@linuxea role]# cat ./role-clusterrole.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: creationTimestamp: null name: pods-read namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: linuxea-cluster-read subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: linuxea为了避免权限重叠，将之前创建的clusterrolebinding删除[root@linuxea role]# kubectl delete clusterrolebinding linuxea-cluster-read clusterrolebinding.rbac.authorization.k8s.io "linuxea-cluster-read" deleted而后apply -f role-clusterrole.yaml[root@linuxea role]# kubectl apply -f ./role-clusterrole.yaml rolebinding.rbac.authorization.k8s.io/pods-read created[root@linuxea role]# kubectl describe rolebinding pods-read Name: pods-read Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"pods-read","namespace":"default"},"roleRef":{"ap... Role: Kind: ClusterRole Name: linuxea-cluster-read Subjects: Kind Name Namespace ---- ---- --------- User linuxea 切换到linuxea用户验证下权限[root@linuxea ~]# kubectl config use-context linuxea@kubernetes Switched to context "linuxea@kubernetes".此前的role角色权限是list，也就是说定义在namespace中，只有pods的list，get权限.那么是没有其他namespace的权限[root@linuxea ~]# kubectl get pods -n ingress-nginx No resources found. Error from server (Forbidden): pods is forbidden: User "linuxea" cannot list pods in the namespace "ingress-nginx"pod是可以进行get的[root@linuxea ~]# kubectl get pods NAME READY STATUS RESTARTS AGE linuxea-sa-demo 1/1 Running 0 2d linuxea-tomcat-group-b77666d76-4h5mz 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-89qnx 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-gvm4w 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-jszbg 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-l5nkq 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-lxr8r 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-m5sxg 1/1 Running 0 3d satefulset-0 1/1 Running 0 5d satefulset-1 1/1 Running 0 5d satefulset-2 1/1 Running 0 5d satefulset-3 1/1 Running 0 5d satefulset-4 1/1 Running 0 5d [root@linuxea ~]# 绑定内置Role内置的role有很多，其中包含有admin，尝试将linuxea绑定到admin[root@linuxea ~]# kubectl get clusterrole NAME AGE admin 19dadmin的角色有很多，不一 一列举,可以查看这个文件[root@linuxea ~]# kubectl get clusterrole admin -o yaml >> /admin.yaml [root@linuxea ~]# cat /admin.yaml aggregationRule: clusterRoleSelectors: - matchLabels: rbac.authorization.k8s.io/aggregate-to-admin: "true" apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: 2018-09-16T05:56:16Z labels: kubernetes.io/bootstrapping: rbac-defaults name: admin resourceVersion: "350" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/admin uid: 39a45e55-b975-11e8-a8ab-88882fbd1028 ................ 直接绑定到linuxea用户上[root@linuxea ~]# kubectl create rolebinding linuxea-admin --clusterrole=admin --user=linuxea rolebinding.rbac.authorization.k8s.io/linuxea-admin created[root@linuxea ~]# kubectl get rolebinding NAME AGE linuxea-admin 8s pods-read 3h[root@linuxea ~]# kubectl describe rolebinding linuxea-admin Name: linuxea-admin Labels: <none> Annotations: <none> Role: Kind: ClusterRole Name: admin Subjects: Kind Name Namespace ---- ---- --------- User linuxea 切换到linuxea用户下[root@linuxea ~]# kubectl config use-context linuxea@kubernetes Switched to context "linuxea@kubernetes".验证是否具有admin的角色权限[root@linuxea ~]# kubectl get pods NAME READY STATUS RESTARTS AGE linuxea-sa-demo 1/1 Running 0 2d linuxea-tomcat-group-b77666d76-4h5mz 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-89qnx 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-gvm4w 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-jszbg 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-l5nkq 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-lxr8r 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-m5sxg 1/1 Running 0 4d satefulset-0 1/1 Running 0 5d satefulset-1 1/1 Running 0 5d satefulset-2 1/1 Running 0 5d satefulset-3 1/1 Running 0 5d satefulset-4 1/1 Running 0 5d[root@linuxea ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 19d linuxea-tomcat ClusterIP 10.97.191.185 <none> 8080/TCP,8009/TCP 4d satefulset-linuxea ClusterIP None <none> 80/TCP 5d[root@linuxea ~]# kubectl get deploy NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE linuxea-tomcat-group 7 7 7 7 4d[root@linuxea ~]# kubectl delete pods linuxea-tomcat-group-b77666d76-4h5mz pod "linuxea-tomcat-group-b77666d76-4h5mz" deleted[root@linuxea ~]# kubectl get pods NAME READY STATUS RESTARTS AGE linuxea-sa-demo 1/1 Running 0 2d linuxea-tomcat-group-b77666d76-89qnx 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-fj2rk 1/1 Running 0 6s linuxea-tomcat-group-b77666d76-gvm4w 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-jszbg 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-l5nkq 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-lxr8r 1/1 Running 0 4d linuxea-tomcat-group-b77666d76-m5sxg 1/1 Running 0 4d satefulset-0 1/1 Running 0 5d satefulset-1 1/1 Running 0 5d satefulset-2 1/1 Running 0 5d satefulset-3 1/1 Running 0 5d satefulset-4 1/1 Running 0 5d [root@linuxea ~]# 尽管如此，他是没有管理其他的namespace中的权限[root@linuxea ~]# kubectl get pods -n kube-system No resources found. Error from server (Forbidden): pods is forbidden: User "linuxea" cannot list pods in the namespace "kube-system"内置Rolebinding我们切换回kubernetes-admin[root@linuxea ~]# kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes".在内置Rolebinding中已经有绑定admin的clusterrolebinding，cluster-admin[root@linuxea ~]# kubectl get clusterrolebinding NAME AGE cluster-admin 19d使用-o yaml查看describe信息[root@linuxea ~]# kubectl get clusterrolebinding cluster-admin -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: 2018-09-16T05:56:16Z labels: kubernetes.io/bootstrapping: rbac-defaults name: cluster-admin resourceVersion: "110" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin uid: 39d1bdfd-b975-11e8-a8ab-88882fbd1028 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:masters其中在system:masters组中有kubernetes-admin用户，kubetnetes-admin在pki中的CRT文件的cn对应就是kube-apiserver-kubelet-client，可以使用openssl查看crt文件[root@linuxea ~]# openssl x509 -in /etc/kubernetes/pki/apiserver-kubelet-client.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 8110592987322906857 (0x708e9d59a727f8e9) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=kubernetes Validity Not Before: Sep 16 05:55:34 2018 GMT Not After : Sep 16 05:55:35 2019 GMT Subject: O=system:masters, CN=kube-apiserver-kubelet-client Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus:如果此时在创建用户或者授权时候，可以O=system:masters将用户绑定到admin组在RBAC上授权时候，允许存在三类组件，分别是user,group以及serviceAccountuser可以绑定在group,role,serviceaccount。如果绑定在用户上，则只是授权在一个用户上，绑定在组，则组内用户都有这个权限，如果多个用户有同样的权限，可以授权成一个组。如果serviceAccount与role或者clusterrole绑定，则意味着serviceAccount有访问权限，并且在serviceAccountName使用了这个serviceAccount的name，那么在service内的pod中的应用程序就有了serviceAccount的权限.并且，在一些pod运行的时候就需要这种权限来以便于操作，如flannel，在github上有flannel的yml文件文件以供参考[root@linuxea ~]# kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE ... kube-flannel-ds-amd64-5swqs 1/1 Running 0 19d ...可以查看kube-flannel-ds-amd64-5swqsyaml文件[root@linuxea ~]# kubectl get pods kube-flannel-ds-amd64-5swqs -o yaml -n kube-system

linuxea:kubernetes Role和Cluster Role示例(32) 不管是role，rolebinding还是clusterRole，clusterRolebinding都是资源清单中的标准资源我们创建linuxea-readpod和linuxea-cluster-read分别示例RBAC对权限的控制，图示如下：可以使用kubectl create role --help查看帮助信息创建ROLE创建role，对pods有get,list权限，使用-dry-run运行是否有误[root@linuxea ~]# kubectl create role pods-read --verb=get,list,watch --resource=pods --dry-run role.rbac.authorization.k8s.io/pods-read created (dry run)甚至于可以使用-o yaml输出yaml格式[root@linuxea role]# kubectl create role pods-read --verb=get,list,watch --resource=pods --dry-run -o yaml >> ./role-demo.yaml随后编辑添加上namespace:default[root@linuxea role]# cat ./role-demo.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: pods-read namespace: default rules: - apiGroups: - "" resources: - pods verbs: - get - list - watchapply[root@linuxea role]# kubectl apply -f ./role-demo.yaml role.rbac.authorization.k8s.io/pods-read created[root@linuxea role]# kubectl get role NAME AGE pods-read 3s[root@linuxea role]# kubectl describe pods-read error: the server doesn't have a resource type "pods-read" [root@linuxea role]# kubectl describe role pods-read Name: pods-read Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"creationTimestamp":null,"name":"pods-read","namespace":"defaul... PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list watch]其中可以针对某一个资源做限制objects：Resources(资源名称)下的 某个Resource Name(资源类别)Non-Resource URLs(非资源URL,不能对于成对象的资源，是定义成某种特殊操作)PolicyRule Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list watch]此前创建了一个用户linuxea，linuxea用户并没有权限读取pod，此刻让linuxea扮演此role，那么就需要绑定rolebinding创建Rolebinding而rolebinding可以绑定role和clusterrole，我们选择role绑定，而后指定username或者groupname，如果绑定不是普通账号，而是service账号，就需要指定serviceaccount的名称现在将之前创建的linxea绑定到pods-read的role上创建一个叫linuxea-readpod的rolebinding，指定上述创建的role名称，绑定到pods-read ，指定--user=linuxea； 这个账号不存在系统上，只是标识[root@linuxea role]# kubectl create rolebinding linuxea-readpod --role=pods-read --user=linuxea --dry-run -o yaml >> ./rolebinding-demo.yaml而在yaml文件定义中明确定义了roleRef的api组，组内的kind类型和名称。用户的api组，和组内的kind和用户名[root@linuxea role]# cat ./rolebinding-demo.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: creationTimestamp: null name: linuxea-readpod roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pods-read subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: linuxeaapply[root@linuxea role]# kubectl apply -f rolebinding-demo.yaml rolebinding.rbac.authorization.k8s.io/linuxea-readpod created[root@linuxea role]# kubectl get rolebinding NAME AGE linuxea-readpod 11s[root@linuxea role]# kubectl describe rolebinding linuxea-readpod Name: linuxea-readpod Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"creationTimestamp":null,"name":"linuxea-readpod","names... Role: Kind: Role Name: pods-read Subjects: Kind Name Namespace ---- ---- --------- User linuxea 此刻，linuxea用户已经拥有了get,list权限。现在切换到linuxea用户get pods[root@linuxea ~]# kubectl config use-context linuxea@kubernetes Switched to context "linuxea@kubernetes".在看当前的用户则是current-context: linuxea@kubernetes[root@linuxea ~]# kubectl config view .... - context: cluster: kubernetes user: linuxea name: linuxea@kubernetes current-context: linuxea@kubernetes ....而后get pods，由于之前对当前名称空的pods有get,list权限，查看是没有问题的[root@linuxea ~]# kubectl get pods NAME READY STATUS RESTARTS AGE linuxea-sa-demo 1/1 Running 0 1d linuxea-tomcat-group-b77666d76-4h5mz 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-89qnx 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-gvm4w 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-jszbg 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-l5nkq 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-lxr8r 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-m5sxg 1/1 Running 0 3d satefulset-0 1/1 Running 0 5d satefulset-1 1/1 Running 0 5d satefulset-2 1/1 Running 0 5d satefulset-3 1/1 Running 0 5d satefulset-4 1/1 Running 0 5d其他删除也没权限操作[root@linuxea ~]# kubectl delete pods linuxea-tomcat-group-b77666d76-4h5mz Error from server (Forbidden): pods "linuxea-tomcat-group-b77666d76-4h5mz" is forbidden: User "linuxea" cannot delete pods in the namespace "default"其他名称空间仍然没有权限[root@linuxea ~]# kubectl get svc No resources found. Error from server (Forbidden): services is forbidden: User "linuxea" cannot list services in the namespace "default"[root@linuxea ~]# kubectl get pods -n ingress-nginx No resources found. Error from server (Forbidden): pods is forbidden: User "linuxea" cannot list pods in the namespace "ingress-nginx" [root@linuxea ~]# 创建Cluster role回到管理员账号创建clusterrole[root@linuxea ~]# kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes".将配置追加到./clusterrole.yaml中.创建一个名称为linuxea-cluster-read的clusterrole，权限是list和get，watch。在clusterrole中，授权集群级别[root@linuxea role]# kubectl create clusterrole linuxea-cluster-read --verb=get,list,watch --resource=pods -o yaml --dry-run >> ./clusterrole.yaml而后apply[root@linuxea role]# kubectl apply -f clusterrole.yaml clusterrole.rbac.authorization.k8s.io/linuxea-cluster-read created使用kubectl get clusterrole查看已经被创建的linuxea-cluster-read[root@linuxea role]# kubectl get clusterrole NAME AGE .... linuxea-cluster-read 13m ....现在将linuxea用户绑定到clusterrolebinding上，先将刚才绑定的rolebinding删除[root@linuxea role]# kubectl get rolebinding NAME AGE linuxea-readpod 1h[root@linuxea role]# kubectl delete rolebinding linuxea-readpod rolebinding.rbac.authorization.k8s.io "linuxea-readpod" deleted现在linuxea账号对任何名称空间都没有任何权限。并且已经创建好了cluster role。接着创建clusterrolebinding绑定创建Clusterrolebindingclusterrolebinding只能绑定clusterrole.创建一个clusterrolebinding名称为linuxea-cluster-read，名称和clusterrole一样，绑定到clusterrolebinding的linuxea-cluster-read上[root@linuxea role]# kubectl create clusterrolebinding linuxea-cluster-read --clusterrole=linuxea-cluster-read --user=linuxea --dry-run -o yaml >> ./clusterrolebinding.yaml [root@linuxea role]# cat ./clusterrolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: creationTimestamp: null name: linuxea-cluster-read roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: linuxea-cluster-read subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: linuxea使用kubectl get clusterrolebinding查看创建已经完成的clusterrolebinding[root@linuxea role]# kubectl get clusterrolebinding NAME AGE ..... linuxea-cluster-read 22s .....查看创建的clusterrolebinding的describe信息[root@linuxea role]# kubectl describe clusterrolebinding linuxea-cluster-read Name: linuxea-cluster-read Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"creationTimestamp":null,"name":"linuxea-clu... Role: Kind: ClusterRole Name: linuxea-cluster-read Subjects: Kind Name Namespace ---- ---- --------- User linuxea 而后切换到linuxea用户下，验证下授予的clusterrole权限[root@linuxea role]# kubectl config use-context linuxea@kubernetes Switched to context "linuxea@kubernetes".之前授权的是名称空间下的pod的list,get[root@linuxea role]# kubectl get pods NAME READY STATUS RESTARTS AGE linuxea-sa-demo 1/1 Running 0 2d linuxea-tomcat-group-b77666d76-4h5mz 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-89qnx 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-gvm4w 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-jszbg 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-l5nkq 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-lxr8r 1/1 Running 0 3d linuxea-tomcat-group-b77666d76-m5sxg 1/1 Running 0 3d satefulset-0 1/1 Running 0 5d satefulset-1 1/1 Running 0 5d satefulset-2 1/1 Running 0 5d satefulset-3 1/1 Running 0 5d satefulset-4 1/1 Running 0 5d换名称空间到pods -n kube-system[root@linuxea role]# kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE coredns-78fcdf6894-mvdln 1/1 Running 0 19d coredns-78fcdf6894-zwqfw 1/1 Running 0 19d etcd-linuxea.master-1.com 1/1 Running 0 19d kube-apiserver-linuxea.master-1.com 1/1 Running 0 19d kube-controller-manager-linuxea.master-1.com 1/1 Running 0 19d kube-flannel-ds-amd64-5swqs 1/1 Running 0 19d kube-flannel-ds-amd64-fwzjl 1/1 Running 0 19d kube-flannel-ds-amd64-gtqhv 1/1 Running 0 19d kube-flannel-ds-amd64-qmhq9 1/1 Running 0 19d kube-proxy-64jwb 1/1 Running 0 19d kube-proxy-sllmj 1/1 Running 0 19d kube-proxy-tzdlj 1/1 Running 0 19d kube-proxy-vwtx4 1/1 Running 0 19d kube-scheduler-linuxea.master-1.com 1/1 Running 0 19d或者名称空间ingress-nginx[root@linuxea role]# kubectl get pods -n ingress-nginx NAME READY STATUS RESTARTS AGE default-http-backend-6586bc58b6-n9qbt 1/1 Running 0 19d nginx-ingress-controller-6bd7c597cb-krz4m 1/1 Running 0 19d当然，除了授权的list,get之外，其他没授权的都是拒绝的，也就是说没有权限的[root@linuxea role]# kubectl delete pods kube-flannel-ds-amd64-qmhq9 Error from server (Forbidden): pods "kube-flannel-ds-amd64-qmhq9" is forbidden: User "linuxea" cannot delete pods in the namespace "default"

linuxea:kubernetes 了解RBAC(31) 之前我们知道kubernetes的授权是用插件来实现，并且支持很多插件，并且支持很多插件同时使用，且只要通过其中一个授权检查通过则不会在进行其他插件进行检查，而后由准入控制插件后续检查。授权插件常用有四个：节点Node，ABAC属性访问控制，RBAC，Webhook回掉机制实现授权、RBACRBAC的全称是Role-based AC，在kubernetes中RBAC就是定义标准的资源：Role:operations(许可授权，在其中只要包含在内的写入的都是允许的，不能定义拒绝权限，因为没有就是拒绝权限),objects,rolebinding（角色绑定）将用户(useraccount)或者serviceaccount绑定到那个角色上，让用户扮演那个角色其中role和rolebinding有两个级别在kubernetes中资源分属两种级别，集群和名称空间，role和rolebinding是名称空间级别内的许可权限。基于角色的访问控制，用户作为访问的独立账号，角色(role)是授权机制：授权和许可(permission)user扮演了角色1就拥有了角色1的权限，所有的授权都添加在角色上，用户扮演的 角色就拥有了角色权限权限：对于对象，每一个被访问的组件都是对象，在restful 的api当中一切届对象，k8s上运行的组件分为三类， 对象占用了绝大部分，对象列表API，非对象资源，URL。在restful风格中的操作都是指在某个对象施加的(action)某种行为，称之operations。在一个对象上施加过程组合起来称为permissions. 而后可以在role上，授权于role拥有某个许可的权限(permissions)(在某些对象上实现某些操作的权限)。如果需要使用基于角色访问控制，应该有user,role，permissions，而permissions就需要事先有一些objects，这些objects支持一些operations，这组合在一起就定义成了permissions。授于role，就完成了授权。能够扮演角色并施加权限的有两个账号，如下：userAccount和serviceAccount,serviceAccount，这些restful 接口执行类似与GET,PUT等操作，操作对象于位于url路径的对象列表或者一个具体的URL对象。把图一和图二绑定起来permissions，而后授予到角色上，让用户扮演角色，最后完成授权。除开role和rol ebinding之外，还有两个组件clusterrole，clusetrrolebinding在名称空间A中定义了角色(role)，角色和user1建立绑定关系(rolebinding)，user1就有了定义的角色(role)权限。user1的这些权限只能在当前名称空间下的所有pod生效。如下：如果此时user1用户定义的是clusterRole，操作对象还是pod。user1用户和clusterRole建立绑定关系(也就是clusterRoleBinding)，那就会突破名称空间的边界，而是集群级别的权限，生效的范围在整个集群。如下：那么如果名称空间b中的user1的rolebingding绑定集群级别的ClusterRole(角色)，而不是绑定namespace中的role(角色)，即便如此。权限仍然在namespace中，因为user使用rolebinding绑定的clusterRole，对用户来讲权限就限制在namespace中。这样以来clusterrole权限降级到rolebinding所有权限。如果要对某一个或几个名称空间做用户权限则可以如此。如下：role定义的在那个名称空间，生效范围在那个名称空间

linuxea:kubernetes config用户认证和自定义认证(30) RBAC是基于角色的访问控制。Api server的客户端在认证时，如果要基于配置文件来保存配置信息，而并不是使用serviceAccount使用token认证，就应该配置为一个配置文件。事实上，kubenetes中大大多数组件要连接api server都需要认证，这些都可以算作客户端。这些组件能够链接入正确的集群，就需要提供正确的证书，私钥等信息，这些信息保存在配置文件，这个配置文件有个专用的称呼叫做：kubeconfig，这个配置文件就是api server的客户端，连接api server时候的认证格式的配置文件。可以通过kubectl config view查看字段·clusters集群列表，如果有读个则显示多少contexts列表中指明对应的访问权限，指明那个用户访问那个集群，当前用户访问集群的用户则是current-context[root@linuxea sa]# kubectl config view apiVersion: v1 clusters: # 集群列表 - cluster: certificate-authority-data: REDACTED # 服务器发来认证集群的认证方式，REDACTED加密 server: https://10.10.240.161:6443 # 服务器api server路径 name: kubernetes # 集群名称 contexts: # 上下文列表 - context: # 指定是那个用户访问那个集群 cluster: kubernetes # 访问的集群名称 user: kubernetes-admin # 范围集群的账号 name: kubernetes-admin@kubernetes # context名称，通常也是用户名 current-context: kubernetes-admin@kubernetes # 当前访问集群的用户 ，当前上下文 kind: Config preferences: {} users: # 用户列表 - name: kubernetes-admin # 用户名，集群管理员 user: #用户被api server认证的证书 client-certificate-data: REDACTED # 客户端证书 client-key-data: REDACTED # key # 客户端私钥上下文：这个配置文件不单单是说就只能访问一个集群。假如此刻有多个集群，我需要在集群间互相切换，使用一个帐号就可以完成。为了使一个kubectl账号控制多个集群。那它可能需要这样，如：此刻有三个集群，分别是a,b,c。这a,b,c三个集群可能都有各自的账号，所以就提供了配置文件：集群列表，用户列表。对每个集群可能都有不同的账号，也可能一样。我们事先定义好账号(也就是用户列表，用户可能有多个，和集群数目无直接关系，权限也不一样)，这些账号列表中某个账号去访问那个集群就取决于contexts定义。这样以来可能有多个contexts，但是当前使用那个账号访问那个集群就取决于current-context(当前帐号)。其中当创建一个config的时候，他的认证信息较为复杂。如下：定义配置文件定义配置文件需要一些参数，通过kubectl config --help获取： set-cluster 设定集群 set-context 设定上下文 set-credentials 设定用户账号 unset Unsets an individual value in a kubeconfig file use-context 设定谁说是当前上下文 view Display merged kubeconfig settings or a specified kubeconfig file配置中，可以在当前一个配置中新增用户账号，也可以另建立配置文件提供账号。这样的好事就能让一个配置文件浮现负载很多用户账号。所以，是可以在这里添加账号的。不过，在添加账号的时候，需要自带账号专门用于到服务端认证信息的。我们在使用kubeadm初始化的时候，会为当前集群创建一个私有的CA，位于/etc/kubernetes/pki。这些ca被api server所信任，都可以认证连入集群。如果有需要，可以使用这里ca和key签署自定义是证书和私钥进行认证。这些信息尤为重要。我们使用这里的证书和私钥做一个账号，来进行认证到api server在使用kubeadm创建集群时候，会在/etc/kubernetes/pki创建私有CA[root@linuxea sa]# ll /etc/kubernetes/pki/ total 56 -rw-r--r--. 1 root root 1241 Sep 16 06:55 apiserver.crt -rw-r--r--. 1 root root 1094 Sep 16 06:55 apiserver-etcd-client.crt -rw-------. 1 root root 1675 Sep 16 06:55 apiserver-etcd-client.key -rw-------. 1 root root 1679 Sep 16 06:55 apiserver.key -rw-r--r--. 1 root root 1099 Sep 16 06:55 apiserver-kubelet-client.crt -rw-------. 1 root root 1679 Sep 16 06:55 apiserver-kubelet-client.key -rw-r--r--. 1 root root 1025 Sep 16 06:55 ca.crt -rw-------. 1 root root 1675 Sep 16 06:55 ca.key drwxr-xr-x. 2 root root 162 Sep 16 06:55 etcd -rw-r--r--. 1 root root 1025 Sep 16 06:55 front-proxy-ca.crt -rw-------. 1 root root 1675 Sep 16 06:55 front-proxy-ca.key -rw-r--r--. 1 root root 1050 Sep 16 06:55 front-proxy-client.crt -rw-------. 1 root root 1679 Sep 16 06:55 front-proxy-client.key -rw-------. 1 root root 1679 Sep 16 06:55 sa.key -rw-------. 1 root root 451 Sep 16 06:55 sa.pub这里可是使用ca.key签署自定义的证书和私钥，也可以直接使用创建好的证书和私钥，这些文件非常重要。只要api server信任的私钥都可以链接到集群。可以使用这里的证书制作另外一个账号进行认证到api server上。生成私钥生产一个专属证书，证书的持有者和用户名必须保持一致，证书的持有者名称就是账号名[root@linuxea sa]# (umask 077; openssl genrsa -out linuxea.key 2048) Generating RSA private key, 2048 bit long modulus ............+++ ..................................................................................................+++ e is 65537 (0x10001) [root@linuxea sa]# ll linuxea.key -rw-------. 1 root root 1679 Oct 3 15:01 linuxea.key基于这个私钥生成一个证书，使用/etc/kubernetes/pki下的ca.crt签署签署证书[root@linuxea pki]# openssl req -new -key linuxea.key -out linuxea.csr -subj "/CN=linuxea"[root@linuxea pki]# pwd /etc/kubernetes/pki[root@linuxea pki]# openssl x509 -req -in linuxea.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out linuxea.crt -days 36500 Signature ok subject=/CN=linuxea Getting CA Private Key也可查看证书的信息[root@linuxea pki]# openssl x509 -in linuxea.crt -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: 89:e9:b5:e3:21:06:0b:b9 Signature Algorithm: sha256WithRSAEncryption Issuer: CN=kubernetes Validity Not Before: Oct 3 14:12:02 2018 GMT Not After : Sep 9 14:12:02 2118 GMT Subject: CN=linuxea Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: ................ 应用证书这个证书是由kubernetes同一个ca授权创建可以指明认证方式，token,cert指明刚创建的密钥，添加一个名称为linuxea的用户。--embed-certs=true： 隐藏起key和crt显示[root@linuxea pki]# kubectl config set-credentials linuxea --client-certificate=./linuxea.crt --client-key=./linuxea.key --embed-certs=true User "linuxea" set.在看kubectl config view的users字段就多出一个- name: linuxea[root@linuxea pki]# kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED server: https://10.10.240.161:6443 name: kubernetes contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes current-context: kubernetes-admin@kubernetes kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED - name: linuxea user: client-certificate-data: REDACTED client-key-data: REDACTED而后设置上下文,使linuxea也能访问kubernetes集群，指定linuxea用户访问kubernetes集群。linuxea@kubernetes[root@linuxea pki]# kubectl config set-context linuxea@kubernetes --cluster=kubernetes --user=linuxea Context "linuxea@kubernetes" created.此刻，context这里就多一条创建的linuxea用户- context: cluster: kubernetes user: linuxea name: linuxea@kubernetes如下：[root@linuxea pki]# kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED server: https://10.10.240.161:6443 name: kubernetes contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes - context: cluster: kubernetes user: linuxea name: linuxea@kubernetes current-context: kubernetes-admin@kubernetes kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED - name: linuxea user: client-certificate-data: REDACTED client-key-data: REDACTED 切换到创建的linuxea用户[root@linuxea pki]# kubectl config use-context linuxea@kubernetes Switched to context "linuxea@kubernetes". current-context:当前账户linuxea@kubernetescurrent-context: linuxea@kubernetes 如下：[root@linuxea pki]# kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED server: https://10.10.240.161:6443 name: kubernetes contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes - context: cluster: kubernetes user: linuxea name: linuxea@kubernetes current-context: linuxea@kubernetes 使用创建的用户访问svc但是，这个linuxea用户并没有管理员权限，这里报No resources found. Forbidden[root@linuxea pki]# kubectl get svc No resources found. Error from server (Forbidden): services is forbidden: User "linuxea" cannot list services in the namespace "default"设置集群如果是一个新集群定义，可以设置如下：创建cluster集群配置文件，在创建之前需要切换到kubernetes-admin管理员账号[root@linuxea pki]# kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes".kubectl默认加载当前用户在家目录下的.kube，当然，也可以在创建集群时可指定名称，指明配置文件位置，指明服务位置，并指明server，指明ca证书指明集群的ca证书，因为ca证书要验证集群api server发过来的证书。[root@linuxea ~]# kubectl config set-cluster linuxeacluster --kubeconfig=/data/linuxea.conf --server="https://10.10.240.161:6443" --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true Cluster "linuxeacluster" set.而后就可以看到定义的集群，名称linuxeacluster，其他等信息。[root@linuxea ~]# kubectl config view --kubeconfig=/data/linuxea.conf apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED server: https://10.10.240.161:6443 name: linuxeacluster contexts: [] current-context: "" kind: Config preferences: {} users: []

linuxea:kubernetes pod用户信息认证serviceAccount(29) 在kubernets上有一些服务和客户端需要与api server交涉，并且集群内部会运行类似的pod资源，这些资源是需要访问api server的 ，如: CoreDNS,以及dashboarddashboard提供一个web界面来管理kubernetes，通过service暴漏到外部，通过浏览器打开使用。当然会有通过dashboard来进行增删改查资源，那意味着dashboard这个pod就有可能去创建pod，甚至于名称空间等，那这种操作明显是需要与api server交涉的。如下图：与api server交涉的有两类：集群之外的客户端 ，集群之外的客户端每次访问api server使用api server监听的节点地址如kubectl，kubectl并没有运行在节点之上，可以运行在任何系统上，只要有配置文件，都可以进行链接。外部的链接通过api server对外的通信监听的地址，与远程客户端通讯。如上图。集群内部POD客户端pod有pod网络，pod工作在内部的网段内集群内部范围api server是通过名称空间当中的kubernetes的service ip 10.96.0.1 进行通讯。将一个集群外部的服务以service的方式引入到集群内部来，事实上也是同一个主机上的，10.96.0.1也就是serviec所在的网络地址，pod本身也是可以和service通讯的，从而使得POD可以请求api server之上的服务。pod请求api service上的服务就是通过10.96.0.1进行的。如上图[root@linuxea volume]# kubectl describe svc kubernetes Name: kubernetes Namespace: default Labels: component=apiserver provider=kubernetes Annotations: <none> Selector: <none> Type: ClusterIP IP: 10.96.0.1 Port: https 443/TCP TargetPort: 6443/TCP Endpoints: 10.10.240.161:6443 Session Affinity: None Events: <none>但是，api server是需要认证的，api server将认证传递给客户端，客户端校验api server的身份，同时api server校验客户端的身份。那就意味着api server发送给客户端的身份中表明的ip地址不能只是宿主机10.10.240.161这一个ip地址，并且要有coredns的10.96.0.1这个ip地址。因为pod客户端在集群内访问的是10.96.0.1这个IP地址。那也就是说证书持有者名称必须有两条a记录解析到这两个ip。serviceAccount那也就是说证书持有者名称必须有两条a记录解析到这两个ip。任何pod只要需要访问到api server，api server必须要求认证pod，不认证就会被拒绝。而这个认证是由pod提供的，而serviceAccountName（服务账号名称）就是让pod链接api server进行认证用的账号。kubernetes集群中有两类认证账号，一种是管理人员用户操作类(`userAccountName)，第二种是服务账号(serviceAccountName)，指运行在k8s集群上的pod，想访问当前k8s集群的api server的用户认证信息，服务帐户等。事实上每一种pod都会与api交互，只是权限大小不同而已默认pod在运行时候，都会有相关信息，如下：[root@linuxea ~]# kubectl describe pods satefulset-2 ...... Volumes: default-token-k25gj: Type: Secret (a volume populated by a Secret) SecretName: default-token-k25gj Optional: false QoS Class: BestEffort Node-Selectors: <none> .....default-token-k25gj的认证资源保存在Secret vloume存储卷的方式关联到pod当中,从而来完成认证链接信息的其次，在名称空间中默认会创建一个secret的名称空间。default-token-k25gj [root@linuxea ~]# kubectl get secret NAME TYPE DATA AGE default-token-k25gj kubernetes.io/service-account-token 3 15d redis-passwd Opaque 1 2d tomcat-ingress-secret kubernetes.io/tls 2 14d之前创建的 ingress-nginx名称空间，也有default-token-s7f97 ,这个token让这个名称空间所有的pod资源联系api server时候预置的认证信息，不过仅限获取当前pod于自身的相关属性，并不能去管理别人的[root@linuxea ingress]# kubectl get secret -n ingress-nginx NAME TYPE DATA AGE default-token-s7f97 kubernetes.io/service-account-token 3 15d nginx-ingress-serviceaccount-token-89ctc kubernetes.io/service-account-token 3 15d如果要扩展一个pod,就是用来管理其他的pod，或者说是管理类的其他资源对象，就必须手动创建一个service-account-token，并且创建pod时候附加手动定义的service-account-token，不去使用默认的即可。默认的service-account-token一般权限非常小，如果需要提升权限就需要手动定义。创建serviceAccountserviceAccount属于k8s标准资源，可以创建完成后，使用serviceAccountname加载定义的serviceAccount可以使用create创建serviceAccount，而后指定属性即可创建，这些属性使用kubectl create serviceaccount -h可以看到。如果不指定任何属性，也可以给定一个名称。serviceAccount本身是不带权限的，创建只是使他换了一个账号。而后使用RBAC授其他的权限给这个创建的serviceAccount。授权并不属于serviceAccount，可以使用一个专用的账号给POD使用，而后给这个专用的账号更大的权限使用。而默认的serviceAccount会让名称空间当中所有的pod都拥有这个权限。如果有这种专用的需求，就需要定义一个专用的账号来赋予权限。命令行创建--dry-run=false: If true, only print the object that would be sent, without sending it.。我们可在加上--dry-run测试[root@linuxea ingress]# kubectl create serviceaccount mysa --dry-run serviceaccount/mysa created (dry run)--o yaml指明输出格式，清单类型yaml[root@linuxea ingress]# kubectl create serviceaccount mysa -o yaml --dry-run apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: null name: mysa可以使用--dry-run将结果>输出重定向到文件中,如：kubectl create serviceaccount mysa -o yaml --dry-run > ./linuxea.yml,支持create的都可以这么做。当然，也可以指定一个pod名称来查看，如：kubectl get pods linuxea-tomcat-group-b77666d76-4h5mz -o yaml --exportserviceAccount简称sa，在使用kubectl get sa即可。此时能看到默认的一个sa[root@linuxea ingress]# kubectl get sa NAME SECRETS AGE default 1 16d创建sa创建一个名称为admin-linuxea的serviceaccount[root@linuxea ingress]# kubectl create serviceaccount admin-linuxea serviceaccount/admin-linuxea created [root@linuxea ingress]# kubectl get sa NAME SECRETS AGE admin-linuxea 1 3s default 1 16d创建完成系统会自动生成secret。而系统也会自动生成一个tokens信息[root@linuxea ingress]# kubectl describe sa admin-linuxea Name: admin-linuxea Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: admin-linuxea-token-4zpzk Tokens: admin-linuxea-token-4zpzk Events: <none>生成的admin-linuxea-token-4zpzksecret这个secret仅用于这个sa链接当前api server的认证信息，并不包含权限信息，如果需要什么权限，则需要另外授权[root@linuxea ingress]# kubectl get secret NAME TYPE DATA AGE admin-linuxea-token-4zpzk kubernetes.io/service-account-token 3 1m应用sa到pod创建一个linuxea-sa-demo的pod，在spec中添加serviceAccountName: admin-linuxea,也就是之前创建的serviceAccount[root@linuxea sa]# cat sa-demo.yaml apiVersion: v1 kind: Pod metadata: name: linuxea-sa-demo namespace: default labels: www: linuxea-com tier: backend annotations: www.linuxea.com/ops-by: "linuxea admin" spec: containers: - name: linuxea-pod1-com image: "marksugar/nginx:1.14.a" ports: - containerPort: 80 serviceAccountName: admin-linuxea用kubectl describe pods linuxea-sa-demo查看volumes，admin-linuxea-token-4zpzk:已在其中，type为Secret，如下：[root@linuxea sa]# kubectl describe pods linuxea-sa-demo|tail -20 Initialized True Ready True ContainersReady True PodScheduled True Volumes: admin-linuxea-token-4zpzk: Type: Secret (a volume populated by a Secret) SecretName: admin-linuxea-token-4zpzk Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 33s default-scheduler Successfully assigned default/linuxea-sa-demo to linuxea.node-3.com Normal Pulled 31s kubelet, linuxea.node-3.com Container image "marksugar/nginx:1.14.a" already present on machine Normal Created 30s kubelet, linuxea.node-3.com Created container Normal Started 30s kubelet, linuxea.node-3.com Started container私有镜象认证的两种方式在每一次提交资源清单到api server，api server传递至kubelet，而后创建并允许一个pod，而这个pod内的容器想要启动，就需要pull一个镜象仓库的镜象，而这个镜象参考需要认证。这个认证信息在之前的配置中使用Secret，并且定义，而后使用pod中的imagePullSecrets指明使用那个Secret对象，而这个Secret对象中包含了认证私有镜象仓库的账号和密码。我们也可以在pod当中不使用imagePullSecrets来告诉pod怎么去认证下载镜象文件，而是用serviceAccountName，serviceAccountName相当于指定了sa账号，而这个sa账号附带可以认证到私有参考的认证信息的，如下：在之前创建的sa -> admin-linuxea中Image pull secrets，也就是说创建的secrets可以直接定义在sa上，然后在把sa定义到pod上，这样sa通过Image pull secrets定义secrets也能完成image的资源认证。相比较imagePullSecrets，用户只能看见sa，对于sa来讲， 是或许不到secrets信息的，相对安全些[root@linuxea sa]# kubectl describe sa admin-linuxea Name: admin-linuxea Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: admin-linuxea-token-4zpzk Tokens: admin-linuxea-token-4zpzk Events: <none>这样一来获取私有镜象认证就 有两种方式：1，imagePullSecrets字段指定认证的secrets对象2，在pod上定义serviceAccount，而后在pod附加即可Image pull secrets

linuxea:kubernetes 了解认证授权(28) kubernetes上运行着众多的应用，特别是无状态的应用，更甚有一些核心的数据。对于这些数据的访问或者管理，并不是任何人可以随意的管理使用的。因此，kubernetes对于整个系统的认证，授权，以及后续的访问控制做了非常紧密和精心的设计。通常，客户端通过客户端工具kubectl来访问kubernetes， 对于管理员或者kubectl来讲api server是作为管理的唯一入口。这联想起了ingress。这与ingress不同，ingress只是暴露服务端口，对于pod内应用程序来讲，客户端访问是不用经过api server。而api server中有众多资源管理平台，管理对应的对象(多组API，且自我迭代)，不同于pod中应用。不论如何，任何用户试图在kubernetes平台操作资源对象时，出于安全考虑 ，在访问api server之前需要做三种安全相关的操作。如下图：1，任何访问到api server之前需要做认证操作，用户具备正确的权限账号，并且通过2，认证通过，授权检查 ​ 认证通过，仅仅说明是一个合法的用户，是否拥有其他权限。就要查看授权的资源可能存在链接到其他资源依赖是否具备权限访问，权限是否在允许操作的范围内，就来到第三步3，准入控制器(Service Account Admission Controller )​ 当权限认证通过，且检查后，尽管已经拥有了操作的权限，但是用户的操作是否运行被执行，就进行准入控制kubernetes是模块化设计，授权以及准入控制都可以通过插件的方式，可由用户自定义选择，经由什么插件，又如何控制？取决于用户本身。认证这类模块认证支持多种插件认证方式，如API令牌(token-controller),交换共享密钥，创建等所谓令牌认证就是双方都有共享密钥，服务端存放密码，在登陆时进行密码验证登陆，这种方式就是对称密钥认证方式。在k8s中提供的restful接口，通过http的方式，认证的协议通过http首部进行传递，这种认证首部在传递时的预共享密钥编码信息，就叫做令牌-->token。SSL认证对于kubernetes来讲，ssl认证能让客户端认证，并且确认服务器身份在与服务器通信之前，先要求发送一个证书是否是认可的CA签署。如果发送的信息与目标主机的信息保持一致没有问题， 那就可以认为服务器身份得到认证。而在k8s通信中，服务器也需要认证客户端的身份。因此kubectl也需要有一个证书和私钥，并且必须是server颁发签署的证书，而且客户端认证也要与证书中标识的身份保持一致。并且基于ssl加密会话进行通信尽管支持多种认证，但是认证一旦通过某个插件认证通过后便认证通过，而无需向其他认证做串行检查。授权当认证完成就进入授权检查，在k8s 1.6后支持RBAC，以及node认证，web回调等。使用kubeadm安装的kubernetes集群，默认强制启用RBAC认证。默认权限全部拒绝。RABC定制的权限非常灵活，可以针对名称空间做权限控制。尽管支持多种授权，但是授权一旦通过某个插件授权通过后便获得了授权的权限，而无需向其他授权做串行检查。准入控制用于授权完成后的一些其他安全操作账号信息在k8s中的一个用户账号，大致需要一下信息：当客户端对api server发起请求，在识别的过程中，凭证有：用户名，用户id，用户组。当用户携带凭证请求的时候，会请求到一个特定的api资源。在k8s server中有多组，因此，在api请求的资源中必须标识Request Path标识，如：/apis/apps/v1/namespace/default/deployments/myapp-deploy/Request Pathk8s兼容多个版本共存，这里的版本有多个，如：beta的版本叠加，apps/v1，apps/v1beta1，apps/v1beta2/namespace/default/deployments/myapp-deploy/在资源里面，要么属于名称空间，要么属于集群级别。名称空间，pv属于集群级别，而pod,serivce,pvc等等，属于名称空间级别，所有名称空间级别，所有名称空间级别访问需要指定：/名称空间/default名称空间名称/下找deployments/名称叫myapp-deploy/的资源。用户可以对这个资源发起增删改查操作。kubectl create ,apply ,delete等操作，事实上都是被转换为一个Http协议的请求来请求的：如：http://10.10.240.161:6443/apis/apps/v1/namespace/default/deployments/myapp-deploy/通常在操作kubectl时，由于kubectl自带了认证信息，所以kubectl能操作所有的操作。在创建kubernetes集群时候，我们复制了一个配置文件到~/.kube/config。这个配置文件中包含了证书和私钥，所以我们在使用kubectl时候并不需要认证信息，如下：[root@linuxea satefulset]# cat ~/.kube/config apiVersion: v1 clusters: - cluster: certificate-authority-data: 省略号。。。。。。。 server: https://10.10.240.161:6443 name: kubernetes contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes current-context: kubernetes-admin@kubernetes kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: 省略号。。。。。。。 client-key-data: 省略号。。。。。。。我们可以使用curl进行curl请求这些url，但是curl的话就需要认证信息。可以使用kubectl proxy --port=8080创建一个porxy代理8080端口，proxy自动回和kubectl进行认证，而我们curl查看便不需要认证，而后跳过[root@linuxea satefulset]# kubectl proxy --port=8080 Starting to serve on 127.0.0.1:8080端口已经启动[root@linuxea volume]# ss -tlnp|grep 8080 LISTEN 0 128 127.0.0.1:8080 *:* users:(("kubectl",pid=10193,fd=3))curl http://localhost:8080/api/v1curl本地的8080代理端口. 会得到一个json格式的结果。此前我们知道，编写的资源清单yaml最终也会转成json格式后提交给系统使用，如下：api/v1 此前的yaml文件的指定的apiVersion: v1则是指定的这里[root@linuxea volume]# curl http://localhost:8080/api/v1/namespaces { "kind": "NamespaceList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/namespaces", "resourceVersion": "2003021" }, "items": [ { "metadata": { "name": "default", "selfLink": "/api/v1/namespaces/default", "uid": "3914423a-b975-11e8-a8ab-88882fbd1028", "resourceVersion": "5", "creationTimestamp": "2018-09-16T05:56:15Z" }, "spec": { "finalizers": [ "kubernetes" ] }, "status": { "phase": "Active" } 省略..... 省略..... 省略..... 省略..... 省略.....那么访问deploy也是如此，也是基于url进行增删改查，如：coredns[root@linuxea volume]# kubectl get deploy -n kube-system NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 2 2 2 2 14d对于k8s来讲，所有的api资源都起源于api的父树apis，此前的http://localhost:8080/api/v1/namespaces特殊链接除外（核心群组特殊的访问逻辑）。我们试图获取deployments的对象列表http://localhost:8080/apis/apps/v1/namespaces/kube-system/deployments/[root@linuxea volume]# curl http://localhost:8080/apis/apps/v1/namespaces/kube-system/deployments/ { "kind": "DeploymentList", "apiVersion": "apps/v1", "metadata": { "selfLink": "/apis/apps/v1/namespaces/kube-system/deployments/", "resourceVersion": "2003887" }, "items": [ { "metadata": { "name": "coredns", "namespace": "kube-system", "selfLink": "/apis/apps/v1/namespaces/kube-system/deployments/coredns", "uid": "3bb90cc6-b975-11e8-a8ab-88882fbd1028", "resourceVersion": "600", "generation": 1, "creationTimestamp": "2018-09-16T05:56:19Z", "labels": { "k8s-app": "kube-dns" }, "annotations": { "deployment.kubernetes.io/revision": "1" } 省略..... 省略..... 省略..... 省略..... 省略..... "spec": {或者请求coredns[root@linuxea volume]# curl http://localhost:8080/apis/apps/v1/namespaces/kube-system/deployments/coredns这些都是http格式，可以编辑，查看，修改，删除这些操作的授权http request verb请求动作，包括: get ,post,put,delete,这些http的方法会转换成api requets verb的方法，如：get，list，create，update，patch，watch，proxy，redirect，delete，delete collection。resource: 请求资源的id或者名称。subresource: 子资源。namespace,api group等。这些在request path中已经包含api server是整个访问请求进入的网关接口，用户用于身份识别，授权用于权限检查，准入控制更多的补充了授权机制，一般会在删除，创建，修改或者代理时候做补充。

linuxea:kubernetes 初探SatefulSet控制器(27) 在前面的一节中了解过SatefulSet控制器. 在看看如何创建satefulset，在创建之前，先准备好pv以便于使用VolumeClaimTemplate创建PV尽管使用VolumeClaimTemplate会自动创建pvc并且绑定pv，但是pv在这里仍然需要自己手动创建(如果你有动态供给的话另说)。仍然使用之前的nfs[root@linuxea volume]# cat pv-demo.yaml apiVersion: v1 kind: PersistentVolume metadata: name: linuxea-1 labels: name: v1 spec: nfs: path: /data/linuxea-volumes/linuxea-1 server: 10.0.1.61 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 5Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: linuxea-2 labels: name: v2 spec: nfs: path: /data/linuxea-volumes/linuxea-2 server: 10.0.1.61 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 5Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: linuxea-3 labels: name: v3 spec: nfs: path: /data/linuxea-volumes/linuxea-3 server: 10.0.1.61 accessModes: ["ReadWriteOnce"] capacity: storage: 5Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: linuxea-4 labels: name: v4 spec: nfs: path: /data/linuxea-volumes/linuxea-4 server: 10.0.1.61 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 5Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: linuxea-5 labels: name: v5 spec: nfs: path: /data/linuxea-volumes/linuxea-5 server: 10.0.1.61 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 5Giapply[root@linuxea volume]# kubectl apply -f pv-demo.yaml persistentvolume/linuxea-1 created persistentvolume/linuxea-2 created persistentvolume/linuxea-3 created persistentvolume/linuxea-4 created persistentvolume/linuxea-5 created[root@linuxea volume]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE linuxea-1 5Gi RWO,RWX Retain Available 4s linuxea-2 5Gi RWO,RWX Retain Available 4s linuxea-3 5Gi RWO Retain Available 4s linuxea-4 5Gi RWO,RWX Retain Available 4s linuxea-5 5Gi RWO,RWX Retain Available 4s[root@linuxea volume]# kubectl get pvc No resources found. [root@linuxea volume]# 创建satefulset此前，我们知道，集群内创建一个pod，pod中定义pvc类型的volumeMounts，并且关联到当前同一个名称空间的pvc,这个pvc关联集群的pv。pv我们在上面已经创建好了，而pvc则使用volumeClaimTemplates动态生成开始先创建一个名称为satefulset-linuxea的service。并且是无头服务。selector是my-satefulset每一个pod的存储卷是在template定义，而pvc是由volumeClaimTemplates自动生成创建service和StatefulSetspec: serviceName: satefulset-linuxea # 关联到无头服务，基于这个无头服务分配唯一的标识符 replicas: 2 # 副本个数 selector: # pod管理 matchLabels: app: my-satefulset template: # 定义pod模板 metadata: labels: app: my-satefulset spec: containers: ..... volumeMounts: # 定义pod自己的存储卷 - name: wwwdata mountPath: /data/wwwroot # 挂在到容器的目录 volumeClaimTemplates: # 使用volumeClaimTemplates动态生成pod pvc spec: accessModes: ["ReadWriteOnce"] storageClassName: "gluster-dynamic" resources: requests: storage: 2Gi [root@linuxea satefulset]# cat satefulset-demo.yaml apiVersion: v1 kind: Service metadata: name: satefulset-linuxea labels: app: satefulset-app spec: ports: - port: 80 name: http clusterIP: None selector: app: my-satefulset --- apiVersion: apps/v1 kind: StatefulSet metadata: name: satefulset spec: serviceName: satefulset-linuxea replicas: 2 selector: matchLabels: app: my-satefulset template: metadata: labels: app: my-satefulset spec: containers: - name: satefulset image: "marksugar/nginx:1.14.a" ports: - containerPort: 80 name: http volumeMounts: - name: wwwdata mountPath: /data/wwwroot volumeClaimTemplates: - metadata: name: wwwdata spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 5Giapply[root@linuxea satefulset]# kubectl apply -f satefulset-demo.yaml service/satefulset-linuxea created statefulset.apps/satefulset created[root@linuxea satefulset]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 13d satefulset-linuxea ClusterIP None <none> 80/TCP 5ssts是satefulset简写，可以使用kubectl get sts查看创建的satefulset状态[root@linuxea satefulset]# kubectl get sts NAME DESIRED CURRENT AGE satefulset 2 2 9s同时会自动创建pvc，为每个pod定义的pv并且绑定。使用 kubectl get pvc查看[root@linuxea satefulset]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE wwwdata-satefulset-0 Bound linuxea-3 5Gi RWO 17s wwwdata-satefulset-1 Bound linuxea-4 5Gi RWO,RWX 15s可以通kubectl get pv查看被绑定的pv[root@linuxea satefulset]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE linuxea-1 5Gi RWO,RWX Retain Available 27s linuxea-2 5Gi RWO,RWX Retain Available 27s linuxea-3 5Gi RWO Retain Bound default/wwwdata-satefulset-0 27s linuxea-4 5Gi RWO,RWX Retain Bound default/wwwdata-satefulset-1 27s linuxea-5 5Gi RWO,RWX Retain Available 27s并且pod的名称是固定的，使用 kubectl get pods -o wide查看到，这些pod的名称是可以被固定解析的[root@linuxea satefulset]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE satefulset-0 1/1 Running 0 29s 172.16.5.116 linuxea.node-3.com <none> satefulset-1 1/1 Running 0 27s 172.16.4.11 linuxea.node-2.com <none>只需要解析容器名称即可[root@linuxea satefulset]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE satefulset-0 1/1 Running 0 12m 172.16.5.117 linuxea.node-3.com <none> satefulset-1 1/1 Running 0 12m 172.16.4.12 linuxea.node-2.com <none>[root@linuxea satefulset]# kubectl exec -it satefulset-0 nslookup satefulset-0 nslookup: can't resolve '(null)': Name does not resolve Name: satefulset-0 Address 1: 172.16.5.117 satefulset-0.satefulset-linuxea.default.svc.cluster.local[root@linuxea satefulset]# kubectl exec -it satefulset-1 nslookup satefulset-1 nslookup: can't resolve '(null)': Name does not resolve Name: satefulset-1 Address 1: 172.16.4.12 satefulset-1.satefulset-linuxea.default.svc.cluster.local那这也就意味着直接使用pod名称就会被调用在集群内有可以直接dig解析。dig的域是由pod名称和服务名称组合: pod_name.service_name.ns_name.svc.cluster.local 如：satefulset-0.satefulset-linuxea.default.svc.cluster.local[root@linuxea satefulset]# dig -t A satefulset-0.satefulset-linuxea.default.svc.cluster.local @10.96.0.10 ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -t A satefulset-0.satefulset-linuxea.default.svc.cluster.local @10.96.0.10 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62089 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;satefulset-0.satefulset-linuxea.default.svc.cluster.local. IN A ;; ANSWER SECTION: satefulset-0.satefulset-linuxea.default.svc.cluster.local. 5 IN A 172.16.5.117 ;; Query time: 0 msec ;; SERVER: 10.96.0.10#53(10.96.0.10) ;; WHEN: Sat Sep 29 15:12:16 BST 2018 ;; MSG SIZE rcvd: 159 [root@linuxea satefulset]# 并且这个名称和pvc绑定[root@linuxea satefulset]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE wwwdata-satefulset-0 Bound linuxea-3 5Gi RWO 1h wwwdata-satefulset-1 Bound linuxea-4 5Gi RWO,RWX 1h删除和创建注意：事实上当删除或者创建的时候，会进行顺向创建和逆向关闭删除[root@linuxea satefulset]# kubectl delete -f satefulset-demo.yaml service "satefulset-linuxea" deleted statefulset.apps "satefulset" deleted创建[root@linuxea satefulset]# kubectl apply -f satefulset-demo.yaml service/satefulset-linuxea created statefulset.apps/satefulset created使用kubectl get pods -w 观察整个过程删除[root@linuxea volume]# kubectl get pods -w NAME READY STATUS RESTARTS AGE satefulset-0 1/1 Running 0 22m satefulset-1 1/1 Running 0 22m satefulset-0 1/1 Terminating 0 23m satefulset-1 1/1 Terminating 0 22m satefulset-0 0/1 Terminating 0 23m satefulset-1 0/1 Terminating 0 23m satefulset-1 0/1 Terminating 0 23m satefulset-1 0/1 Terminating 0 23m satefulset-0 0/1 Terminating 0 23m satefulset-0 0/1 Terminating 0 23m启动satefulset-0 0/1 Pending 0 0s satefulset-0 0/1 Pending 0 0s satefulset-0 0/1 ContainerCreating 0 0s satefulset-0 1/1 Running 0 2s satefulset-1 0/1 Pending 0 0s satefulset-1 0/1 Pending 0 0s satefulset-1 0/1 ContainerCreating 0 0s satefulset-1 1/1 Running 0 1s这个删除的过程是不会被删除的[root@linuxea satefulset]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE wwwdata-satefulset-0 Bound linuxea-3 5Gi RWO 28m wwwdata-satefulset-1 Bound linuxea-4 5Gi RWO,RWX 28m扩展现在有两个pod，当扩展到第三个甚至于第四个的时候，也会自动创建pvc请求绑定到符合的pv大小上，并且是顺序列的使用 kubectl scale sts satefulset --replicas=5进行扩展，将replicas设置为5个[root@linuxea satefulset]# kubectl scale sts satefulset --replicas=5 statefulset.apps/satefulset scaled可以观察这个扩展的过程，从0-5[root@linuxea volume]# kubectl get pods -w NAME READY STATUS RESTARTS AGE satefulset-0 1/1 Running 0 1h satefulset-1 1/1 Running 0 1h satefulset-2 0/1 Pending 0 0s satefulset-2 0/1 Pending 0 0s satefulset-2 0/1 Pending 0 0s satefulset-2 0/1 ContainerCreating 0 0s satefulset-2 1/1 Running 0 1s satefulset-3 0/1 Pending 0 0s satefulset-3 0/1 Pending 0 0s satefulset-3 0/1 Pending 0 0s satefulset-3 0/1 ContainerCreating 0 0s satefulset-3 1/1 Running 0 1s satefulset-4 0/1 Pending 0 0s satefulset-4 0/1 Pending 0 0s satefulset-4 0/1 Pending 0 0s satefulset-4 0/1 ContainerCreating 0 0s satefulset-4 1/1 Running 0 2s而后创建完成[root@linuxea satefulset]# kubectl get pods NAME READY STATUS RESTARTS AGE satefulset-0 1/1 Running 0 1h satefulset-1 1/1 Running 0 1h satefulset-2 1/1 Running 0 16s satefulset-3 1/1 Running 0 15s satefulset-4 1/1 Running 0 14s在上面提到过，创建一个pod后会自动创建pvc绑定pv。查看下pvckubectl get pvc，已经创建并且绑定不是说水墨速度慢吗[root@linuxea satefulset]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE wwwdata-satefulset-0 Bound linuxea-3 5Gi RWO 1h wwwdata-satefulset-1 Bound linuxea-4 5Gi RWO,RWX 1h wwwdata-satefulset-2 Bound linuxea-2 5Gi RWO,RWX 3m wwwdata-satefulset-3 Bound linuxea-1 5Gi RWO,RWX 3m wwwdata-satefulset-4 Bound linuxea-5 5Gi RWO,RWX 3m缩减缩减和扩展相反，是逆序的使用kubectl scale sts satefulset --replicas=2直接运行[root@linuxea satefulset]# kubectl scale sts satefulset --replicas=2 statefulset.apps/satefulset scaled也可以打补丁进行缩减 kubectl scale sts satefulset -p '{"spec":{"replicas":2}'而后使用 来观察缩减顺序，逆序从4开始关闭到2。只剩下0和1。完成规模的缩减[root@linuxea volume]# kubectl get pods -w NAME READY STATUS RESTARTS AGE satefulset-0 1/1 Running 0 1h satefulset-1 1/1 Running 0 1h satefulset-2 1/1 Running 0 20m satefulset-3 1/1 Running 0 20m satefulset-4 1/1 Terminating 0 20m satefulset-4 0/1 Terminating 0 20m satefulset-4 0/1 Terminating 0 20m satefulset-4 0/1 Terminating 0 20m satefulset-3 1/1 Terminating 0 20m satefulset-3 0/1 Terminating 0 21m satefulset-3 0/1 Terminating 0 21m satefulset-3 0/1 Terminating 0 21m satefulset-2 1/1 Terminating 0 21m satefulset-2 0/1 Terminating 0 21m satefulset-2 0/1 Terminating 0 21m satefulset-2 0/1 Terminating 0 21m[root@linuxea volume]# kubectl get pods NAME READY STATUS RESTARTS AGE satefulset-0 1/1 Running 0 1h satefulset-1 1/1 Running 0 1h滚动updateStrategy：自定义更新策略。updateStrategy默认滚动更新satefulset: spec: updateStrategy: rollingUpdate: partition: # 默认为0(partition)更新边界每个pod用名称进行标识，分别是linuxea-0,4。如果partition等于5，意味着大于等于5的pod编号将会被更新。如果没有，则不会进行更新。如上图。此时如果配置partition等于4，那便意味着更新大于等于4的pod，但是最大的只有pod4一个，那就只会更新一个，当4更新完成，在将partition修改为0（但与等于0），那就进行全部更新updateStrategy自定义更新策略设定partition设定partition为4：kubectl patch sts satefulset -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":4}}}}'[root@linuxea satefulset]# kubectl patch sts satefulset -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":4}}}}' statefulset.apps/satefulset patched而后通过kubectl describe sts satefulset查看状态[root@linuxea volume]# kubectl describe sts satefulset ... Update Strategy: RollingUpdate Partition: 4 Pod Template: ... Image: marksugar/nginx:1.14.a ... 更新partition将上面的image更新到marksugar/nginx:1.14.b，仍然通过打补丁的方式 kubectl patch sts satefulset -p '{"spec":{"template":{"spec":{"containers[0]":{"image":"marksugar/nginx:1.14.b"}}}}}'[root@linuxea satefulset]# kubectl get sts -o wide NAME DESIRED CURRENT AGE CONTAINERS IMAGES satefulset 5 5 15h satefulset marksugar/nginx:1.14.a使用set image修改到marksugar/nginx:1.14.b[root@linuxea satefulset]# kubectl set image sts/satefulset satefulset=marksugar/nginx:1.14.b statefulset.apps/satefulset image updated[root@linuxea satefulset]# kubectl get sts -o wide NAME DESIRED CURRENT AGE CONTAINERS IMAGES satefulset 5 5 15h satefulset marksugar/nginx:1.14.b此时如果pods运行的机器尚未拉取镜像，此时会进行拉取更新[root@linuxea satefulset]# kubectl get pods -o wide -w NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE satefulset-0 1/1 Running 0 15h 172.16.5.117 linuxea.node-3.com <none> satefulset-1 1/1 Running 0 15h 172.16.4.12 linuxea.node-2.com <none> satefulset-2 1/1 Running 0 13h 172.16.3.43 linuxea.node-1.com <none> satefulset-3 1/1 Running 0 13h 172.16.3.44 linuxea.node-1.com <none> satefulset-4 0/1 Terminating 0 13h 172.16.4.13 linuxea.node-2.com <none> satefulset-4 0/1 Terminating 0 13h 172.16.4.13 linuxea.node-2.com <none> satefulset-4 0/1 Terminating 0 13h 172.16.4.13 linuxea.node-2.com <none> satefulset-4 0/1 Pending 0 0s <none> <none> <none> satefulset-4 0/1 Pending 0 0s <none> linuxea.node-3.com <none> satefulset-4 0/1 ContainerCreating 0 0s <none> linuxea.node-3.com <none> satefulset-4 1/1 Running 0 2s 172.16.5.119 linuxea.node-3.com <none>而后使用kubectl get pods satefulset-4 -o yaml查看satefulset-4,也就是设定的partition的pod更新partition定义的是4，也就是说大于等于4的被更新，其他的不会被更新[root@linuxea volume]# kubectl get pods satefulset-4 -o yaml|grep image - image: marksugar/nginx:1.14.b imagePullPolicy: IfNotPresent image: marksugar/nginx:1.14.b 此时，如果要将其他的镜像都更新到marksugar/nginx:1.14.b,将partition修改为0即可kubectl patch sts satefulset -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}'[root@linuxea satefulset]# kubectl patch sts satefulset -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}' statefulset.apps/satefulset patched而后，pod会进行更新到marksugar/nginx:1.14.b[root@linuxea satefulset]# kubectl get pods -w NAME READY STATUS RESTARTS AGE satefulset-0 1/1 Running 0 15h satefulset-1 1/1 Running 0 15h satefulset-2 1/1 Running 0 13h satefulset-3 1/1 Running 0 13h satefulset-4 1/1 Running 0 11m satefulset-3 1/1 Terminating 0 13h satefulset-3 0/1 Terminating 0 13h satefulset-3 0/1 Terminating 0 13h satefulset-3 0/1 Terminating 0 13h satefulset-3 0/1 Pending 0 0s satefulset-3 0/1 Pending 0 0s satefulset-3 0/1 ContainerCreating 0 0s satefulset-3 1/1 Running 0 1s satefulset-2 1/1 Terminating 0 13h satefulset-2 0/1 Terminating 0 13h satefulset-2 0/1 Terminating 0 13h satefulset-2 0/1 Terminating 0 13h satefulset-2 0/1 Pending 0 0s satefulset-2 0/1 Pending 0 0s satefulset-2 0/1 ContainerCreating 0 0s satefulset-2 1/1 Running 0 1s satefulset-1 1/1 Terminating 0 15h satefulset-1 0/1 Terminating 0 15h satefulset-1 0/1 Terminating 0 15h satefulset-1 0/1 Terminating 0 15h satefulset-1 0/1 Pending 0 0s satefulset-1 0/1 Pending 0 0s satefulset-1 0/1 ContainerCreating 0 0s satefulset-1 1/1 Running 0 1s satefulset-0 1/1 Terminating 0 15h satefulset-0 0/1 Terminating 0 15h satefulset-0 0/1 Terminating 0 15h satefulset-0 0/1 Terminating 0 15h satefulset-0 0/1 Pending 0 0s satefulset-0 0/1 Pending 0 0s satefulset-0 0/1 ContainerCreating 0 0s satefulset-0 1/1 Running 0 1s集群内访问的版本是version number 2.0之前的image：marksugar/nginx:1.14.a是version number 1.0，由此可见，更新已经完成。statefulset的更新顺序是从倒序的[root@linuxea volume]# curl 172.16.5.120/linuxea.html linuxea-satefulset-0.com ▍ decd7c42de3ab ▍version number 2.0 [root@linuxea volume]# curl 172.16.3.46/linuxea.html linuxea-satefulset-1.com ▍ 33b9df88388ed ▍version number 2.0 [root@linuxea volume]# curl 172.16.4.14/linuxea.html linuxea-satefulset-2.com ▍ 5172054ce689c ▍version number 2.0 [root@linuxea volume]# curl 172.16.3.45/linuxea.html linuxea-satefulset-3.com ▍ edc72116a7040 ▍version number 2.0 [root@linuxea volume]# curl 172.16.5.119/linuxea.html linuxea-satefulset-4.com ▍ a978be23d0de0 ▍version number 2.0