RBAC: Role Based Access Control
Role Based Access Control is comprised of four layers:
ClusterRole - permissions assigned to a role that apply to an entire cluster
ClusterRoleBinding - binding a ClusterRole to a specific account
Role - permissions assigned to a role that apply to a specific na...
查看帮助
1kubectl explain hpa
先创建一个有资源限制的pod
1kubectl run myapp --image=ikubernetes/myapp:v1 --replicas=1 --requests='cpu=50m,memory=256Mi' --limits='cpu=50m,memory=256Mi' --labels='app=myapp' --expose --port=80
创建一个HPA
1kubectl autoscale --help //查看帮助
1kubectl autoscal...
[TOC]
statefulset的特征
稳定唯一的网络标识符
稳定持久的存储
有序平滑的部署和扩展
有序平滑的删除终止
有序的滚动更新
pod的名字必须持久有效 , 比如一个pod销毁了 , 再次重新创建 , 还必须还是原来的名字 , 因为statefulset是根据pod名称有次序的进行更新等操作 , 次序还不能乱 , 比如创建的时候是1-9 那么更新的时候就是9-1 , 那么如何保证持久有效呢 ,得使用headless服务 直达ip地址 还得给pod配置一个唯一的名称, 每个节点得有自己专用的存储 , 使用volumeClaimTemolates 来生成一个专有的pvc 之后在...
部署123kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml//详细情况可以去github上去看 地址是https://github.com/kubernetes/dashboard
将Service改成NodePort1kubectl patch svc kubernetes-dashboard -p '{"spec":{&quo...
kube-proxy一直watch着api-service的变动 , 如果监听到了api-service关于service的任何变动 , kube-proxy就调度给后端
service实现方式
userspace:
请求——->serviceIP(iptables)—–>kube-proxy(kube-proxy是运行在用户空间的)—->serviceIP(iptables)—–>backend(后端pod)
iptables
请求——>iptables——–>pod
ipvs
请求——->iptables——->pod
se...
我们暴露外部服务一般用的是NodePort , 但是nodeport暴露服务有一个问题 , 就是每个node都会占一个端口去暴露, 而且前面没有统一的服务入口 没有负载均衡 ,nodeport是基于4层调度 这也是问题
NodePort的访问路径是
NodePort: client—–>NodeIP:NodePort—–>ClusterIP:ServicePort—->PodIP:containerPort
在访问NodeIP:NodePort 的时候 , 要加一个负载均衡
我们可以部署一个基于七层的pod调度器 , 运行在用户空间 , 来接管访问的流量 , 监听在宿...
存储卷快照和pvc于pv创建的过程很类似
都是:
PVC-—>StorageClass—->PV
VolumeSnapshot—->VolumeSnapshotClass—–>VolumeSnapshotContent
在kubernetes中用VolumeSnapshotContent 和VolumeSnapshot这样的API资源去为用户和管理员创建卷快照
其中:
VolumeSnapshotContent是从集群中指定的volume中获取的快照, 他很像PV资源一样
VolumeSnapshot是用户想从某个指定volume获取快照的一个请求 , 就像集...
首先DaemonSet Controller会从Etcd里获取node的节点列表, 之后一个一个区遍历检查,看看node是不是有一个特定的label(这个label是创建DaemonSet 时指定的,即spec.template.metadata.labels) , 如果有这个pod就不管,没有就创建, 多了就删
在创建pod的时候, 会指定pod在指定的node上创建, 即在创建pod的时候DaemonSet 会自动在pod的API对象上加一个nodeAffinity字段 , 这个字段的作用就是指定pod只能运行在当前节点
这个字段的具体增加是:
123456789101112131...
我们知道deployment是通过管理ReplicaSet来进行管理pod的, 但是DaemonSet控制器直接控制的就是pod,那么他是如何进行版本的维护呢
在kubernetes v1.7之后 有一个对象是ControllerRevision 是专门用来管理某种Controller对象的版本的
比如某个DaemonSet的名字为A
我们查看这个 DaemonSet controller的版本
1kubelet get controllerrevision -n kube-system -l name=A
这里会获得一个版本名字 , 命名规则是[controller-name]-[ha...
在deployment有一个对象字段,叫RollingUpdateStrategy
12345678910111213apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec:... strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1
maxSurge指的是控制器还可以创建多个新的pod,maxUnavailable表示可以控...
