1. Formatos de arquivo suportados pelo K8S
Kubernetes oferece suporte aos formatos de arquivo YAML e JSON para gerenciar objetos de recursos.
Formato JSON: usado principalmente para transmissão de mensagens entre interfaces API
Formato YAML: usado para configuração e gerenciamento. YAML é uma linguagem concisa e sem marcação com formato de conteúdo amigável e relativamente
fácil de ler
1. A principal diferença entre yaml e json
- YAML usa espaços para indentação, que é um território familiar para desenvolvedores Python.
- Os desenvolvedores de JavaScript adoram JSON porque é um subconjunto de JavaScript que pode ser usado diretamente em
- Interpretado e escrito em JavaScript, ao declarar JSON usando uma forma abreviada, não são necessárias aspas duplas nas chaves ao usar nomes de variáveis típicos sem espaços.
- Existem muitos analisadores que funcionam bem em todas as linguagens para YAML e JSON.
- Em muitos casos, o formato de espaço em branco do YAML pode ser mais fácil de visualizar porque a formatação requer uma abordagem mais humana.
Se o seu editor não tiver espaços em branco visíveis ou indicadores de linha de recuo, os espaços em branco do YAML, embora mais compactos e fáceis de ver, podem ser difíceis de editar manualmente. - A serialização e desserialização de JSON são muito mais rápidas porque há significativamente menos recursos para verificar do que YAML, o que permite que códigos menores e mais leves manipulem JSON.
- Um equívoco comum é que o YAML requer menos pontuação e é mais compacto que o JSON, mas isso está completamente errado. O espaço em branco é invisível, então parece que há menos caracteres, mas se você contar o espaço em branco real necessário para que o YAML seja interpretado corretamente com o recuo correto, você descobrirá que o YAML na verdade requer mais caracteres do que JSON . JSON não usa espaços em branco para representar hierarquia ou agrupamento e pode ser facilmente nivelado removendo espaços em branco desnecessários para uma transmissão mais compacta.
2. Formato de linguagem YAML
- Maiúsculas e minúsculas
- Use recuo para indicar relacionamentos hierárquicos
- O recuo da tecla Tab não é suportado, apenas espaços são usados para recuo
- O número de espaços recuados não é importante, desde que os elementos do mesmo nível estejam alinhados à esquerda, normalmente dois espaços são recuados no início.
- Recue um espaço após um caractere de símbolo, como dois pontos, vírgula, traço (-), etc.
- — Representa o formato YAML, o início de um arquivo, usado para separar arquivos
- # representa comentários
2. YAML
1. Visualize o rótulo da versão do recurso API
kubectl api-versions
2. Preparar lista de alocação de recursos
2.1 编写 nginx-test.yaml 资源配置清单
vim nginx-test.yaml
#指定api版本标签
apiVersion: apps/v1
#定义资源的类型/角色，deployment为副本控制器
#此处资源类型可以是Deployment、Job、Ingress、Service等
kind: Deployment
#定义资源的元数据信息，比如资源的名称、namespace、标签等信息
metadata:
#定义资源的名称，在同一个namespace空间中必须是唯一的
name: nginx-deployment
labels:
app: nginx
#定义deployment资源需要的参数属性，诸如是否在容器失败时重新启动容器的属性
spec:
#定义副本数量
replicas: 3
#定义标签选择器
selector:
#定义匹配标签
matchLabels:
#需与后面的.spec.template.metadata.labels定义的标签保持一致
app: nginx
#定义业务模板，如果有多个副本，所有副本的属性会按照模板的相关配置进行匹配
template:
metadata:
#定义Pod副本将使用的标签，需与前面的.spec.selector.matchLabels定义的标签保持一致
labels:
app: nginx
spec:
#定义容器属性
containers:
#定义一个容器名，一个-name:定义一个容器
- name: nginx
#定义容器使用的镜像以及版本
image: nginx:1.15.4
ports:
#定义容器对外的端口
- containerPort: 80
#------------------------------------------------------------------#
#无注释
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
2.2 创建资源对象
kubectl create -f nginx-test.yaml --validate=false
2.3 查看创建的pod资源
kubectl get pods -o wide
3、创建service服务对外提供访问并测试
3.1 编写nginx-svc-test.yaml文件
[root@master ~]# vim nginx-svc-test.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
labels:
app: nginx
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
#此处定义的selector要与deployment所定义的selector相同
#service依靠标签选择器来检索提供服务的nodes
app: nginx
3.2 创建资源对象
kubectl create -f nginx-svc-test.yaml
kubectl get svc
3.3 访问测试
访问nginx-test的ip
curl 10.96.28.172:80
curl 192.168.160.40:32139
三、详解K8S中的Port
port
- port 是 k8s 集群内部访问 service 的端口，即通过 clusterIP:port 可以从 Pod 所在的Node上访问到service nodePort
nodePort
- 是外部访问 k8s 集群中 service 的端口，通过 nodeIP:nodePort 可以从外部访问到service
targetPort
- targetPort 是 Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器
containerPort
- containerPort 是 Pod 内部容器的端口，targetPort 映射到 containerPort
四、试运行生成 yaml 模板后创建实例
1、–dry-run：试运行
–dry-run：表示试运行，不真正执行命令(测试命令是否正确)，即并不会真的创建出 pod 和 deployment 实例，去掉该参数后即可真正执行命令。
kubectl create deployment dryrun-test --image=nginx --port=80 --replicas=3 --dry-run
#打印相应的 API 对象而不执行创建
2、查看生成yaml格式
使用 --dry-run 试运行可不触发生成命令，然后通过 -o yaml 可实现对其 yaml 资源配置清单的查看
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml
3、查看生成json格式
可通过 -o json 查看该命令产生的 json 配置清单
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o json
4、使用 yaml 格式导出生成模板
kubectl create deployment dryrun-test --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml > dryrun-test.yaml
5、使用 yaml 模板创建实例
kubectl apply -f dryrun-test.yaml
kubectl get pod,deploy
6、将现有资源生成 yaml 模板导出并保存为文件
kubectl get deploy/dryrun-test -o yaml
kubectl get deploy/dryrun-test -o yaml > export-test.yaml
7、查看字段帮助信息
explain 可一层层的查看相关资源对象的帮助信息
kubectl explain deployments.spec.template.spec.containers
五、总结
没有相关资源，使用 run 命令 --dry-run 选项
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > dryrun-test.yaml已有相关资源，使用 get 命令 --export 选项
kubectl get deploy dryrun-test --export -o yaml > export-test.yaml写yaml太累怎么办？
用 --dry-run 命令生成
kubectl run my-deploy --image=nginx --dry-run=client -o yaml > my-deploy.yaml用get命令导出
kubectl get svc nginx-service -o yaml > my-svc.yaml
或
kubectl edit svc nginx-service #复制配置，再粘贴到新文件yaml文件的学习方法：
(1)多看别人(官方)写的，能读懂
(2)能照着现场的文件改着用
(3)遇到不懂的，善用kubectl explain ... 命令查