This year, the UNICEF Venture Fund celebrates five graduating companies from a recent investment round. For the first time, many of these companies are exiting from the Venture Fund having already earned recognition as Digital Public Goods (DPGs). With the support of a cross-sectional team of mentors, these graduating companies worked to achieve compliance with the DPG Standard.

The Digital Public Good Standard offers a nine-point baseline for evaluation and recognition of Open Source software, content, data, and standards that adhere to privacy and other applicable laws and best practices, do no harm by design, and help attain the Sustainable Development Goals (SDGs). Once a solution is recognised as a digital public good it is discoverable on the DPG Registry.

This recognition acknowledges their use of vetted Open Source licenses, useful documentation, and adherence to relevant best practices and local data protection laws. What makes this achievement a first for the Venture Fund is that these recognitions were achieved by the companies during the investment round. Typically, companies that go on from the Venture Fund achieve recognition after a year or more of graduation. This new shift is made possible by the growing investment in Technical Assistance at the Venture Fund and the leadership of a robust team of mentors.

This article introduces the Technical Assistance mentoring programmes offered by the UNICEF Venture Fund, the addition of new mentors in the last year, the shift of mentor focus around the DPG Standard, and the results achieved to date from the latest graduating Venture Fund cohort.

Origins of Technical Assistance at the Venture Fund 🔗

The Venture Fund offers different areas of Technical Assistance to start-up companies who apply and are selected to receive early-stage seed investment by UNICEF. Originally starting in 2018, the Technical Assistance programmes only included Business Development and Open Source. Over the years, we have piloted and pivoted mentorship models with input from our portfolio of startups. Today, the Technical Assistance programmes cover a range of topics across an experienced team of mentors, depending on the relevance to the start-up companies:

• Blockchain with Arun Maharajan and Alex Sherbuck (former)
• Business Development with Jamil Wyne and Philippa Martinelli (former)
• Evidence of Impact with Milena Bacalja Perianes and Jennifer Sawyer
• Data Privacy & Security with Lydia Kwong
• Data Science & A.I. with Daniel Alvarez
• Open Source with Justin Wheeler, Abigail Cabunoc Mayes (former), and Vipul Siddharth
• Software Development with Iván Perdomo

The mentors work closely with the experienced team of portfolio managers (Meghan Warner, Kennedy Kitheka, and Madison Marks) to guide and coach Venture Fund companies to achieve their targets and success indicators during the investment round.

Starting in 2021, the Venture Fund broadened the Technical Assistance programmes to include Software Development, Data Science & A.I., Data Privacy & Security, and Evidence of Impact. This was a marked change in growing the support and expertise made available to start-up companies during their investment round. However, as the team of mentors and Technical Assistance offerings expanded, there was a growing need to bring a common rallying point across all programmes. How could the mentors ensure their Technical Assistance programmes complemented one another without duplicating topics or repeating conversations?

Further complementing the core Technical Assistance programme, specialized workshops were held by like-minded institutions outside the Venture Fund’s core team of mentors , along with personalized mentorship sessions. The recent Blockchain Cohort, for example, benefitted from targeted mentorship from AW3L, a blockchain consulting firm that share many of UNICEF’s values around leveraging blockchain for social impact.

“Blockchain has immense potential, but it remains just a tool and its impact is dependent on what we do with it. That’s why it is crucial to have local entrepreneurs on the ground building use-cases that solve real problems unique to their geography. We are therefore extremely happy and proud to support UNICEF and its portfolio companies to tackle real-world problems in emerging markets by utilizing blockchain technology.”

Martijn van de Weerdt, Founder, AW3L

How the DPG Standard unified the mentoring streams 🔗

The DPG Standard became a common rallying point for the UNICEF Technical Assistance programmes. As our mentoring programmes increased and topic areas broadened, we needed coordination and a synchronized stream of Technical Assistance programmes. In the last year, the Venture Fund reviewed its workplan development and strategy to enable more solutions to achieve recognition as a digital public good at or near the graduation point for a Venture Fund portfolio. The most recent graduating cohort, the 2021 Blockchain cohort, represents this improved alignment, with 4 of 5 companies receiving recognition of their products as digital public goods by their graduation this year.

How does recognition of an open solution as a Digital Public Good help Venture Fund startups? It is an acknowledgment by the Digital Public Goods Alliance of a commitment and adherence to best practices and steps taken to protect data privacy and do no harm. Additionally, recognition as a DPG unlocks stronger potential for adoption and deployment of the solution by global stakeholders by providing greater visibility in a public roster of open solutions that adhere to best practices and standards. The recognition of 80% of an off-boarding Venture Fund portfolio speaks to both the intrinsic capabilities of the companies and the value of the Technical Assistance programmes and mentorship provided to them by the Venture Fund.

While past Venture Fund companies have received recognition as digital public goods before, this is the first time that a company achieved the recognition at the time of their graduation from the Venture Fund. Aligning the Technical Assistance programmes around the DPG Standard provided common frameworks and mental models for the diverse team of mentors to support the companies and help them achieve the Standard as an important part of their product development lifecycle.

“As an early-stage startup, we struggled with a clear business model. Especially in the last six months of the investment, support from the mentor network helped in building clear business growth and impact metric plans. Also a year ago, we were very heavy on the tech side but lacked considerable planning on network and visibility growth. We have developed a customer persona and a pricing model, and now have a clearer vision of our Total Available Market, Serviceable Available Market, and Serviceable Obtainable Market (TAM, SAM, and SOM) models.”

Rumee Singh, Co-Founder, Rumsan

Further, farther, together 🔗

What comes next? The Technical Assistance programmes at the UNICEF Venture Fund are gearing up for additional cohorts benefiting from our seed-stage investment: a Data Science & A.I. cohort and an upcoming Blockchain cohort. These early-stage companies undergo a technical assistance programme involving a technical and strategic workshop series and monthly mentorship meetings. Graduates of our seed-stage investment that  have received additional capital through our Growth Funding to take their solution to the next level of impact also benefit from customized mentorship to support their evolution from good prototype developments to solutions that can be implemented and scaled, with sustainable business models and proven pilots.

Additionally, mentors are developing digital toolkits to enable Venture Fund companies and anyone to read up and study best practices for building and sustaining digital public goods. Most of these toolkits will be released digitally online under Open Source licenses. You can find three of these toolkits below:

• Data Science & A.I.
• Drones
• Open Source

Since the first Technical Assistance programmes were launched in 2018, the Venture Fund has seen improved results that correlate with the Technical Assistance programmes. In the most recent Blockchain 2021 cohort, across 500+ hours of mentoring, the cohort collectively reached over 700,000 beneficiaries, raised $4M in follow-on funding, and 4 of 5 graduating companies were recognized as a digital public good before graduation. This also marked a new record of external contributors, with a total of 39 people who contributed to repositories across all portfolio companies. The expert guidance and coaching provided by the team of UNICEF mentors aids the start-ups in achieving new record heights.

