Skip to content

Commit 4bd3096

Browse files
committed
Fixes knrt10#4
Signed-off-by: knrt10 <[email protected]>
1 parent 7a6f932 commit 4bd3096

File tree

1 file changed

+59
-6
lines changed

1 file changed

+59
-6
lines changed

readme.md

Lines changed: 59 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -24,6 +24,10 @@ This is just a simple demonstration to get a basic understanding of how kubernet
2424
- [Pushing the image to an image registry](#pushing-the-image-to-an-image-registry)
2525
- [Pushing image to docker hub](#pushing-image-to-docker-hub)
2626
3. **Kubernetes**
27+
- [What is Kubernetes](#what-is-kubernetes)
28+
- [Splitting apps into microservice](#splitting-apps-into-microservice)
29+
- [Scaling Microservices](#scaling-microservices)
30+
- [Deploying Microservices](#deploying-microservices)
2731
- [Working with Kubernetes](#working-with-kubernetes)
2832
- [Setting up a Kubernetes cluster](#setting-up-a-kubernetes-cluster)
2933
- [Running a local single node Kubernetes cluster with Minikube](#running-a-local-single-node-kubernetes-cluster-with-minikube)
@@ -57,6 +61,7 @@ This is just a simple demonstration to get a basic understanding of how kubernet
5761
- [Scheduling pods to specific nodes](#scheduling-pods-to-specific-nodes)
5862
- [Scheduling to one specific node](#scheduling-to-one-specific-node)
5963
- [Annotating pods](#Annotating-pods)
64+
- [Looking up an objects annotations](#looking-up-an-objects-annotations)
6065

6166
4. [Todo](#todo)
6267

@@ -226,15 +231,56 @@ Before you can push the image to Docker Hub, you need to log in under your user
226231

227232
`docker push knrt10/kubia`
228233

229-
## Working with Kubernetes
234+
### What is Kubernetes
235+
236+
Years ago, most software applications were big monoliths, running either as a single process or as a small number of processes spread across a handful of servers. Today, these big monolithic legacy applications are slowly being broken down into smaller, independently running components called microservices. Because microservices are decoupled from each other, they can be developed, deployed, updated, and scaled individually. This enables you to change components quickly and as often as necessary to keep up with today’s rapidly changing business requirements.
237+
238+
But with bigger numbers of deployable components and increasingly larger datacenters, it becomes increasingly difficult to configure manage, and keep the whole system running smoothly. It’s much harder to figure out where to put each of those components to achieve high resource utilization and thereby keep the hardware costs down. Doing all this manually is hard work. We need automation, which includes automatic scheduling of those components to our servers, automatic configuration, supervision, and failure-handling. This is where **Kubernetes** comes in.
239+
240+
Kubernetes enables developers to deploy their applications themselves and as often as they want, without requiring any assistance from the operations (ops) team. But Kubernetes doesn’t benefit only developers. It also helps the ops team by automatically monitoring and rescheduling those apps in the event of a hardware failure. The focus for system administrators (sysadmins) shifts from supervising individual apps to mostly supervising and managing Kubernetes and the rest of the infrastructure, while Kubernetes itself takes care of the apps.
241+
242+
#### Splitting apps into microservice
243+
244+
Each microservice runs as an independent process and communicates with other microservices through simple, well-defined interfaces (APIs). Refer to below image
245+
246+
![Microservice](https://user-images.githubusercontent.com/24803604/68068406-bf4bb200-fd54-11e9-8565-6214d30616bb.png)
247+
248+
> Image taken from other source
249+
250+
251+
Microservices communicate through synchronous protocols such as HTTP, over which they usually expose RESTful (REpresentational State Transfer) APIs, or through asynchronous protocols such as AMQP (Advanced Message Queueing Protocol). These protocols are simple, well understood by most developers, and not tied to any specific programming language. Each microservice can be written in the language that’s most appropriate for implementing that specific microservice.
252+
253+
Because each microservice is a standalone process with a relatively static external API, it’s possible to develop and deploy each microservice separately. A change to one of them doesn’t require changes or redeployment of any other service, provided that the API doesn’t change or changes only in a backward-compatible way.
254+
255+
#### Scaling Microservices
256+
257+
Scaling microservices, unlike monolithic systems, where you need to scale the system as a whole, is done on a per-service basis, which means you have the option of scaling only those services that require more resources, while leaving others at their original scale. Refer to image below
258+
259+
![Scaling](https://user-images.githubusercontent.com/24803604/68068433-03d74d80-fd55-11e9-87fe-5fad885168d1.png)
260+
261+
> Image taken from other source
262+
263+
When a monolithic application can’t be scaled out because one of its parts is unscalable, splitting the app into microservices allows you to horizontally scale the parts that allow scaling out, and scale the parts that don’t, vertically instead of horizontally.
264+
265+
#### Deploying Microservices
266+
267+
As always, microservices also have drawbacks. When your system consists of only a small number of deployable components, managing those components is easy. It’s trivial to decide where to deploy each component, because there aren’t that many choices. When the number of those components increases, deployment-related decisions become increasingly difficult because not only does the number of deployment combinations increase, but the number of inter-dependencies between the components increases by an even greater factor.
268+
269+
Microservices also bring other problems, such as making it hard to debug and trace execution calls, because they span multiple processes and machines. Luckily, these problems are now being addressed with distributed tracing systems such as Zipkin.
270+
271+
![Drawback](https://user-images.githubusercontent.com/24803604/68068466-62043080-fd55-11e9-867f-971dc4df862f.png)
272+
273+
> Multiple applications running on the same host may have conflicting dependencies.
274+
275+
#### Working with Kubernetes
230276

231277
Now that you have your app packaged inside a container image and made available through Docker Hub, you can deploy it in a Kubernetes cluster instead of running it in Docker directly. But first, you need to set up the cluster itself.
232278

233279
#### Setting up a Kubernetes cluster
234280

235281
Setting up a full-fledged, multi-node Kubernetes cluster isn’t a simple task, especially if you’re not well-versed in Linux and networking administration. A proper Kubernetes install spans multiple physical or virtual machines and requires the networking to be set up properly so that all the containers running inside the Kubernetes cluster can connect to each other through the same flat networking space.
236282

237-
### Running a local single node Kubernetes cluster with Minikube
283+
#### Running a local single node Kubernetes cluster with Minikube
238284

239285
The simplest and quickest path to a fully functioning Kubernetes cluster is by using Minikube. Minikube is a tool that sets up a single-node cluster that’s great for both testing Kubernetes and developing apps locally.
240286

@@ -638,15 +684,22 @@ But setting the *nodeSelector* to a specific node by the hostname label may lead
638684

639685
### Annotating pods
640686

641-
In addition to other labels, pods and other objects can also contain annotations. They are also key value pairs, so in essence they are similar to labels, but aren't meant to hold identifying information. They can't be used to group objects the way label can.
687+
In addition to other labels, pods and other objects can also contain annotations. They are also key value pairs, so in essence they are similar to labels, but aren't meant to hold identifying information. They can't be used to group objects the way label can. While objects can be selected through label selectors, there’s no such thing as an annotation selector. On the other hand, annotations can hold much larger pieces of information and are primarily meant to be used by tools. Certain annotations are automatically added to objects by Kubernetes, but others are added by users manually.
688+
689+
A great use to annotating pods is to add desciption to each pod or other API object so that everyone using the cluster can quickly look up information about each individual object.
690+
691+
#### Looking up an objects annotations
642692

643-
Example
693+
Let’s see an example of an annotation that Kubernetes added automatically to the pod you created in the previous section. To see the annotations, you’ll need to request the full YAML of the pod or use the `kubectl describe` command. You’ll use the first option in the following listing.
644694

645-
`kubeclt get pod -a`
695+
`kubectl get po kubia-zxzij -o yaml`
696+
```bash
697+
698+
```
646699

647700
## Todo
648701

649-
- [x] ~~Write more about pods~~
702+
- [ ] Write more about pods
650703
- [ ] Write about yaml files
651704
- [ ] Write about ingress routing
652705
- [ ] Write about volumes

0 commit comments

Comments
 (0)