Kubernetes中pod分类、核心组件、网络模型及kubectl命令使用
文章目录Kubernetes中pod分类、核心组件、网络模型及kubectl命令使用1.k8s中pod分类2.核心组件3.网络模型4.kubectl常用命令使用Kubernetes中pod分类、核心组件、网络模型及kubectl命令使用1.k8s中pod分类1Infrastructure Container:基础容器•维护整个Pod网络空间2InitContainers:初始化容器•先于业务容器开
Kubernetes中pod分类、核心组件、网络模型及kubectl命令使用
1.k8s中pod分类
1Infrastructure Container:基础容器
•维护整个Pod网络空间
2InitContainers:初始化容器
•先于业务容器开始执行
3Containers:业务容器
•并行启动
pod分为两类:自主式pod与控制器管理的pod
自主式pod由k8s管理器进行管理,而static pod由kubelet进行创建与管理
自主式pod
自主式pod总是在前台运行,同时接受k8s管理与调度,当集群当中的pod因为某种原因停止,k8s会根据其副本的数量,重新的生成对应的pod
自我管理的pod,创建以后仍然需要提交给apiserver,由apiserver接收以后借助于调度器将其调度至指定的node节点,由node启动此pod
如果此pod出现故障,需要重启容器则由kubelet来完成
如果node节点故障了,那么此pod将会消失。其无法实现全局调度。所以不推荐使用此种pod
2.核心组件
Kubernetes主要由以下几个核心组件组成:
- etcd保存了整个集群的状态;
- apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;
- controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
- scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
- kubelet负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理;
- Container runtime负责镜像管理以及Pod和容器的真正运行(CRI);
- kube-proxy负责为Service提供cluster内部的服务发现和负载均衡;
k8s的设计理念类似于linux的分层架构
1.master 核心控制 是老大
它主要负责调度,决定服务在哪里运行,master运行linux系统,可以是物理机或虚拟机,master是k8s Cluster的大脑,运行着的守护进程服务包括:kube-apiserver,kube-scheduler,kube-controller-manager,etcd,Pod网络。
2.node 做事儿的
除了master剩下的都是node 节点,node是运行容器里的应用,被master管理,负责监控并汇报容器状态(每个node里可以有很多pod,每个pod里有一个pause容器,专门保存剩余的容器的状态,通过管理pause,即可达到管理所有容器的效果),同时根据master的要求管理容器的生命周期,也运行在linux系统,可以是物理机或虚拟机。
3.Pod
k8s的最小单元,也是最重要最基本的概念,每个pod包含一个或多个容器,pod容器会作为整体被master调度到node上运行,k8s为每个pod都分配了IP地址,此IP地址在容器内共享,k8s 一个pod里的容器和另外主机上的pod里的容器能够直接通信。
3.网络模型
分为三种网络模型:节点网络、service集群网络、pod网络
同一pod内的多个容器间如何通信?
lo网卡
各pod之间如何通信?
1.物理桥桥接,规模大的情况下会产生广播风暴
2.Overlay Network,通过隧道的方式转发报文
容器和容器之间的网络
- 在k8s中每个Pod中管理着一组Docker容器,这些Docker容器共享同一个网络命名空间。
- Pod中的每个Docker容器拥有与Pod相同的IP和port地址空间,并且由于他们在同一个网络命名空间,他们之间可以通过localhost相互访问。
什么机制让同一个Pod内的多个docker容器相互通信那?其实是使用Docker的一种网络模型:–net=container
container模式指定新创建的Docker容器和已经存在的一个容器共享一个网络命名空间,而不是和宿主机共享。新创建的Docker容器不会创建自己的网卡,配置自己的 IP,而是和一个指定的容器共享 IP、端口范围等
每个Pod容器有有一个pause容器其有独立的网络命名空间,在Pod内启动Docker容器时候使用 –net=container就可以让当前Docker容器加入到Pod容器拥有的网络命名空间(pause容器)
pod和pod之间的网络
- k8s中,每个Pod拥有一个ip地址,不同的Pod之间可以直接使用改ip与彼此进行通讯
- 在同一个Node上,从Pod的视角看,它存在于自己的网络命名空间中,并且需要与该Node上的其他网络命名空间上的Pod进行通信。
那么是如何做到的?这多亏了使用linux虚拟以太网设备或者说是由两个虚拟接口组成的veth对使不同的网络命名空间链接起来,这些虚拟接口分布在多个网络命名空间上(这里是指多个Pod上)。
为了让多个Pod的网络命名空间链接起来,我们可以让veth对的一端链接到root网络命名空间(宿主机的),另一端链接到Pod的网络命名空间。
每对Veth就像一根接插电缆,连接两侧并允许流量在它们之间流动;这种veth对可以推广到同一个Node上任意多的Pod上,如上图这里展示使用veth对链接每个Pod到虚拟机的root网络命名空间。
下面我们看如何使用网桥设备来让通过veth对链接到root命名空间的多个Pod进行通信。
linux以太网桥(Linux Ethernet bridge)是一个虚拟的2层网络设备,目的是把多个以太网段链接起来,网桥维护了一个转发表,通过检查转发表通过它传输的数据包的目的地并决定是否将数据包传递到连接到网桥的其他网段,网桥代码通过查看网络中每个以太网设备特有的MAC地址来决定是传输数据还是丢弃数据。
同一个node和pod之间的网络通信
鉴于每个Pod有自己独立的网络命名空间,我们使用虚拟以太网设备把多个Pod的命名空间链接到了root命名空间,并且使用网桥让多个Pod之间进行通信,
- 通过网桥这里把veth0和veth1组成为一个以太网,他们直接是可以直接通信的,另外这里通过veth对让pod1的eth0和veth0、pod2的eth0和veth1关联起来,从而让pod1和pod2相互通信。
- Pod 1通过自己默认的以太网设备eth0发送一个数据包,eth0把数据传递给veth0,数据包到达网桥后,网桥通过转发表把数据传递给veth1,然后虚拟设备veth1直接把包传递给Pod2网络命名空间中的虚拟设备eth0.
4.kubectl常用命令使用
create
从文件活标准输出中创建pod
创建一个deployment类型的pod,名字是sb,使用的镜像是nginx
[root@master ~]# kubectl create deployment by --image=nginx
deployment.apps/by created
[root@master ~]# kubectl create deployment sb --image=nginx
deployment.apps/sb created
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 0/1 ContainerCreating 0 28s
nginx-6799fc88d8-6z4mk 1/1 Running 2 8h
sb-8fb46785f-7r9pn 0/1 ContainerCreating 0 10s
[root@master ~]#
创建deployment类型的pod,名字是sb1,使用的镜像是nginx,replicas是指定创建的个数
[root@master ~]# kubectl create deployment sb1 --image=nginx --replicas=3
deployment.apps/sb1 created
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 111s
nginx-6799fc88d8-6z4mk 1/1 Running 2 8h
sb-8fb46785f-7r9pn 1/1 Running 0 93s
sb1-cc9676664-9cklr 1/1 Running 0 10s
sb1-cc9676664-9lftf 1/1 Running 0 10s
sb1-cc9676664-cc8dn 0/1 ContainerCreating 0 10s
[root@master ~]#
创建一个名为sb2的pod,运行nginx镜像并暴露端口,这里只能暴露端口,并没有其他的作用,也不能访问
[root@master ~]# kubectl create deployment sb2 --image=nginx --port=80
deployment.apps/sb2 created
run
在集群中运行一个指定的镜像的pod
使用run运行的pod默认为pod类型
[root@master ~]# kubectl run nginx --image nginx
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 8m52s
nginx 1/1 Running 0 3m55s
sb2-b79db78c4-5xtv4 1/1 Running 0 5m18s
[root@master ~]#
运行一个pod叫sb,使用镜像nginx,指定标签为app=web
[root@master ~]# kubectl run sb --image=nginx --labels="app=web"
pod/sb created
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 10m
nginx 1/1 Running 0 6m2s
sb 1/1 Running 0 24s
sb2-b79db78c4-5xtv4 1/1 Running 0 7m25s
[root@master ~]#
查看sb的详细描述
[root@master ~]# kubectl describe pod sb
Name: sb
Namespace: default
Priority: 0
Node: node1/192.168.100.170
Start Time: Sun, 19 Dec 2021 06:50:18 -0500
Labels: app=web
Annotations: <none>
Status: Running
IP: 10.244.1.8
IPs:
IP: 10.244.1.8
Containers:
sb:
Container ID: docker://4a1dd5d99598f3db72d480c0298ebad66036bab6d14b44af0c0fc7e9a8065d2e
Image: nginx
Image ID: docker-pullable://nginx@sha256:9522864dd661dcadfd9958f9e0de192a1fdda2c162a35668ab6ac42b465f0603
Port: <none>
Host Port: <none>
State: Running
Started: Sun, 19 Dec 2021 06:50:36 -0500
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-glz77 (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-glz77:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-glz77
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 69s default-scheduler Successfully assigned default/sb to node1
Normal Pulling 69s kubelet Pulling image "nginx"
Normal Pulled 53s kubelet Successfully pulled image "nginx" in 16.010236464s
Normal Created 53s kubelet Created container sb
Normal Started 52s kubelet Started container sb
[root@master ~]#
再次创建几个,使他们的表签都是nginx
[root@master ~]# kubectl run sb1 --image=nginx --labels="app=web"
pod/sb1 created
[root@master ~]# kubectl run sb2 --image=nginx --labels="app=web"
pod/sb2 created
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 13m
nginx 1/1 Running 0 8m7s
sb 1/1 Running 0 2m29s
sb1 0/1 ContainerCreating 0 11s
sb2 1/1 Running 0 7s
sb2-b79db78c4-5xtv4 1/1 Running 0 9m30s
[root@master ~]#
删除时指定标签就可以删除对应标签的pod
[root@master ~]# kubectl delete pod -l app=web
pod "sb" deleted
pod "sb1" deleted
pod "sb2" deleted
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 13m
nginx 1/1 Running 0 8m59s
sb2-b79db78c4-5xtv4 1/1 Running 0 10m
[root@master ~]#
试运行,不会真正的创建运行,只是试运行
[root@master ~]# kubectl run by1 --image=nginx --dry-run=client
pod/by1 created (dry run)
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 15m
nginx 1/1 Running 0 10m
sb2-b79db78c4-5xtv4 1/1 Running 0 11m
[root@master ~]#
启动一个pod,放在前台,如果退出,则不重新启动
[root@master ~]# kubectl run -i -t by1 --image=busybox --restart=Never
If you don't see a command prompt, try pressing enter.
/ # ls
bin dev etc home proc root sys tmp usr var
/ #
delete
删除资源的文件名,标准输出,资源和名称,或资源和标签选择器
查看所存在的service和pod
[root@master ~]# kubectl get pods,svc
NAME READY STATUS RESTARTS AGE
pod/by-6589fb64ff-wmgxg 1/1 Running 0 24m
pod/by1 0/1 Completed 0 3m15s
pod/nginx 1/1 Running 0 19m
pod/sb2-b79db78c4-5xtv4 1/1 Running 0 20m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8h
[root@master ~]#
删除和pod名字叫nginx的
[root@master ~]# kubectl delete deployment,pod nginx
pod "nginx" deleted
Error from server (NotFound): deployments.apps "nginx" not found //这里我servce里面本来就没有nginx所以并没有找到它
[root@master ~]# kubectl get pod,svc
NAME READY STATUS RESTARTS AGE
pod/by-6589fb64ff-wmgxg 1/1 Running 0 27m
pod/by1 0/1 Completed 0 6m
pod/sb2-b79db78c4-5xtv4 1/1 Running 0 23m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8h
[root@master ~]#
get
查看创建的pod
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 28m
by1 0/1 Completed 0 6m47s
sb2-b79db78c4-5xtv4 1/1 Running 0 24m
[root@master ~]#
查看svc
[root@master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 9h
[root@master ~]#
也可以pod和svc一起查看,注意要用“,”隔开
[root@master ~]# kubectl get pod,svc
NAME READY STATUS RESTARTS AGE
pod/by-6589fb64ff-wmgxg 1/1 Running 0 28m
pod/by1 0/1 Completed 0 7m39s
pod/sb2-b79db78c4-5xtv4 1/1 Running 0 25m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 9h
[root@master ~]#
查看名称空间
[root@master ~]# kubectl get ns
NAME STATUS AGE
default Active 9h
kube-node-lease Active 9h
kube-public Active 9h
kube-system Active 9h
[root@master ~]#
除了可以查看pod,还可以查看指定的pod
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
by-6589fb64ff-wmgxg 1/1 Running 0 30m
by1 0/1 Completed 0 8m55s
sb2-b79db78c4-5xtv4 1/1 Running 0 26m
[root@master ~]# kubectl get deployment by
NAME READY UP-TO-DATE AVAILABLE AGE
by 1/1 1 1 30m
[root@master ~]#
列出一个由pod中指定的类型和名称标识的pod,可以使用json或者yaml输出格式
[root@master ~]# kubectl get deployment by -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2021-12-19T11:39:43Z"
generation: 1
labels:
app: by
managedFields:
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:app: {}
f:spec:
f:progressDeadlineSeconds: {}
f:replicas: {}
f:revisionHistoryLimit: {}
f:selector: {}
f:strategy:
f:rollingUpdate:
.: {}
f:maxSurge: {}
f:maxUnavailable: {}
f:type: {}
f:template:
f:metadata:
f:labels:
.: {}
f:app: {}
f:spec:
f:containers:
k:{"name":"nginx"}:
.: {}
f:image: {}
f:imagePullPolicy: {}
f:name: {}
f:resources: {}
f:terminationMessagePath: {}
f:terminationMessagePolicy: {}
f:dnsPolicy: {}
f:restartPolicy: {}
f:schedulerName: {}
f:securityContext: {}
f:terminationGracePeriodSeconds: {}
manager: kubectl-create
operation: Update
time: "2021-12-19T11:39:43Z"
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.: {}
f:deployment.kubernetes.io/revision: {}
f:status:
f:availableReplicas: {}
f:conditions:
.: {}
k:{"type":"Available"}:
.: {}
f:lastTransitionTime: {}
f:lastUpdateTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"Progressing"}:
.: {}
f:lastTransitionTime: {}
f:lastUpdateTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
f:observedGeneration: {}
f:readyReplicas: {}
f:replicas: {}
f:updatedReplicas: {}
manager: kube-controller-manager
operation: Update
time: "2021-12-19T11:40:25Z"
name: by
namespace: default
resourceVersion: "4455"
uid: 5699d40d-472f-4348-9975-62c2c332e334
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: by
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: by
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
status:
availableReplicas: 1
conditions:
- lastTransitionTime: "2021-12-19T11:40:25Z"
lastUpdateTime: "2021-12-19T11:40:25Z"
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
- lastTransitionTime: "2021-12-19T11:39:43Z"
lastUpdateTime: "2021-12-19T11:40:25Z"
message: ReplicaSet "by-6589fb64ff" has successfully progressed.
reason: NewReplicaSetAvailable
status: "True"
type: Progressing
observedGeneration: 1
readyReplicas: 1
replicas: 1
updatedReplicas: 1
[root@master ~]#
更多推荐
所有评论(0)