“UNICEF’s support helped Xcapit build value, with a premium put on discovery, iteration, survey, and experimentation with the end user. The guidance at the right time is priceless. It prevented us from facing a major problem in the future when our blockchain UNICEF mentor guided us when we were deciding the technology to create our wallet. Changing our mindset to become a fully open source company was also challenging. We had the best guidance we could ask, and we successfully overcame the difficulties and doubts, understanding the benefits of open collaboration.”

Antonella Perrone, COO, Xcapit

Contribute to Technical Assistance knowledge and mentoring 🔗

The UNICEF mentor toolkits are open source and you can also participate. The toolkits are currently accepting contributions for UI/UX and front-end development, as well as content curation and authorship. Get involved with the toolkits by participating via GitHub:

• UNICEF Inventory theme (see “good first issues”)
• UNICEF Open Source Inventory
• UNICEF Data Science & A.I. toolkit

With the Digital Public Goods Alliance, we built upon our learnings and successes from portfolio companies and created the DPG Accelerator Guide as a collection of resources for accelerators to also support local ventures in developing digital public goods, setting them up for scale and impact.

The shared context is the most valuable piece of the conference. As a first-time attendee, I was blown away by the depth and range of topics covered by attendees. This blog post covers a narrow perspective of Sustain OSS through the sessions I participated and co-facilitated in.

Speed breakout groups 🔗

The morning started with speed breakout groups of between six to twelve people. Several attendees acted as facilitators for discussion on special topics. Every attendee could about half of all groups. I took extensive notes in the following groups:

• Charitable participation in open source
• Diversity and inclusion
• Turning open source projects into sustainable projects / companies
• Design in open source
• Open source financial sustainability models

Sustain OSS: High-level takeaways 🔗

To save you time, these are my high-level takeaways across all breakout groups I participated in:

• Open source isn’t something just done in people’s free time

• Complex systems can enable systemic bias in terms of what “open source” means

• Sustainability as topic of first priority / consideration, not an afterthought

• There is no “silver bullet” solution to any of these challenges; they all require adaption to work across communities, projects, and organizations

Charitable participation in open source 🔗

This breakout group focused on the connection between charitable organizations and free software projects. It was facilitated by the esteemed Karen Sandler of the Software Freedom Conservancy.

Overall, the conversation was split among creating ethical software, finding sustainable funding models, and balancing how much control to relinquish as a managing organization of an open source project. Some felt pride and ideology were strong drivers for contributors to ideological projects (which also mirrors my experience at UNICEF). These could be key motivations to understand for contributors. Additionally, the challenge around sustainable funding models was common across charitable foundations focused on free software. Grant funding is a common strategy employed by charitable organizations, but the short-term nature of grants puts additional strain on resources to continue searching for new funding. Lastly, for charitable organizations overseeing or supporting free software projects, there was uncertainty over how much control should be left to projects. Attendees generally expressed a desire to let projects do what they want, but it sometimes came at the risk of additional overhead for the organization when everyone does something of everything. The concern over toxic communities came up, and how some issues remain buried until farther along in a relationship with a project. One successful solution employed was to hold monthly meetings among all member projects of an organization to address difficulties.

One interesting detail that captured my attention: one attendee noted how extensive effort into fundraising campaigns targeted to members of a foundation actually increased member engagement with the foundation.

Diversity and inclusion 🔗

My biggest takeaway from this session was the danger in thinking of open source as something we do in our free time. This can be exclusive to different genders, races, and socioeconomic statuses. Some “free time” is more equal than others. The actionable piece for me is to be more conscious in building and growing communities to support different levels of contribution in a community.

The question I wanted to explore after reflecting is to ask of those who feel disadvantaged:

• What factors makes a project more or less inviting for you?
• What can we do better when designing for participation in our communities?

Turning open source projects into sustainable ones 🔗

My notes weren’t thorough on this session, but there was an interesting point on trademark that came up during discussion of the Commons Clause. One participant was pursuing trademark law to enforce commercial protections and sustainability. They gave an example of a large corporation advertising support with a major open source project (e.g. a major software/hardware vendor supporting a specific NodeJS version). They wanted to use this as a way to create a more financially sustainable model for some projects.

Design in open source 🔗

This breakout group focused on sustainable design and design practices in open source communities. The role of designers in technical projects was also discussed and how we can build technical communities to be more inclusive for designers. It was facilitated by Elio Qoshi.

My takeaways from this breakout were that established ways of working can be unfriendly to designers and there is a need to emphasize diversity across different roles in a project or organization. Certain tools, platforms, or other mechanisms for contributing have poor user interfaces. They can push people away because of barriers to contributing with a frustrating user experience. Next, the need for diversity in roles was noted, with an example of engineers leading project management. Sometimes bias or oversights afforded as an engineer accidentally excludes others like designers or writers from contributing to our project. We should endeavor for people to spend more time on their preferred and most effective methods of contribution.

Financial sustainability models 🔗

This breakout session focused on the traditional sense of sustainability: in finances and resources. Attendees discussed different models used to fund open source projects and foundations. The session was facilitated by the founder of the MusicBrainz project, Robert Kaye.

The model used by MetaBrainz essentially as a data broker was interesting and unique. MetaBrainz offers commercial data usage at a cost, and companies using their data have a strong need for the data and see value in it. Through other parts of their model since changing three years ago, they had significant gains in their revenue and were able to increase paid staff working on the projects.

The Amazon invoice cake is also an amusing story, but you should ask Robert directly about it.

Hour breakout sessions 🔗

After lunch, attendees participated in two hour-long breakout sessions to explore specific topics in greater detail.

Human aspect of governance 🔗

Longer form notes are available below. I won’t go into detail since it has its own document with notes and highlights.

Human aspects of open source governance - Sustain OSS London 2018Download

University engagement 🔗

Together with Josh Greenberg of the Alfred P. Sloan Foundation, we co-facilitated a spontaneous session on how universities can engage with open source communities and vice versa.

In our session, two major topics were discussed:

• Education (e.g. curriculum, institutions, programs, etc.)

• Research

We asked all participants why they decided to participate and what questions they had, even though we weren’t able to answer all of them:

1. How do we get the word out?
2. What research is most valuable for open source?
3. How to long-term sustain projects?
4. How to actually do and support research?
5. How to engage both students and faculty?
6. How to harness / enable institutions to make positive contributions to ecosystem?

