前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >k8s 之yaml文件基本格式

k8s 之yaml文件基本格式

作者头像
小手冰凉
发布于 2020-08-28 01:39:06
发布于 2020-08-28 01:39:06
1.3K00
代码可运行
举报
文章被收录于专栏:小手冰凉小手冰凉
运行总次数:0
代码可运行

注:yaml文件严格要求缩进,默认不同层次等级是两个空格的缩进 1、使用httpd镜像创建一个Deployment资源对象

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[root@docker-k8s01 ~]# mkdir yaml
[root@docker-k8s01 ~]# cd yaml/
[root@docker-k8s01 yaml]# vim test01.yaml
kind: Deployment              # 指定要创建的资源对象类型
apiVersion: extensions/v1beta1                  # 指定deployment所对应的API版本
metadata:
  name: test01-deploy                         # 定义deployment的名称
spec:
  replicas: 4                   # 定义需要创建pod副本的数量
  template:
    metadata:
      labels:
        user: zyz                               # 指定pod的标签
    spec:
      containers:
      - name: httpd                         # 指定容器的名称
        image: httpd               # 指定创建容器基于的镜像
[root@docker-k8s01 yaml]# kubectl apply -f test01.yaml            # 执行编写的文件
deployment.extensions/test01-deploy created            # 返回信息显示已经创建
#注:如果不知道某个资源对象所对应的API版本,可以通过此命令查看
[root@docker-k8s01 yaml]# kubectl explain deployment
KIND:     Deployment
VERSION:  extensions/v1beta1              # 这就是Deployment资源所对应的API版本

#确定所执行的yaml文件生成了我们所需数量的pod
[root@docker-k8s01 ~]# kubectl get deployments test01-deploy 
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
test01-deploy   4/4     4            4           2m19s

查看其pod标签,是否是我们定义的label

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
#查看这个资源对象的详细信息
[root@docker-k8s01 ~]# kubectl describe deployments test01-deploy   
Name:                   test01-deploy
Namespace:              default
CreationTimestamp:      Wed, 26 Aug 2020 11:26:28 +0800
Labels:                 user=zyz               # 这里就是该资源对象的标签

2、创建一个svc资源对象与上述Deployment资源对象关联。且能够对外网提供服务。映射节点端口为:32123

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[root@docker-k8s01 yaml]# vim httpd-service.yaml

kind: Service
apiVersion: v1
metadata:
  name: httpd-service
spec:
  type: NodePort                      # 这里需要指定类型为“NodePort”,否则默认是cluster IP
  selector:
    user: zyz                     # 与deployment资源对象的这个标签进行关联
  ports:  
  - protocol: TCP                       # 指定协议
    port: 79                         # 这里指定要映射到的Cluster  IP的端口
    targetPort: 80                  # 这里指定的是要映射pod中的端口
    nodePort: 32123                 # 这里指定的是映射到宿主机的端口
#执行刚刚编辑的文件
[root@docker-k8s01 yaml]# kubectl apply -f httpd-service.yaml 
service/httpd-service created           
[root@docker-k8s01 yaml]# kubectl get svc httpd-service 
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
httpd-service   NodePort   10.102.10.20   <none>        79:32123/TCP   48s
#可以看到将指定的群集端口映射到了本地的32123

现在就可以使用client访问k8s群集中任意一个节点的32123端口,即可看到pod所提供的服务

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
#查看该service的详细信息
[root@docker-k8s01 yaml]# kubectl get svc httpd-service 

返回的信息如下(只能显示少量IP,剩下的只是被省略了,而不是未指定)

既然上面说到了,endpoint指定的都是后端pod的IP地址,那么就来查看验证一下,是否正确

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
#输出后端pod的IP地址
#可以确认查看的IP能对应上上面service的endpoint指定的IP
[root@docker-k8s01 yaml]# kubectl get pod -o wide | awk '{print$6}'
IP
10.244.1.3
10.244.2.3
10.244.2.2
10.244.1.2

查看svc映射endpoint的详细情况,并详细说明负载均衡的底层原理

3、当我们做完上述操作后,client是可以访问我们pod提供的服务的(并且是负载均衡的效果),那么这是一个什么样的实现过程呢?依赖什么实现的? 其实,背后的原理并没有那么高大上,kube-proxy通过iptables的转发机制来实现负载均衡的效果的,先定义目标IP是service提供的群集IP,然后使用“-j”选项转发到其他iptables规则

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[root@docker-k8s01 yaml]# kubectl get svc httpd-service | awk '{print$3}'
CLUSTER-IP
10.102.10.20                           # 查看到service的群集IP
[root@docker-k8s01 yaml]# iptables-save > a.txt            # 将iptables规则输出到文件中,方便我们查找
[root@docker-k8s01 yaml]# vim a.txt          # 打开导出的规则进行查看

搜索我们的群集IP,可以看到,当目标地址是群集IP地址时,就会转发到另一个规则“KUBE-SVC-X2P42VLQEZCHLPKZ”,如下

