Introduction to YAML: Deployments and other Kubernetes Objects Q&A

The post Introduction to YAML: Deployments and other Kubernetes Objects Q&A appeared first on Mirantis | Pure Play Open Cloud.
Recently we gave a webinar that gave an Introduction to YAML: Deployments and other Kubernetes Objects. Here’s a look at some of the Q&As we covered (and some that we didn’t have time for).
Q: What tool compiles a YAML file?
A: YAML files are meant to be human-readable text, but they can be compiled into objects if necessary. For example, SaltStack compiles YAML into objects. In the case of Kubernetes, if YAML needs to be compiled it would likely be the Go code behind the component that’s utilizing it.
Q: In context to the YAML structure, can we write labels as labels: [app: nginx type: webserver]?
A: It would be labels: [app: nginx, type: webserver], but yes, you can mix YAML and JSON styles.
Q: Why do you have to provide an image name? If the container is up, can we just specify the name?
A: Kubernetes is based on Infrastructure as code, so you’re describing what you want to happen and letting Kubernetes figure out how to get there; if you were to reference the container itself, it would break that paradigm.
Q: What are all possible Kinds possible, such as DaemonSet, or CronJob?
A: Rather than me just listing them, it’s probably best that you check out the Kubernetes reference documentation.
Q: Can we use just JSON notation for creating kubernetes objects, and not YAML?
A: You can; any JSON object is a valid YAML object.
Q: Does “targetPort:” mean destination port ?
OK, so I get this mixed up all the time. The port is the port of the request, and the targetPort is the port on the destination container.
Q: What does Ingress mean in this context?
Ingress routes requests from outside the cluster to cluster services. You can then create rules that route traffic and create load balancing, name-based virtual hosting, and so on.
Q: Can we debug YAML to verify correct values before pushing to kubernetes?
Yes. In addition to using a YAML linter (such as http://www.yamllint.com/) to check the formatting and indenting and such, you can use the –dry-run parameter to “run” the command and see what happens without actually persisting the changes.
Q: Can you please talk more about nested -s(dashes)
I’m guessing that you’re asking about lists of lists. The answer is that you can have as many levels as you need, and you can have lists of lists, maps of lists, maps of maps, and maps of lists. The important thing is to make sure that you have the indentation straight, since YAML uses solely that to determine the structure.
Q: In the volume section you mentioned awsstorage but not PersistentVolumeClaim. Can it work like this?
A: A volume has a certain type, which in this example was awsstorage. Once you’ve created a PersistentVolume, you can make a separate PersistentVolumeClaim to get access to that volume.
Q: Possibly, not for this session, but will be good if you give a brief overview of what Ingress and Egress are?
A: Strictly speaking, “Ingress” refers to requests coming into the cluster, and “Egress” refers to traffic flowing out of the cluster (as in “This way to the Egress”(http://www.ptbarnum.org/egress.html)).
Q: Did you mean that you can have two network interfaces on the same container?
A: You can indeed have multiple network interfaces on the same container, but you may need to use a CNI. For example, virtlet uses CNI-Genie to have not just multiple interfaces, but potentially multiple interfaces of different plugin types.
Q: Is there any object for multicluster kubernetes management?
A: Kubernetees objects are generally meant to be used within a single cluster, so in general multicluster management is handled outside of the cluster or through the application. A possible exception would be the Federation-related objects, which enable identities to be shared throughout the federated clusters.
Q: What will actually happen when you try to overwrite the value in this example:
backend: &stdbe
  serviceName: test
  servicePort: 80
– path: /realpath
  backend: *stdbe
    servicePort: 443
A: Written like this you’ll get an error, but you can actually find the corrected code — which DOES work — here.
Q: What happens when I have a PersistentVolume of one size (let’s say 10G) and I have PersistentVolumeClaim of a different size (let’s say 2G)?
A: You’ll get a claim of 10G, because there’s a 1:1 relationship between a PersistentVolume and a PersistentVolumeClaim, meaning that you can’t have separate areas of the volume staked out by different claims. That said, multiple pods can reference the same PVC in order to use the same (full) volume.
Q: What is really the concept behind using running a container inside a Pod, and what is the key point behind Pod images?
A: A Pod is the smallest unit that can be managed by Kubernetes, basically providing a layer of abstraction above the container. A Pod can have a single container, which yes, makes it seem redundant, but it can also contain multiple containers, all of which are managed as a single chunk, which is where it begins to make more sense. As such, there’s no such thing as a “Pod image”; it’s a container image instantiated by the Pod.5
Q: Do you have any other information for Kubernetes that would be useful to Solution Architects, more of an inch deep but mile wide approach?
A: Stay tuned.