For education, we agreed that introducing and teaching open source in curriculum better serves students and the institution (both financially and in career satisfaction). Many technology companies today are participating in open source and it is an important skill to have for students entering the workforce. For research, students are already doing research and proposing topics, so better student engagement in open source is better for research.

Our takeaways were to better engage with existing organizations working on these problems for years already (e.g. POSSE), shifting the perspective of universities to be stewards of FOSS, and using collegiate hackathons as a way to better engage with undergraduate students.

One additional point that stood out to me was the emphasis across all breakout participants for a need of good communication skills to be successful. In many cases, the companies hiring top tech talent (from our breakout attendees) listed this as most desirable skill. Technology and new skills can be learned, but teaching good communication skills and how to work collaboratively are not easily learned.

Other takeaways 🔗

One takeaway I couldn’t fit elsewhere was my changed perspective on “technical” vs. “non-technical” work. The phrase “non-technical work” implies an “other space where development does not occur”. Does the phrase place unequal priority on technical work? One action item is to avoid using “non-technical work” as an umbrella term, and instead call these areas by what they are: design, documentation, writing, marketing, community building, etc.

For me, I still want an umbrella term for these things, but I’m open-minded for better alternatives to non-technical.

Skill share: conflict resolution 🔗

The last event of Sustain OSS was a 1x1 skill share. Roughly half of the attendees identified a “skill” they could teach someone else in the room. The other half of attendees paired with someone teaching a skill they wanted to learn more about. I paired with Jono Bacon on a short breakout on conflict resolution.

Jono detailed steps of working through and resolving conflict, including how to identify root problems, how to make steps to resolve them, and some personal philosophy of how we build and maintain relationships with others.

An important first step is to identify the critical point: this could be an ongoing crisis, dealing with interpersonal conflict, or dealing with burnout. When someone is explaining a problem, listen fully to them and understand what they are saying. Let them get it off their chest. Is there something else causing this behavior? Tap into the cloud of ranting and determine what the root cause is.

Once common ground is established, make a plan to resolve it. Jono’s advice was to create written next steps and be explicit about expectations. This way, everyone is on the same page of what the next steps are and everyone involved has signed off on these next steps (this creates a sense of commitment and the next steps become written as “law”). Encourage others to restate the goals of conflict resolution in their own words. Once you have written goals and expectations, the crucial next step is follow-up. Check in on a regular basis with the person or people involved. Try to be neutral and unbiased when listening to others in these conversations. Go in with an open mind.

Lastly, we contextualized conflict resolution in personal philosophy of how we build and maintain relationships with others – both in and out of our open source projects. Sometimes the best way to address difficult interpersonal problems is to stop avoiding them and simply address them. Much easier said than done, but otherwise there is no escaping the perpetuated cycle of conflict if someone doesn’t make a first step.

It’s not just about code.

Thank you 🔗

To wrap up this Sustain OSS report, a few obligatory thank-yous are needed:

• Sloan Foundation / Ford Foundation: For the financial support I needed to attend and participate in the event – this is never something I take for granted and I am happy to have received a scholarship to attend and participate

• Josh Greenberg @ Sloan Foundation: For helping me get over some imposter syndrome and co-facilitate the university engagement breakout session with me – thanks for the gentle push

• Robert Kaye @ MetaBrainz: For being generally awesome and finally giving me someone to nerd out about all these crazy ideas of how free culture and music can actually be related!

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me map a strategy to get the most out of Sustain OSS

Sustain OSS gave me a lot to think about and consider. I’m glad and fortunate to have attended. I hope this event report gives additional visibility to some of the conversations held in London this year.

This article covers Horizontal Pod Autoscaling, what it is, and how to try it out with the Kubernetes guestbook example. By the end of this article, you will…

• Understand what Horizontal Pod Autoscaling (HPA) is
• Be able to create an HPA in Kubernetes
• Create an HPA for the Guestbook and watch it work with Siege

What is Horizontal Pod Autoscaling? 🔗

Horizontal Pod Autoscaling (HPA) is a Kubernetes API resource to dynamically grow an environment. To help simplify things, consider it in three pieces:

• Horizontal: Think of horizontal growth, i.e. adding more nodes to your available pool (unlike vertical, which would be adding more memory / CPU to your existing nodes)
• Pod: Your deployable units in Kubernetes
• Autoscaling: Automatically scaling out when needed

To help visualize it, imagine you have a Python Flask web server that reads and writes data to a Redis back-end. Your web server is the front-end for all of your incoming traffic. You run it with three pods in Kubernetes, with 512MB of RAM and 50m of CPU. Now, suddenly, BuzzFeed writes an article about your app, Kanye West name drops the app in a TV interview, and the president of the United States retweets a link to your site.

Oops.

Now you have a serious problem on your hands, where your tiny application is overloaded. Three pods aren’t cutting it anymore. You get woken up at 3:00am to hastily adjust the number of replicas and rapidly scale your infrastructure. While you’re wondering how this happened, you also wonder… isn’t there an easier way? Could I have avoided this panicked, pre-dawn scaling crisis? Yes, there is! At least, somewhat.

Building to scale 🔗

By creating and managing your deployments with HPAs, your application grows horizontally to handle the load. As the CPU utilization rises, HPAs trigger the addition of more pods to scale automatically. Previously, you could create a Horizontal Pod Autoscaler that would begin scaling when cumulative CPU utilization was at 60%. You could also tell it to scale to a maximum of 500 pods, but no less than three. So then, when the Apocalypse of Viral Sharing happened to your web application, it could have grown dynamically.

If you want to dive deeper in the technical implementation of HPAs, you can read more in the Kubernetes documentation.

Create a Horizontal Pod Autoscaler 🔗

Now that you understand how a Horizontal Pod Autoscaler (HPA) is helpful, how do you create one? Like any other resource in Kubernetes, define HPAs in a YAML definition file. Here’s a template for getting started.

---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: my-app-space
  labels:
    app: my-app
    tier: frontend
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 2
  maxReplicas: 20
  targetCPUUtilizationPercentage: 60

This is the minimal spec you need to deploy an HPA. It’s not that different from other Kubernetes resources you may have seen.

Explaining the configuration 🔗

Let’s look at what some of the specific lines are.

• spec.scaleTargetRef.name: Name of resource to scale (e.g. name of a deployment)
• spec.minReplicas: Minimum number of replicas running when CPU use is minimal
• spec.maxReplicas: Maximum number of replicas running when CPU use peaks
• spec.targetCPUUtilizationPercentage: Percentage threshold when HPA begins scaling out pods

When starting out for the first time, tweak these values based on the amount of traffic you expect to receive or what your budget is. Load testing your application is one way to see the HPAs do their job.

Obliterating the Guestbook 🔗

