k8s的pod,Service,ReplicationController,Deployment对象
通过编写yaml文件创建对象,出现问题可以查看文件找到配置
Pod(容器组):Pod是Kubernetes中最基本的部署单元,它是一组运行在同一主机上的容器的集合。Pod可以包含一个或多个容器,这些容器共享相同的网络命名空间和存储卷。Pod提供了一个逻辑上独立的部署单元,用于运行应用程序的实例。
Pod定义文件包括三部分:apiVersion、kind和spec。apiVersion指定了Kubernetes API的版本号。kind指定了该资源类型为Pod。spec描述了Pod的详细配置,包括容器的名称、镜像、端口映射等。
apiVersion: v1
kind: Pod #对象
metadata:
name: my-pod #自定pod名称
spec:
containers:
- name: nginx #自定容器的名称
image: nginx:latest #拉取的镜像,nginx最新版
Service对象是Kubernetes中的一种资源对象,用于定义一组Pod的访问方式和网络策略。它可以为一组Pod创建一个稳定的端点,并提供负载均衡、服务发现等功能。
Service对象具有以下主要特点:
稳定的虚拟IP:每个Service都会通过一个虚拟IP(Cluster IP)来公开服务。这个虚拟IP不会随着Pod的创建、删除或重启而改变,保证了服务的稳定性。
透明的服务发现:通过Service对象,其他应用或者服务可以通过Service名称作为DNS名来访问该服务。Kubernetes内部的DNS解析机制会自动将Service名称解析为相应的虚拟IP,从而实现无需关注底层Pod的访问。
负载均衡:当多个Pod副本属于同一个Service时,Service会根据一定的负载均衡算法,将请求分发到各个Pod上,实现请求的负载均衡。
定义端口映射:Service可以定义一组端口映射规则,将外部请求的端口映射到Pod内部的端口上。这样可以隐藏具体Pod的网络细节,只暴露Service的端口给外界。
Service类型:Kubernetes支持不同类型的Service,包括ClusterIP、NodePort和LoadBalancer。ClusterIP类型是默认类型,通过集群内部的虚拟IP访问服务;NodePort类型允许将Service公开到每个节点上的随机端口上;LoadBalancer类型可以将服务暴露到云提供商或硬件负载均衡器上。
通过定义Service对象,可以实现将一组Pod作为一个逻辑单元进行管理和访问,提供了更灵活、高可用的服务资源。
port
:port
字段定义了Service暴露给集群内部其他应用程序或Service的端口号。在示例中,通过设置port: 80
,我们将Service暴露在80端口上,其他应用程序或Service可以通过该端口访问Service提供的服务。targetPort
:targetPort
字段定义了Service将请求转发到后端Pod的哪个容器端口。在示例中,设置targetPort: 8080
意味着Service将所有传入的请求转发到Pod中运行的容器的8080端口上。这样,Service作为一个抽象层,向外公开了统一的端口(即port
),并将请求转发到Pod内部具体的容器端口(即targetPort
)。nodePort
:nodePort
字段定义了Service暴露给集群节点的端口号。当Service类型设置为NodePort
时,Kubernetes会在集群的每个节点上打开同样的端口,从而允许从节点访问Service。在示例中,通过设置nodePort: 30001
,我们指定了将Service公开到集群节点的30001端口上。
apiVersion: v1
kind: Service #对象
metadata:
name: my-service # Service名称
spec:
type: NodePort #设置自己指定nodePort
selector:
app: my-app # 根据标签选择Pod的selector
ports:
- name: my-name #自定义端口名称
nodePort: 30001 # node端口名称,端口范围30000-32767
port: 80 # Service端口
targetPort: 8080 # Pod容器端口
ReplicationController和Deployment都是用于在Kubernetes中管理Pod副本的核心对象,但它们之间存在一些区别。
选择器:ReplicationController使用
spec.selector
字段来定义与受其管理的Pod副本相关联的标签选择器,而Deployment使用spec.selector.matchLabels
字段来实现相同的功能。Deployment提供了更灵活的选择器功能,以便能够针对较大的应用程序进行精细控制。升级:ReplicationController不支持滚动升级,需要手动更新模板以升级Pod,这可能会导致应用程序停机时间。Deployment支持滚动升级和回滚功能,允许您逐步更新应用程序版本,以确保最小化停机时间。
副本集:ReplicationController创建一组Pod副本,每个副本都与受其管理的其他副本相同。Deployment使用ReplicaSet对象来创建一组Pod副本,每个副本都可以有不同的标签和选择器,使得您可以更容易地进行部署的升级和回滚操作。
更新策略:Deployment提供多种更新策略,例如Recreate和RollingUpdate策略,可以帮助您控制部署的更新方式。而ReplicationController只会简单地替换所有Pod副本来达到更新的目的。
创建ReplicationController对象
apiVersion: v1
kind: ReplicationController #对象
metadata:
name: my-replication-controller #自定义RC名称
spec:
replicas: 3 #创建几个pod
selector:
app: my-app #标签,键值对的形式,app是键,my-app是值
template: #指定了用于创建和管理Pod副本的模板。
metadata:
labels:
app: my-app #引用上面同一个标签,不要写错
spec:
containers:
- name: my-container #自定义容器名字
image: nginx:latest #拉取的镜像
ports:
- containerPort: 80 #指定公开端口
Deployment对象的版本不一样,需要注意,比ReplicationController的功能要多,可以热升级,回滚功能
apiVersion: apps/v1 #注意Deployment版本
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector: #指定了一个标签选择器。
matchLabels: #用于定义一组标签键值对
app: my-app #标签键值对
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx:latest
ports:
- containerPort: 80
同一个文件可以同时创建多个对象,下列例子同时创建了Deployment,和Service,并且将Deployment容器的标签加入到Service内
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx1
namespace: default
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: daocloud.io/library/nginx:1.12.0-alpine
ports:
- containerPort: 80
--- #分割线,下面创建Service
apiVersion: v1
kind: Service
metadata:
name: serv1
spec:
type: NodePort
ports:
- port: 7788
nodePort: 30012
targetPort: 80
selector:
app: nginx
使用kubectl apply -f 文件的路径,根据文件分配node节点拉取镜像,同时创建serv1的对象,访问宿主机的ip加30012端口可以进入nginx的web页面
kubectl get service serv1
查看创建的Service
kubectl get deployments.apps nginx1
查看创建的deployment加键值对,可以看到该对象运行状态