那么,现在继续搜索它转发到的规则上

上面的图中,就是与他实现负载均衡相关的策略的,我们一共四个pod,所以上图中的第一个规则使用了random的算法,只有0.25(1/4)的几率采用这个规则,当到达第二条规则后,则有0.33的几率,因为去除前一个pod,还剩下三个pod,10/3=0.33,这就是这个几率的由来,依次类推,当到达最后一个规则后,那么就不用指定几率了,肯定是它来处理这条请求。

附:为node节点打标签,以便使pod运行在指定的节点

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
#给节点node01打标签“disktype=ssd”(自定义的标签)
[root@docker-k8s01 yaml]# kubectl label nodes node01 disktype=ssd

#相应的yaml文件如下:
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        app: httpd-server
    spec:
      containers:
      - name: httpd
        image: 192.168.171.151:5000/httpd:v1
        ports:
        - containerPort: 80
      nodeSelector:                //指定标签选择器
        disktype: ssd 
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2020/08/26 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
k8s资源对象的升级、回滚、扩容、缩容
命令的方式创建资源,理解命令运行之后的动作,通过查看资源的方式,总结Pod名称的由来
小手冰凉
2020/08/27
7080
K8S的名称空间创建&&版本的升级、回滚操作
2、在master节点,自定义一个镜像,基于nginx镜像,默认界面内容改为:Version:v1,版本2内容为:Version:v2.版本3内容为:Version:v3
小手冰凉
2020/08/28
5010
K8S的名称空间创建&&版本的升级、回滚操作
再战 k8s(15):Ingress和Ingress Controller
从前面的学习,我们可以了解到Kubernetes暴露服务的方式目前只有三种:LoadBlancer Service、ExternalName、NodePort Service、Ingress;而我们需要将集群内服务提供外界访问就会产生以下几个问题:
看、未来
2022/05/06
1.7K0
再战 k8s(15):Ingress和Ingress Controller
Kubernetes系列之理解K8s Service的几种模式
我们知道pod的ip不是固定的,是根据所在宿主机的docker0网卡生成的,每次重启,更新,调度等情况IP都会变,那pod与pod之间需要互相调用,肯定不能用ip的,因为地址不是固定的, 如何能保障pod之前访问的可靠性,由此就衍生出Service的概念。
程序员同行者
2019/03/29
2.4K0
Kubernetes系列之理解K8s Service的几种模式
k8s的YAML与集群访问
查看服务详情 kubectl describe svc test-k8s ,可以发现 Endpoints 是各个 Pod 的 IP,也就是他会把流量转发到这些节点。
爽朗地狮子
2022/09/22
6640
K8s——MySQL实现数据持久化
5、创建pod+svc(service) 这个pod是提供的MySQL服务,并将其映射到宿主机,可以做和client端通信
小手冰凉
2020/09/11
2K0
k8s实战之部署PHP/Java网站
对k8s刚入门的朋友而言,光搭建k8s集群是不够的,我们需要更多的理论加实战,才能更好的掌握k8s的好处,当我们成功部署一个k8s集群之后,我们需要在实际项目中进行应用,本文简单的介绍了当前比较主流的PHP/Java网站的部署
没有故事的陈师傅
2019/09/25
6.3K1
k8s实战之部署PHP/Java网站
K8s——Ingress-nginx原理及配置
在Kubernetes中,服务和Pod的IP地址仅可以在集群网络内部使用,对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务,在Kubernetes中目前提供了以下几种方案:
小手冰凉
2020/09/15
6.7K0
K8s——Ingress-nginx原理及配置
ReplicaSet && DaemonSet 资源对象
用于确保由其掌控的Pod对象副本数量,能够满足用户期望,多则删除,少则通过模板创建。
小手冰凉
2020/09/10
4390
ReplicaSet && DaemonSet 资源对象
K8S基础搭建使用
由上可见,需要本地镜像仓库需要 pod-infrastructure:latest 这个 pod 基础镜像,所以需要在拉取镜像 docker pull tianyebj/pod-infrastructure,并且 push 到本地镜像仓库
cuijianzhe
2022/06/14
5660
K8S基础搭建使用
k8s——针对有状态服务实现数据持久化
对服务器程序来说,究竟是有状态服务,还是无状态服务,其判断依旧是指两个来自相同发起者的请求在服务器端是否具备上下文关系。如果是状态化请求,那么服务器端一般都要保存请求的相关信息,每个请求可以默认地使用以前的请求信息。而对于无状态请求,服务器端所能够处理的过程必须全部来自于请求所携带的信息,以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息。 无状态的服务器程序,最著名的就是WEB服务器。每次HTTP请求和以前都没有什么关系,只是获取目标URI。得到目标内容之后,这次连接就被杀死,没有任何痕迹。在后来的发展进程中,逐渐在无状态化的过程中,加入状态化的信息,比如COOKIE。服务端在响应客户端的请求的时候,会向客户端推送一个COOKIE,这个COOKIE记录服务端上面的一些信息。客户端在后续的请求中,可以携带这个COOKIE,服务端可以根据这个COOKIE判断这个请求的上下文关系。COOKIE的存在,是无状态化向状态化的一个过渡手段,他通过外部扩展手段,COOKIE来维护上下文关系。 状态化的服务器有更广阔的应用范围,比如MSN、网络游戏等服务器。他在服务端维护每个连接的状态信息,服务端在接收到每个连接的发送的请求时,可以从本地存储的信息来重现上下文关系。这样,客户端可以很容易使用缺省的信息,服务端也可以很容易地进行状态管理。比如说,当一个用户登录后,服务端可以根据用户名获取他的生日等先前的注册信息;而且在后续的处理中,服务端也很容易找到这个用户的历史信息。 状态化服务器在功能实现方面具有更加强大的优势,但由于他需要维护大量的信息和状态,在性能方面要稍逊于无状态服务器。无状态服务器在处理简单服务方面有优势,但复杂功能方面有很多弊端,比如,用无状态服务器来实现即时通讯服务器,将会是场恶梦。
小手冰凉
2020/09/15
2.3K0
k8s 架构、基本概念及命令
API server: 是k8s 集群的前端接口,各种客户端工具以及k8s的其他组件 可以通过它管理k8s集群的各种资源。它提供了HTTP/HTTPS RESTful API, 即K8S API.
小手冰凉
2020/08/20
8000
k8s 架构、基本概念及命令
K8s的Service详解
● 在kubernetes中,Pod是应用程序的载体,我们可以通过Pod的IP来访问应用程序,但是Pod的IP地址不是固定的,这就意味着不方便直接采用Pod的IP对服务进行访问。
大忽悠爱学习
2022/09/28
1.4K0
K8s的Service详解
k8s群集的三种Web-UI界面部署
//这里使用的dashboard版本较高,相较于之前的版本访问必须使用火狐浏览器,这里不需要。
小手冰凉
2020/09/15
4.2K0
k8s群集的三种Web-UI界面部署
深入玩转K8S之外网如何访问业务应用(nginx-ingress篇)
前面的文章介绍了如何安装kubernetes集群,集群部署完毕之后就可以在上面部署服务了。服务部署完之后如何访问集群中的服务呢?  访问部署在kubernetes中的服务有两种情况,一种是在kubernetes集群内部访问,另一种是在集群外部访问服务。
DevinGeng
2019/04/09
2.2K0
k8s实践(12)--K8s service服务详解
Kubernetes Pod 是有生命周期的,它们可以被创建,也可以被销毁,然而一旦被销毁生命就永远结束。 通过 ReplicationController 能够动态地创建和销毁 Pod(例如,需要进行扩缩容,或者执行)。 每个 滚动升级 Pod 都会获取它自己的 IP 地址,即使这些 IP 地址不总是稳定可依赖的。 这会导致一个问题:在 Kubernetes 集群中,如果一组 Pod(称为 backend)为其它 Pod (称为 frontend)提供服务,那么那些 frontend 该如何发现,并连接到这组 Pod 中的哪些 backend 呢?
黄规速
2022/04/14
9.2K0
k8s实践(12)--K8s service服务详解
k8s-service
Kubernetes Service定义了这样一种抽象:一个Pod的逻辑分组,一种可以访问它们的策略-通常称为微服务。这一组Pod能够被Service访问到,通常是通过Label selector
eadela
2019/12/11
9000
k8s有哪些资源_k8s资源类型
• default:所有未指定的Namespace的对象都会被分配在default命名空间。 • kube-node-lease:集群节点之间的心跳维护,v1.13开始引入。 • kube-public:此命名空间的资源可以被所有人访问(包括未认证用户)。 • kube-system:所有由kubernetes系统创建的资源都处于这个命名空间。
全栈程序员站长
2022/09/22
5220
k8s有哪些资源_k8s资源类型
k8s 实践经验(七)ingress 详解
采用 NodePort 方式暴露服务面临问题是,服务一旦多起来,NodePort 在每个节点上开启的端口会及其庞大,而且难以维护;这时,我们可以能否使用一个Nginx直接对内进行转发呢?众所周知的是,Pod与Pod之间是可以互相通信的,而Pod是可以共享宿主机的网络名称空间的,也就是说当在共享网络名称空间时,Pod上所监听的就是Node上的端口。那么这又该如何实现呢?简单的实现就是使用 DaemonSet 在每个 Node 上监听 80,然后写好规则,因为 Nginx 外面绑定了宿主机 80 端口(就像 NodePort),本身又在集群内,那么向后直接转发到相应 Service IP 就行了,如下图所示:
看、未来
2022/05/09
2.3K0
k8s 实践经验(七)ingress 详解
k8s之Service
我们定义service如下,其中selector是用来筛选需要代理的pod,targetPort是目标pod的端口,port是指该service的端口。
编程黑洞
2023/03/06
2880
相关推荐
k8s资源对象的升级、回滚、扩容、缩容
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验