But this guide wouldn’t be complete without a live demo to try. You can create one with an existing application and put it to the test. This section assumes you have a running Guestbook application in your Kubernetes environment. As a quick refresh, the Guestbook is a three-part application:

• PHP web application for writing messages into a virtual guestbook
• Primary Redis node for writing new messages from web page
• Replica Redis nodes for reading the data into web page

We’ll add an HPA as a fourth part to scale the PHP web application for new traffic.

Create the HPA for Guestbook 🔗

Now, create a new HPA spec file for the guestbook.

---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: guestbook-frontend
  namespace: guestbook
  labels:
    app: guestbook
    env: production
    tier: frontend
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: guestbook-frontend
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 75

Put this into a file and create the HPA with kubectl.

$ kubectl apply --record -f guestbook-frontend-hpa.yaml

Now, the Horizontal Pod Autoscaler is operational and monitoring the CPU utilization of your deployment.

Load test with Siege 🔗

To force the HPA into action, we’ll use Siege, an HTTP load testing and benchmark utility. Siege is a multi-threaded load testing tool and has a few other capabilities included to make it a good option for putting some force onto a simple web app.

First, put various permutations of the URL in a plaintext file. By doing this, Siege can randomly scan the URLs in he text file and ping them in “Internet mode” by randomly selecting a URL from the list for each request. This could look like the following…

http://my-guestbook.example.com/
http://my-guestbook.example.com/index.html
http://my-guestbook.example.com/guestbook.php
http://my-guestbook.example.com/guestbook.php?cmd=get&key=messages

Once this is done, you can fire up Siege to begin load testing. In this case, to get fast results, we’ll use 255 concurrent users for five minutes, using Internet and benchmark modes.

$ siege --verbose --benchmark --internet --concurrent 255 --time 10M --file siege-urls.txt

You should see Siege begin to rapidly send requests to your Guestbook application. Now that the action is in progress, you can slowly observe your CPU utilization begin to climb. Watch it slowly change by using watch.

$ watch -d -n 2 -b -c kubectl get hpa -l app=guestbook

During the five minute load test, you should notice CPU usage rise and then new replicas will appear. Depending on what your original requests and limits are for the deployment, you will see different results. Next, try setting the deployment’s requests / limits to lower values if nothing seems to happen while testing.

Learn more about Horizontal Pod Autoscaler 🔗

Horizontal Pod Autoscalers are a stable resource in Kubernetes and are available for you to begin playing around with now. To learn more, read the documentation or see another example in the official walkthrough.

Welcome back to the Kubernetes and Fedora series. Each week, we build on the previous articles in the series to help introduce you to using Kubernetes. This article picks up from where we left off last when you installed Tectonic to Amazon Web Services (AWS). By the end of this article, you will…

• Start up Redis master and slave pods
• Start a front-end pod that interacts with the Redis pods
• Deploy a simple web app for all of your friends to leave you messages

Compared to previous articles, this article will be a little more hands-on. Also like before, this is based off an excellent tutorial in the upstream Kubernetes documentation. Let’s get started!

Pre-requisites 🔗

This tutorial assumes you followed the Minikube how-to earlier in this series and that you already have a Tectonic installation running (doesn’t have to be on AWS). In case you’re jumping in now, make sure you have the Kubernetes client tools installed on your Fedora system, like kubectl. If not, you can install them now.

$ sudo dnf install kubernetes-client

Configure kubectl for Tectonic 🔗

To use kubectl with your Tectonic installation, you need to have a valid configuration in ~/.kube/config for your cluster. This is how kubectl knows where and how to talk to Tectonic. To get these values, first log into the Tectonic Console you installed.

1. Click username (usually admin) > My Account on the bottom left.
2. Click Download Configuration.
3. When the Set Up kubectl window opens, click Verify Identity.
4. Enter your username and password, and click Login.
5. From the Login Successful screen, copy the provided code.
6. Switch back to Tectonic and enter the code in the field.

Now you will be able to download kubectl-config from Tectonic. There’s two ways to proceed from here.

Add a new configuration 🔗

If this is your first time using kubectl, your configuration is likely empty. If it’s empty or you don’t care about overwriting an old configuration, you can run the following commands to add the configuration.

$ mkdir ~/.kube/
$ mv ~/Downloads/minikube-config ~/.kube/config
$ chmod 600 ~/.kube/config

Append to an existing configuration 🔗

If you already have a configuration, like from Minikube, you might not want to wipe it all out. In this case, you can merge the files manually together. You’ll need to copy the clusters, users, and contexts from the Tectonic configuration into your existing one. The benefit of doing this is that you’ll be able to change contexts to switch from one cluster to another.

Test your configuration 🔗

Once you finished your configuration, test to see if it works.

$ kubectl config use-context tectonic       # if you have multiple contexts in config
$ kubectl get nodes
NAME                                        STATUS    AGE
ip-10-0-0-59.us-east-2.compute.internal     Ready     1d
ip-10-0-23-239.us-east-2.compute.internal   Ready     1d
ip-10-0-44-211.us-east-2.compute.internal   Ready     1d
ip-10-0-61-218.us-east-2.compute.internal   Ready     1d
ip-10-0-67-239.us-east-2.compute.internal   Ready     1d
ip-10-0-95-51.us-east-2.compute.internal    Ready     1d

Huzzah! Now we’re ready to get to work.

Getting the deployment and service files 🔗

All of the example files come from the official Kubernetes GitHub repo. You can find them in the Guestbook example. To get started, create a new directory and download all of the files.

$ wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/examples/guestbook/redis-{master,slave}-{deployment,service}.yaml \
       https://raw.githubusercontent.com/kubernetes/kubernetes/master/examples/guestbook/frontend-{deployment,service}.yaml

We’ll explain what all of these do in next steps. All of these next steps will start with the command to run, followed by a short explanation of what’s actually happening.

Start the Redis master 🔗

$ kubectl create -f redis-master-service.yaml
service "redis-master" created
$ kubectl create -f redis-master-deployment.yaml
deployment "redis-master" created

Define the deployment 🔗

The redis-master-deployment.yaml file downloaded earlier defines the deployment and its characteristics. In this case, we have one pod that runs the Redis master in a container. Since we’re using a deployment, that means if our pod goes down, Kubernetes will spin up a new pod to replace it. Worth noting in this example, if the pod did go down, there would be a potential for data loss until the new one replaces the old one (since the Redis master is not highly available, i.e. there are multiple).

Define the service 🔗

Our service in this example is a named load balancer that proxies traffic across one or many containers. Even though we only have one Redis master pod, we still want to use a service. This is a deterministic way of making the route to the master with a dynamic (or elastic) IP address.

Labeling the pods is important in this case, as Kubernetes will use the pods’ labels to determine which pods receive the traffic sent to the service, and load balance it accordingly.

