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.

OpenShift Commons Briefing: State of Open Source Security Report Review with Liran Tal (Snyk)

## OpenShift Commons Briefing Summary In this briefing, Snyk’s Liran Tal shows the results of his company’s State of Open Source Security 2019 Report. Liran explains each step of the process, from development, to testing, to deployment, and follows the chains of responsibility across those domains. Who is responsible for the security of container images? […]
The post OpenShift Commons Briefing: State of Open Source Security Report Review with Liran Tal (Snyk) appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

Announcing the general availability of Azure Lab Services

Today, we are very excited to announce the general availability of Azure Lab Services – your computer labs in the cloud.

With Azure Lab Services, you can easily set up and provide on-demand access to preconfigured virtual machines (VMs) to teach a class, train professionals, run hackathons or hands-on labs, and more. Simply input what you need in a lab and let the service roll it out to your audience. Your users go to a single place to access all their VMs across multiple labs, and connect from there to learn, explore, and innovate.

Since our preview announcement, we have had many customers use the service to conduct classes, training sessions, boot camps, hands on labs, and more! For classroom or professional training, you can provide students with a lab of virtual machines configured with exactly what you need for class and give each student a specified number of hours to use the VMs for homework or personal projects. You can run a hackathon or a hands-on lab at conferences or events and scale up to hundreds of virtual machines for your attendees. You can also create an invite-only private lab of virtual machines installed with your prerelease software to give preview customers access to early trials or set up interactive sales demos.

Top three reasons customers use Azure Lab Services

Automatic management of Azure infrastructure and scale

Azure Lab Services is a managed service, which means that provisioning and management of a lab’s underlying infrastructure is handled automatically by the service. You can just focus on preparing the right lab experience for your users. Let the service handle the rest and roll out your lab’s virtual machines to your audience. Scale your lab to hundreds of virtual machines with a single click.

Simple experience for your lab users

Users who are invited to your lab get immediate access to the resources you give them inside your labs. They just need to sign in to see the full list of virtual machines they have access to across multiple labs. They can click on a single button to connect to the virtual machines and start working. Users don’t need Azure subscriptions to use the service.

Cost optimization and tracking 

Keep your budget in check by controlling exactly how many hours your lab users can use the virtual machines. Set up schedules in the lab to allow users to use the virtual machines only during designated time slots or set up reoccurring auto-shutdown and start times. Keep track of individual users’ usage and set limits.

Get started now

Try Azure Lab Services today! Get started by creating a lab account for your organization or team. All labs are managed under a lab account. You can give permissions to people in your organization to create labs in your lab account.

To learn more, visit the Azure Lab Services documentation. Ask any questions you have on Stack Overflow. Last of all, don’t forget to subscribe to our Service Updates and view other Azure Lab Services posts on the Azure blog to get the latest news.

General availability pricing

Azure Lab Services GA pricing goes into effect on May 1, 2019. Until then, you will continue to be billed based on the preview pricing. Please see the Azure Lab Services pricing page for complete details.

What’s next

We continue to listen to our customers to prioritize and ship new features and updates. Several key features will be enabled in the coming months:

Ability to reuse and share custom virtual machine images across labs
Feature to enable connections between a lab and on-premise resources
Ability to create GPU virtual machines inside the labs

We always welcome any feedback and suggestions. You can make suggestions or vote on priorities on our UserVoice feedback forum.
Quelle: Azure