kubectl run nginx --image nginx --port 80<\/code><\/pre>\n\n\n\nAgora que temos um pod criado, como podemos ver a lista de pods dispon\u00edveis? O comando kubectl get pods<\/strong><\/em> nos ajuda a visualizar a lista de pods em nosso cluster.<\/p>\n\n\n\nNeste caso, vemos que o pod est\u00e1 em um estado de cria\u00e7\u00e3o de containers e em breve mudar\u00e1 para um estado de execu\u00e7\u00e3o quando estiver realmente em funcionamento.<\/p>\n\n\n\n
Al\u00e9m disso, lembre-se de que ainda n\u00e3o discutimos os conceitos de como um usu\u00e1rio pode acessar o servidor web NGINX. Portanto, no estado atual, o servidor web ainda n\u00e3o est\u00e1 acess\u00edvel para usu\u00e1rios externos. No entanto, voc\u00ea pode acess\u00e1-lo internamente a partir do n\u00f3. Por enquanto, vamos apenas aprender como implantar um pod e, em uma aula futura, quando aprendermos sobre redes e servi\u00e7os, saberemos como tornar este servi\u00e7o acess\u00edvel aos usu\u00e1rios finais.<\/p>\n\n\n\n
Cria\u00e7\u00e3o de um Pod<\/h2>\n\n\n\n
Podemos criar um pod usando um arquivo de configura\u00e7\u00e3o baseado em uma demonstra\u00e7\u00e3o da aula anterior e agora vamos aprender como desenvolver arquivos YAML especificamente para o Kubernetes.<\/p>\n\n\n\n
Kubernetes usa arquivos YAML como entradas para a cria\u00e7\u00e3o de objetos, como servi\u00e7os, Deployments e etc. Todos eles seguem uma estrutura semelhante.<\/p>\n\n\n\n
vim pod-definition.yaml<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n\n\n\nspec:<\/code><\/pre>\n\n\n\nO arquivo de defini\u00e7\u00e3o do Kubernetes sempre cont\u00e9m quatro campos de n\u00edvel superior: vers\u00e3o da API, tipo do objeto, metadados e especifica\u00e7\u00f5es. Essas s\u00e3o as propriedades de n\u00edvel superior ou raiz e tamb\u00e9m s\u00e3o campos obrigat\u00f3rios, portanto, devem ser inclu\u00eddos no arquivo de configura\u00e7\u00e3o.<\/p>\n\n\n\n
apiVersion<\/strong><\/p>\n\n\n\nO primeiro campo \u00e9 apiVersion<\/code>. Essa \u00e9 a vers\u00e3o da API que estamos usando para criar o objeto, dependendo do tipo de objeto que estamos tentando criar. No nosso caso, como estamos trabalhando com Pods, definiremos a vers\u00e3o da API como v1<\/code>. Outros valores poss\u00edveis para esse campo s\u00e3o apps\/v1<\/code>, beta1.extensions\/v1<\/code>, etc. Veremos para que servem essas diferentes vers\u00f5es mais adiante no curso.<\/p>\n\n\n\nkind<\/strong><\/p>\n\n\n\nO campo kind<\/code> se refere ao tipo de objeto que estamos tentando criar. Neste caso, estamos criando um Pod, portanto, definiremos esse valor como Pod<\/code>. Pode ser um conjunto de r\u00e9plicas (ReplicaSet<\/code>), uma implanta\u00e7\u00e3o (Deployment<\/code>) ou um servi\u00e7o (Service<\/code>).<\/p>\n\n\n\nmetadata<\/strong><\/p>\n\n\n\nOs metadados s\u00e3o dados sobre o objeto, como seu nome e labels. Diferentemente dos campos anteriores, onde especificamos valores de string, neste caso, os metadados s\u00e3o especificados na forma de um dicion\u00e1rio. Portanto, todos os campos dentro de metadata<\/code> devem ter um n\u00edvel de indenta\u00e7\u00e3o a mais em rela\u00e7\u00e3o ao campo pai. Essa indenta\u00e7\u00e3o \u00e9 de dois espa\u00e7os.<\/p>\n\n\n\nNo caso dos metadados, temos dois campos: name<\/code> (nome) e labels<\/code> (r\u00f3tulos). O nome \u00e9 um valor de sequ\u00eancia, no qual voc\u00ea pode nomear sua parte (pod). No campo labels<\/code>, temos um dicion\u00e1rio no qual voc\u00ea pode adicionar pares de chave e valor para identificar e agrupar objetos posteriormente. Por exemplo, se voc\u00ea tiver centenas de pods executando um aplicativo front-end e centenas de pods executando um aplicativo back-end ou um banco de dados, pode ser dif\u00edcil agrupar essas pods depois que elas forem implantadas. No entanto, se voc\u00ea as rotular agora como “back-end” ou “front-end”, poder\u00e1 filtrar as partes com base nesses r\u00f3tulos posteriormente.<\/p>\n\n\n\nspec<\/strong><\/p>\n\n\n\nO \u00faltimo campo no arquivo de configura\u00e7\u00e3o \u00e9 a se\u00e7\u00e3o de especifica\u00e7\u00e3o (spec<\/code>). Aqui, forneceremos informa\u00e7\u00f5es adicionais relacionadas a esse objeto, que ser\u00e3o diferentes para objetos diferentes. No nosso caso, como estamos criando apenas um Pod com um \u00fanico cont\u00eainer, podemos adicionar uma propriedade chamada containers<\/code>, que \u00e9 uma lista (ou array). Essa propriedade \u00e9 uma lista porque os Pods podem ter v\u00e1rios cont\u00eaineres dentro deles. No entanto, no nosso caso, adicionaremos apenas um \u00fanico item \u00e0 lista, pois planejamos ter apenas um cont\u00eainer no Pod.<\/p>\n\n\n\nDentro do campo containers<\/code>, temos um dicion\u00e1rio para especificar as propriedades name<\/code> (nome) e image<\/code> (imagem) do cont\u00eainer. O valor da imagem ser\u00e1 o nome da imagem do Docker no reposit\u00f3rio do Docker. Ap\u00f3s criar o arquivo de configura\u00e7\u00e3o YAML, voc\u00ea pode usar o comando kubectl create -f <nome_do_arquivo><\/code> para criar o Pod.<\/p>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: mypod-app\n labels:\n app: mypod\nspec:\n containers:\n - name: nginx \n image: nginx <\/code><\/pre>\n\n\n\nAplicando o manifesto yaml para criar o POD<\/p>\n\n\n\n
kubectl create -f pod-definition.yaml<\/code><\/pre>\n\n\n\nVerificando os Pods<\/h3>\n\n\n\n
Ap\u00f3s criar o Pod, voc\u00ea pode usar o comando kubectl get pods<\/code> para ver uma lista dos Pods dispon\u00edveis. Para obter informa\u00e7\u00f5es detalhadas sobre um Pod espec\u00edfico, execute o comando kubectl describe pod <nome_do_pod><\/code>.<\/p>\n\n\n\nkubectl get pods<\/code><\/pre>\n\n\n\nIsso fornecer\u00e1 informa\u00e7\u00f5es sobre o Pod, como sua cria\u00e7\u00e3o, os r\u00f3tulos atribu\u00eddos a ele, os cont\u00eaineres que fazem parte dele e os eventos associados a esse Pod.<\/p>\n\n\n\n
![\"Sunset\"\/](\"images\/pod_yaml_8.png\")
<\/figure>\n\n\n\n