Create the service 🔗

The next important step is to create the service. Note that we’re doing this before we create the deployment. It’s best practice to create the service first. This allows the scheduler to later spread the service across the deployments you create to support your application.

After creating the service, you can check its status by running this command. You should see similar output.

$ kubectl get services
NAME              CLUSTER-IP       EXTERNAL-IP       PORT(S)       AGE
redis-master      10.0.76.248      <none>            6379/TCP      1s

Now your Redis master serivce is up and running! The next step will be to create the Redis master deployment.

If you look at the service configuration file, you’ll notice port and targetPort are two defined variables. Once everything is up and running, these will be important for determining how the traffic from the slaves to the masters is routed.

1. Redis slave connects to port on Redis master service
2. Traffic forwarded from service’s port to targetPort on pod the service listens to

Create the deployment 🔗

Next, we created the Redis master pod in the cluster. To see our deployment and pods, we can run the following commands to see what was created.

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
redis-master   1         1         1            1           27s

$ kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
redis-master-2353460263-1ecey   1/1       Running   0          1m
...

You should see all of the pods in your cluster so far. For now, that’s just the Redis master. Let’s give it some friends!

Start the Redis slaves 🔗

$ kubectl create -f redis-slave-service.yaml
service "redis-slave" created
$ kubectl create -f redis-slave-deployment.yaml
deployment "redis-slave" created

Defining the deployment 🔗

In the configuration file, we defined two replicas, unlike the master. By doing this, it tells Kubernetes that the minimum number of pods that should always be running is two. If one of your pods goes down, Kubernetes automatically creates a new one to support the application. If you want, you can try killing the Docker process for one of your pods to see it happen in real time.

Start the guestbook front-end 🔗

$ kubectl create -f frontend-service.yaml
service "frontend" created
$ kubectl create -f frontend-deployment.yaml
deployment "frontend" created

The front-end is a PHP application with an AJAX interface and Angular-based UI. When using the form on the front-end application, it talks to the Redis master or slave, depending on if it’s reading or writing to Redis. Again, we’re deploying the front-end with multiple replicas. In this case, there will be three pods to support the front-end.

Say hello! 🔗

Once you’ve finished deploying everything, your web app should now be accessible! To get the full domain from AWS, run this command to figure out where to look.

$ kubectl get deploy/frontend svc/frontend -o wide
NAME           CLUSTER-IP   EXTERNAL-IP                                                             PORT(S)        AGE       SELECTOR
svc/frontend   10.3.0.175   aaebd8247ef2311e6a045021d1620193-54019671.us-east-2.elb.amazonaws.com   80:31020/TCP   1m        k8s-app=guestbook,tier=frontend

NAME              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/frontend   3         3         3            3           1m

Congratulations, we’re all finished!

Cleaning up 🔗

Once you’re finished or when you want to stop running the guestbook, it’s easy to get rid of the deployments and services we created. Using labels, all the deployments and services can be deleted with one command.

$ kubectl delete deployments,services -l "app in (redis, guestbook)"

And now your guestbook application is offline. (It was nice while it lasted!)

Learn more about Kubernetes and Tectonic 🔗

If you want to explore more about Kubernetes, you can read some of the earlier articles in this series. You can also read the original tutorial published by Kubernetes on GitHub. Additionally, the upstream documentation for Kubernetes and Tectonic is thorough and can help answer more advanced questions.

Questions, Tectonic stories, or tips for beginners? Add your comments below.

Welcome back to the Kubernetes and Fedora series. Each week, we build on the previous articles in the series to help introduce you to using Kubernetes. This article takes off from running Kubernetes on your own hardware and moves us one step closer to the cloud. By the end of this article, you will…

• Understand what CoreOS Tectonic is
• Set up Amazon Web Services (AWS) for Tectonic
• Deploy Tectonic to AWS

This article is also based off of the excellent tutorial provided in the CoreOS documentation. Let’s get started!

What is Tectonic? 🔗

In the first article, some of the key concepts of Kubernetes and why it’s useful were explained. Kubernetes automates the deployment and setting up of your infrastructure across the three layers (users, masters, nodes). If you’re working on your own at a small scale, Kubernetes itself can be plenty to meet your needs. However, there is still a decent amount of human involvement in managing the different pieces of Kubernetes. If you’re working with multiple people in a team and across different environments, vanilla Kubernetes can be a lot to manage. For an enterprise environment, there’s still some unmet needs. This is where Tectonic steps in.

Tectonic is a commercial product offered by CoreOS, the providers of Container Linux and the original developers of etcd, now one of the core components of Kubernetes. Tectonic takes all of the open source components and pre-packages them. The self-proclaimed goal of doing this is to let anyone build a Google-style infrastructure into a cloud or on-premise environment. The outcome for the user is that it’s easy to install a Kubernetes infrastructure across many different environments. In addition to simplifying the installation of the various components of a Kubernetes stack, Tectonic also provides a management console, a container registry for building and sharing containers, additional tools for deployment, and a few other nice features.

If we think about Kubernetes as a cake like we did before with three layers, Tectonic is like the box you set it in. Now, you can take your cake anywhere, move it around, and stack it with other cakes-in-a-box. All of your cakes are in their own boxes and you don’t have to worry about them accidentally being damaged. If you’re still a little confused, this diagram might help make more sense of it.

Fortunately, Tectonic has a free license that lets you use it for ten nodes. In this example, we’ll register, get a free license, and deploy it into AWS.

(Note: If you want to revert anything we do in this example, there’s an easy way to dismantle it across AWS and bring your bill to $0.00.)

Pre-requisites 🔗

In order to successfully run this guide, there’s a few things you’ll need first.

• Amazon Web Services (AWS) account (free)
  • Register here
• CoreOS Tectonic account and license (free)
  • Register here
• A root-level or sub-domain (e.g. example.com or k8s.example.com)
  • If you look around, you can probably find some for less than USD$1 a year if you need one
• Curiosity!

Setting up DNS with Route 53 🔗

The first things we’ll do is set up our domain with Route 53 in AWS. Route 53 can do a lot of things, like DNS management, traffic management, availability monitoring, domain registration, and more. However, we’re only going to be using it for DNS management. Tectonic will use this to automatically provision DNS records for internal and external use.

Add your domain 🔗

To add your domain to Route 53, follow these steps from AWS.

1. From Services, select Networking & Content Delivery > Route 53.
2. Select Hosted zones from the left pane and click Create Hosted Zone.
3. Enter your domain or sub-domain, add a comment if you want, and choose a Public Zone for the type.

Once you’ve done this, you can go ahead and click “Create”.

Change the nameservers 🔗

After adding the hosted zone to Route 53, you’ll need to change the nameservers for your domain via the domain registrar (whoever you bought the domain from). Usually it should be easy to find this, but it varies among registrars. If you’re having a hard figuring out how to do this, try searching for a how-to or contacting your registrar’s support.

After you added the hosted zone, you should see the nameservers in Route 53. There will be four nameservers provided there. You can copy and paste them from Route 53 to your domain registrar. Also note that if you’re using a subdomain, the instructions might be a little different. You can read how to do this in the Route 53 documentation.

The nameservers could take minutes or hours to update, depending on how lucky you are. If you’re impatient and want to check, open up a terminal and run this command. If you see the AWS nameservers in the output, then your domain has propagated and is now usable by Route 53.

dig -t ns <example.com>

Configuring EC2 with SSH key pair 🔗

This guide assumes you already have an SSH key pair created on your system. If you don’t have one generated, you can read how to generate one here.

The next step for us is to add an SSH key pair to EC2, one of the compute engine products offered by AWS. We’ll import an existing key on your system into EC2.

1. From AWS, go to Services > Compute > EC2.
2. Confirm that you are in the correct EC2 region by checking the location next to your name in the menu bar.
3. Under Network & Security, click Key Pairs.
4. Click Import Key Pair.
5. Either upload your public key file (~/.ssh/id_rsa.pub) or paste it into the text field. Don’t forget to give it a name.

And that’s all you need to do!

Assigning AWS user privileges 🔗

Tectonic does the magic of setting up AWS for you, so you don’t have to manually add and create the services from the web interface. In order to do this, you need to add a user account that Tectonic can use to do all of the provisioning it needs. To do this, you’ll need to create a new Access ID and Secret key pair from AWS.

1. Select Services > Security, Identity & Compliance > IAM.
2. From the left hand pane, click Users, then click Add user.
3. Set the user details:
   1. User name can be anything you like (I used tectonic-mydomain.com)
   2. Access type only needs to be Programmatic access
4. For permissions, click Add user to group and create a new group for your user.
5. When creating a new group, attach only the policies needed by Tectonic to operate correctly:
   1. AmazonEC2FullAccess
   2. IAMFullAccess
   3. AmazonS3FullAccess
   4. AmazonVPCFullAccess
   5. AmazonRoute53FullAccess
6. Finish creating the user. You’ll then see the Access key ID and Secret access key. Hold onto these, you’ll need them later. You won’t get to see the secret key again!

Now we’re ready to install Tectonic! Let’s grab your credentials next.

Download Tectonic credentials 🔗

Jump back over to the CoreOS accounts page. When you’re logged in, you’ll see the Account Assets area. Download the CoreOS license file and pull secret. Later on in the installer, you’ll need to insert these to finish the installation.

Running the installer 🔗

Now things get interesting! We finally get to install and deploy Tectonic into AWS. The installer takes the form of a graphical installer in your web browser. To use the installer, you need to download the binary and run it. If you’re curious, you can find the installer source code on GitHub.

Download and run installer 🔗

First, open up a new terminal window and navigate to a directory you want to download the installer to. Even though you likely won’t need to run the installer again, you will want to hang on to this if you ever want to easily dismantle everything in AWS later.

curl -O https://releases.tectonic.com/tectonic-1.6.4-tectonic.1.tar.gz

Next, extract the tarball and navigate into the directory.

tar -xzvf tectonic-1.6.4-tectonic.1.tar.gz
cd tectonic/tectonic-installer

Now execute the installer binary. After running this, a new browser window will open that features the graphical installer.

./linux/installer

Running the installer 🔗

The installer is thorough and assumes safe defaults for most of the steps. Be sure to have your AWS Access and Secret ID keys on hand. You should be able to run through the installer without issue. If you’re confused about what any of the values mean or want to make custom changes, you can read more in the upstream documentation.

Once you’re finished, congrats! You’ve successfully installed Tectonic!

Check out your Tectonic install 🔗

Once you finish the installation successfully, your Tectonic installation will be accessible within AWS. You can navigate to the domain you specified during the install to find it. Unless you added a CA authority and certificates, your browser will probably complain about invalid SSL certificates, but you can ignore the warning safely. It might also take a few minutes before the URL is accessible, so if you were looking for a coffee or tea break, now would be a good time!

Once you’re logged in, you should see something like this.

Blow it all away! 🔗

If you’re like me, you might be frustrated by guides that tell you how to install things but not how to take it all apart. Fortunately, this guide not only tells you how to do that, but the Tectonic installer also makes it super easy to do. If you’re sure that you’re done with Tectonic and don’t want any leftovers to remain in AWS, this is the best way to do it, instead of deleting everything manually from the AWS Console.

Every installation has a time-stamped folder in the tectonic directory we used earlier. First, you need to navigate into the specific folder for the cluster you installed. It’s important to be inside of this directory first.

cd tectonic/tectonic-installer/linux/clusters/<CLUSTERNAME>

<CLUSTERNAME> will be the time-stamped directory. Once you’re in the folder, run this command to trigger the uninstaller. After running this, you’ll see the installer slowly dismantle everything and delete any leftovers in AWS.

../../terraform destroy

Once it finishes, you should see an output message confirming how many AWS resources were destroyed. And now you’re back to where you started.

Learn more about Tectonic 🔗

If you thought this was exciting and want to learn more, there is no shortage of resources for you to read. You can learn more about Tectonic from the CoreOS website or the original release announcement. You can also dig into the installer’s source code on GitHub. If you’re still trying to wrap your head around Tectonic, there’s a good write-up on virtualizationreview.com.

Next week, we’ll install a simple guestbook application to our Tectonic installation to see how it all works and what you can do with it. Stay tuned!

Questions, Tectonic stories, or tips for beginners? Add your comments below.

This is a short series to introduce Kubernetes, what it does, and how to experiment with it on Fedora. This is a beginner-oriented series to help introduce some higher level concepts and give examples of using it on Fedora. In the first post, we covered key concepts in Kubernetes. This second post shows you how to build a single-node Kubernetes deployment on your own computer.

Once you have a better understanding of what the key concepts and terminology in Kubernetes are, getting started is easier. Like many programming tutorials, this tutorial shows you how to build a “Hello World” application and deploy it locally on your computer using Kubernetes. This is a simple tutorial because there aren’t multiple nodes to work with. Instead, the only device we’re using is a single node (a.k.a. your computer). By the end, you’ll see how to deploy a Node.js application into a Kubernetes pod and manage it with a deployment on Fedora.

This tutorial isn’t made from scratch. You can find the original tutorial in the official Kubernetes documentation. This article adds some changes that will let you do the same thing on your own Fedora computer.

Introducing Minikube 🔗

Minikube is an official tool developed by the Kubernetes team to help make testing it out easier. It lets you run a single-node Kubernetes cluster through a virtual machine on your own hardware. Beyond using it to play around with or experiment for the first time, it’s also useful as a testing tool if you’re working with Kubernetes daily. It does support many of the features you’d want in a production Kubernetes environment, like DNS, NodePorts, and container run-times.

Installation 🔗

This tutorial requires virtual machine and container software. There are many options you can use. Minikube supports virtualbox, vmwarefusion, kvm, and xhyve drivers for virtualization. However, this guide will use KVM since it’s already packaged and available in Fedora. We’ll also use Node.js for building the application and Docker for putting it in a container.

Pre-requirements 🔗

You can install the prerequisites with this command.

$ sudo dnf install kubernetes libvirt-daemon-kvm kvm nodejs docker

After installing these packages, you’ll need to add your user to the right group to let you use KVM. The following commands will add your user to the group and then update your current session for the group change to take effect.

$ sudo usermod -a -G libvirt $(whoami)
$ newgrp libvirt

Docker KVM drivers 🔗

If using KVM, you will also need to install the KVM drivers to work with Docker. You need to add Docker Machine and the Docker Machine KVM Driver to your local path. You can check their pages on GitHub for the latest versions, or you can run the following commands for specific versions. These were tested on a Fedora 25 installation.

Docker Machine 🔗

$ curl -L https://github.com/docker/machine/releases/download/v0.12.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine
$ chmod +x /tmp/docker-machine
$ sudo cp /tmp/docker-machine /usr/local/bin/docker-machine

Docker Machine KVM Driver 🔗

This installs the CentOS 7 driver, but it also works with Fedora.

$ curl -L https://github.com/dhiltgen/docker-machine-kvm/releases/download/v0.10.0/docker-machine-driver-kvm-centos7 >/tmp/docker-machine-driver-kvm
$ chmod +x /tmp/docker-machine-driver-kvm
$ sudo cp /tmp/docker-machine-driver-kvm /usr/local/bin/docker-machine-driver-kvm

Installing Minikube 🔗

The final step for installation is getting Minikube itself. Currently, there is no package in Fedora available, and official documentation recommends grabbing the binary and moving it your local path. To download the binary, make it executable, and move it to your path, run the following.

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ chmod +x minikube
$ sudo mv minikube /usr/local/bin/

Now you’re ready to build your cluster.

Create the Minikube cluster 🔗

Now that you have everything installed and in the right place, you can create your Minikube cluster and get started. To start Minikube, run this command.

$ minikube start --vm-driver=kvm

Next, you’ll need to set the context. Context is how kubectl (the command-line interface for Kubernetes) knows what it’s dealing with. To set the context for Minikube, run this command.

$ kubectl config use-context minikube

As a check, make sure that kubectl can communicate with your cluster by running this command.

$ kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Build your application 🔗

Now that Kubernetes is ready, we need to have an application to deploy in it. This article uses the same Node.js application as the official tutorial in the Kubernetes documentation. Create a folder called hellonode and create a new file called server.js with your favorite text editor.

var http = require('http');

var handleRequest = function(request, response) {
 console.log('Received request for URL: ' + request.url);
 response.writeHead(200);
 response.end('Hello world!');
};
var www = http.createServer(handleRequest);
www.listen(8080);

Now try running your application and running it.

$ node server.js

While it’s running, you should be able to access it on localhost:8080. Once you verify it’s working, hit Ctrl+C to kill the process.

Create Docker container 🔗

Now you have an application to deploy! The next step is to get it packaged into a Docker container (that you’ll pass to Kubernetes later). You’ll need to create a Dockerfile in the same folder as your server.js file. This guide uses an existing Node.js Docker image. It exposes your application on port 8080, copies server.js to the image, and runs it as a server. Your Dockerfile should look like this.

FROM node:6.9.2
EXPOSE 8080
COPY server.js .
CMD node server.js

If you’re familiar with Docker, you’re likely used to pushing your image to a registry. In this case, since we’re deploying it to Minikube, you can build it using the same Docker host as the Minikube virtual machine. For this to happen, you’ll need to use the Minikube Docker daemon.

$ eval $(minikube docker-env)

Now you can build your Docker image with the Minikube Docker daemon.

$ docker build -t hello-node:v1 .

Huzzah! Now you have an image Minikube can run.

Create Minikube deployment 🔗

If you remember from the first part of this series, deployments watch your application’s health and reschedule it if it dies. Deployments are the supported way of creating and scaling pods. kubectl run creates a deployment to manage a pod. We’ll create one that uses the hello-node Docker image we just built.

$ kubectl run hello-node --image=hello-node:v1 --port=8080

Next, check that the deployment was created successfully.

$ kubectl get deployments
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-node   1         1         1            1           30s

Creating the deployment also creates the pod where the application is running. You can view the pod with this command.

$ kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
hello-node-1644695913-k2314   1/1       Running   0          3

Finally, let’s look at what the configuration looks like. If you’re familiar with Ansible, the configuration files for Kubernetes also use easy-to-read YAML. You can see the full configuration with this command.

$ kubectl config view

kubectl does many things. To read more about what you can do with it, you can read the documentation.

Create service 🔗

Right now, the pod is only accessible inside of the Kubernetes pod with its internal IP address. To see it in a web browser, you’ll need to expose it as a service. To expose it as a service, run this command.

$ kubectl expose deployment hello-node --type=LoadBalancer

The type was specified as a LoadBalancer because Kubernetes will expose the IP outside of the cluster. If you were running a load balancer in a cloud environment, this how you’d provision an external IP address. However, in this case, it exposes your application as a service in Minikube. And now, finally, you get to see your application. Running this command will open a new browser window with your application.

$ minikube service hello-node

Congratulations, you deployed your first containerized application via Kubernetes! But now, what if you need to our small Hello World application?

How do we push changes? 🔗

The time has come when you’re ready to make an update and push it. Edit your server.js file and change “Hello world!” to “Hello again, world!”

response.end('Hello again, world!');

And we’ll build another Docker image. Note the version bump.

$ docker build -t hello-node:v2 .

Next, you need to give Kubernetes the new image to deploy.

$ kubectl set image deployment/hello-node hello-node=hello-node:v2

And now, your update is pushed! Like before, run this command to have it open in a new browser window.

$ minikube service hello-node

If your application doesn’t come up any different, double-check that you updated the right image. You can troubleshoot by getting a shell into your pod by running the following command. You can get the pod name from the command run earlier (kubectl get pods). Once you’re in the shell, check if the server.js file shows your changes.

$ kubectl exec -it <pod-name> bash

Cleaning up 🔗

Now that we’re done, we can clean up the environment. To clear up the resources in your cluster, run these two commands.

$ kubectl delete service hello-node
$ kubectl delete deployment hello-node

If you’re done playing with Minikube, you can also stop it.

$ minikube stop

If you’re done using Minikube for a while, you can unset Minikube Docker daemon that we set earlier in this guide.

$ eval $(minikube docker-env -u)

Learn more about Kubernetes 🔗

You can find the original tutorial in the Kubernetes documentation. If you want to read more, there’s plenty of great information online. The documentation provided by Kubernetes is thorough and comprehensive.

Questions, Minikube stories, or tips for beginners? Add your comments below.

This article is part of a short series that introduces Kubernetes. This beginner-oriented series covers some higher level concepts and gives examples of using Kubernetes on Fedora.

The information technology world changes daily, and the demands of building scalable infrastructure become more important. Containers aren’t anything new these days, and have various uses and implementations. But what about building scalable, containerized applications? By itself, Docker and other tools don’t quite cut it, as far as building the infrastructure to support containers. How do you deploy, scale, and manage containerized applications in your infrastructure? This is where tools such as Kubernetes comes in. Kubernetes is an open source system that automates deployment, scaling, and management of containerized applications. Kubernetes was originally developed by Google before being donated to the Cloud Native Computing Foundation, a project of the Linux Foundation. This article gives a quick precursor to what Kubernetes is and what some of the buzzwords really mean.

What is Kubernetes? 🔗

Kubernetes simplifies and automates the process of deploying containerized applications at scale. Just like Ansible orchestrates software, Kubernetes orchestrates deploying infrastructure that supports the software. There are various “layers of the cake” that make Kubernetes a strong solution for building resilient infrastructure. It also assists with making systems that can grow at scale. If your application has increasing demands such as higher traffic, Kubernetes helps grow your environment to support increasing demands. This is one reason why Kubernetes is helpful for building long-term solutions for complex problems (even if it’s not complex… yet).

At a high level overview, imagine three different layers.

• Users: People who deploy or create containerized applications to run in your infrastructure
• Master(s): Manages and schedules your software across various other machines, for example in a clustered computing environment
• Nodes: Various machines to support the application, called kubelets

These three layers are orchestrated and automated by Kubernetes. One of the key pieces of the master (not included in the visual) is etcd. etcd is a lightweight and distributed key/value store that holds configuration data. Each node, or kubelet, can access this data in etcd through a HTTP/JSON API interface. The components of communication between master and node such as etcd are explained in the official documentation.

Another important detail not shown in the diagram is that you might have many masters. In a high-availability (HA) set-up, you can keep your infrastructure resilient by having multiple masters in case one happens to go down.

Terminology 🔗

It’s important to understand the concepts of Kubernetes before you start to play around with it. There are many core concepts in Kubernetes, such as services, volumes, secrets, daemon sets, and jobs. However, this article explains four that are helpful for the next exercise of building a mini Kubernetes cluster. The three concepts are pods, labels, replica sets, and deployments.

Pods 🔗

If you imagine Kubernetes as a Lego® castle, pods are the smallest block you can pick out. By themselves, they are the smallest unit you can deploy. The containers of an application fit into a pod. The pod can be one container, but it can also be as many as needed. Containers in a pod are unique since they share the Linux namespace and aren’t isolated from each other. In a world before containers, this would be similar to running an application on the same host machine.

When the pods share the same namespace, all the containers in a pod:

• Share an IP address
• Share port space
• Find each other over localhost
• Communicate over IPC namespace
• Have access to shared volumes

But what’s the point of having pods? The main purpose of pods is to have groups of “helping” containers on the same namespace (co-located) and integrated together (co-managed) along with the main application container. Some examples might be logging or monitoring tools that check the health of your application, or backup tools that act when certain data changes.

In the big picture, containers in a single pod are always scheduled together too. However, Kubernetes doesn’t automatically reschedule them to a new node if the node dies (more on this later).

Labels 🔗

Labels are a simple but important concept in Kubernetes. Labels are key/value pairs attached to objects in Kubernetes, like pods. They let you specify unique attributes of objects that actually mean something to humans. You can attach them when you create an object, and modify or add them later. Labels help you organize and select different sets of objects to interact with when performing actions inside of Kubernetes. For example, you can identify:

• Software releases: Alpha, beta, stable
• Environments: Development, production
• Tiers: Front-end, back-end

Labels are as flexible as you need them to be, and this list isn’t comprehensive. Be creative when thinking of how to apply them.

Replica sets 🔗

Replica sets are where some of the magic begins to happen with automatic scheduling or rescheduling. Replica sets ensure that a number of pod instances (called replicas) are running at any moment. If your web application needs to constantly have four pods in the front-end and two in the back-end, the replica sets are your insurance that number is always maintained. This also makes Kubernetes great for scaling. If you need to scale up or down, change the number of replicas.

When reading about replica sets, you might also see replication controllers. They are somewhat interchangeable, but replication controllers are older, semi-deprecated, and less powerful than replica sets. The main difference is that sets work with more advanced set-based selectors – which goes back to labels. Ideally, you won’t have to worry about this much today.

Even though replica sets are where the scheduling magic happens to help make your infrastructure resilient, you won’t actually interact with them much. Replica sets are managed by deployments, so it’s unusual to directly create or manipulate replica sets. And guess what’s next?

Deployments 🔗

Deployments are another important concept inside of Kubernetes. Deployments are a declarative way to deploy and manage software. If you’re familiar with Ansible, you can compare deployments to the playbooks of Ansible. If you’re building your infrastructure out, you want to make sure it is easily reproducible without much manual work. Deployments are the way to do this.

Deployments offer functionality such as revision history, so it’s always easy to rollback changes if something doesn’t work out. They also manage any updates you push out to your application, and if something isn’t working, it will stop rolling out your update and revert back to the last working state. Deployments follow the mathematical property of idempotence, which means you define your specs once and use them many times to get the same result.

Deployments also get into imperative and declarative ways to build infrastructure, but this explanation is a quick, fly-by overview. You can read more detailed information in the official documentation.

Installing on Fedora 🔗

If you want to start playing with Kubernetes, install it and some useful tools from the Fedora repositories.

sudo dnf install kubernetes

This command provides the bare minimum needed to get started. You can also install other cool tools like cockpit-kubernetes (integration with Cockpit) and kubernetes-ansible (provisioning Kubernetes with Ansible playbooks and roles).

Learn more about Kubernetes 🔗

If you want to read more about Kubernetes or want to explore the concepts more, there’s plenty of great information online. The documentation provided by Kubernetes is fantastic, but there are also other helpful guides from DigitalOcean and Giant Swarm. The next article in the series will explore building a mini Kubernetes cluster on your own computer to see how it really works.

Questions, Kubernetes stories, or tips for beginners? Add your comments below.