I'm currently working on making a game where the servers need to be replicated on pods inside the Minikube cluster (I'm using Minikube since it's just a school project). However, I cannot seem to figure out how to make these game servers accessible from other networks. I have tried making a NodePort service, that points to the deployment of my server image, and when using the Minikube cluster IP + my service's port I can connect fine.
What would be the best approach to solve this issue?
By default, the Pod is only accessible by its internal IP address within the Kubernetes cluster. To make the your container accessible from outside the Kubernetes virtual network, you have to expose the Pod as a Kubernetes Service in this example as a type LoadBalancer.
On cloud providers that support load balancers, an external IP address would be provisioned to access the Service. On Minikube, the LoadBalancer type makes the Service accessible through the minikube service command.
Minikube is great for local setups but not for real clusters. It spins up only a one-node cluster for development and testing. It is useless if you want to use multiple servers environment.
Taking under consideration that you want to play fast with scalability across the nodes it is useful to create Kubernetes cluster - using Kubespray or Kubeadm.
If you want to run an actual local Kubernetes, use a local VM and then create K8s cluster using these tools for automated deployment.
Kubeadm
The kubeadm tool is good if you are new in cloud technologies -run k8s cluster for the first time. You can install and use kubeadm on various machines: your laptop, a set of cloud servers and more. Whether you’re deploying into the cloud or on-premises, you can integrate kubeadm into provisioning systems such as Ansible or Terraform.
Kubeadm provides domain Knowledge of Kubernetes clusters' life cycle management, including self-hosted layouts, dynamic discovery services and so on.
Kubespray
Kubespray supports deployments on AWS, Google Compute Engine, Microsoft Azure, OpenStack, and bare metal. It enables deployment of Kubernetes highly available clusters. It supports a variety of Linux distributions and CI. Kubespray supports kubeadm.
There isn't really a good way to do this. Minikube is for local development. If you want to run an actual local Kubernetes, start a local VM directly and use something like kubeadm and kubespray.
Related
I have a project to containerize several applications (Gitlab, Jenkins, Wordpress, Python Flask app...). Currently each application runs on a Compute Engine VM each at GCP. My goal would be to move everything to a cluster (Swarm or Kubernetes).
However I have different questions about Docker Swarm on Google Cloud Platform:
How can I expose my Python application on the outside (HTTP load balancer) as well as the other applications only available in my private VPC ?
From what I've seen on the internet, I have the impression that docker swarm is very little used. Should I go for a kubernetes cluster instead ? (I have good knowledge of Docker/Kubernetes)
It is difficult to find information about Docker Swarm in cloud providers. What would be an architecture with Docker Swarm on GCP?
Thanks for your help.
I'd create a template and from that an instance group for all VM, which shall host the Docker swarm. And a separate instance or instance group for said internal purposes - so that there is a strict separation, which can then be used to route the internal & external traffic accordingly (this would apply in any case). Google Kubernetes Engine is about the same as such an instance group, but Google managed infrastructure. See the tutorial, there's not much difference - except that it better integrates with gcloud & kubectl. While there is no requirement to want or need to maintain the underlying infrastructure, GKE is probably less effort.
What you are basically asking is:
Kubernetes vs. Docker Swarm: What’s the Difference?
Docker Swarm vs Kubernetes: A Helpful Guide for Picking One
Kubernetes vs. Docker: What Does it Really Mean?
Docker Swarm vs. Kubernetes: A Comparison
Kubernetes vs Docker Swarm
The setup below is all done on Google Cloud.
I have a Docker setup running on a VM instance having a Hyperledger Fabric Network of 3 Orderers and 2 peers of a single organization.
I have a Kubernetes Cluster running on GKE having just 2 peer pods.
What I want to achieve is:
I want the peer pod of Kubernetes to be able to communicate with the network setup in Docker.
i.e. I want at least 1 peer of the Kubernetes to be able to join the network channel on the Docker
Network and be able to perform some transaction/query.
Till now what I have done is exposed the services of the 2 peer pods in Kubernetes i.e. ClusterIP -> NodePort.
I have done some reading as to what options are there such as having an Nginx proxy and other things, but I am new to this and still in a beginner phase so a few things are still confusing to me.
Any help would be appreciated.
Since you have two separate container setups (and two different container technologies), containers in one space have to communicate with the other as though they're outside the cluster. You can't join arbitrary Docker containers on another instance into the Kubernetes network environment, nor can you join Kubernetes pods into a single-host Docker network environment.
Using a NodePort or LoadBalancer-type Service as you already have is close to the best you can do, particularly if the underlying protocol isn't HTTP. If you need a multi-host setup, migrating the whole thing into GKE might be a better long-term answer.
Most tutorials I've seen for developing with Kubernetes locally use Minikube. In the latest Edge release of Docker for Windows, you can also enable Kubernetes. I'm trying to understand the differences between the two and which I should use.
Minikube lets you choose the version of Kubernetes you want, can Docker for Windows do that? I don't see a way to configure it.
Minikube has CLI commands to enable the dashboard, heapster, ingress and other addons. I'm not sure why because my undertstanding is that these are simply executing kubectl apply -f http://....
With Minikube I can do a minikube ip to get the cluster IP address for ingress, how can I do this with Docker for Windows?
Is there anything else different that I should care about.
I feel like you largely understand the space, and mostly have answers to your questions already. You might find Docker for Mac vs. Docker Toolbox an informative read, even if it's about the Mac equivalent rather than Windows and about Docker packaged as a VM rather than Kubernetes specifically.
In fact you are stuck with the specific version of Kubernetes the Docker Edge desktop distribution publishes.
is answered in the question.
I believe NodePort-type Services are published on your host's IP address; there isn't an intermediate VM address like there is with Docker Toolbox.
Docker Toolbox and minikube always use a full-blown virtual machine with an off-the-shelf hypervisor. The Docker desktop application might use a lighter-weight virtualization engine if one is available.
Kubernetes can involve some significant background work. If you're using Kubernetes-in-Docker it's hard to "turn off" Kubernetes and still have Docker available; but if you have a separate minikube VM you can just stop it.
Here is a part from Docker documentation:
Kubernetes is only available in Docker for Windows 18.02 CE Edge.
Kubernetes support is not included in Docker for Windows 18.02 CE
Stable. To find out more about Stable and Edge channels and how to
switch between them, see General configuration.
Docker for Windows 18.02 CE Edge includes a standalone Kubernetes
server and client, as well as Docker CLI integration. The Kubernetes
server runs locally within your Docker instance, is not configurable,
and is a single-node cluster.
The Kubernetes server runs within a Docker container on your local
system, and is only for local testing. When Kubernetes support is
enabled, you can deploy your workloads, in parallel, on Kubernetes,
Swarm, and as standalone containers. Enabling or disabling the
Kubernetes server does not affect your other workloads.
See Docker for Windows > Getting started to enable Kubernetes and
begin testing the deployment of your workloads on Kubernetes.
If you have enough CPU and RAM resources, you can easily have both, minikube and docker-for-desktop on the same machine and switch between them by selecting the context, e.g.:
> kubectl config get-contexts
> kubectl config use-context docker-for-desktop
There is no place at the moment to choose the Kubernetes version for docker-for-desktop. It is preselected in the Docker distribution package.
Unfortunately, version of docker inside the minikube is a step behind compared to available on the docker website, and some features could be missing, but if you are interested in Kubernetes environment, it doesn't really matter in most cases.
Some of the features of Kubernetes rely on external resources and could be unavailable for you in case of local installation. For example, you need an ability to create Cloud Load Balancer to use some types of the Ingress or Service objects.
But other resources can be easily started inside the minikube, or docker-for-desktop using kubectl create/apply.
To expose your cluster resources externally, you can use Webhook Relay Ingress controller.
Here is a link to the installation manual.
I know that Docker and Kubernetes aren’t direct competitors. Docker is the container platform and containers are coordinated and scheduled by Kubernetes, which is a tool.
What does it really mean and how can I deploy my app on Docker for Azure ?
Short answer:
Docker (and containers in general) solve the problem of packaging an application and its dependencies. This makes it easy to ship and run everywhere.
Kubernetes is one layer of abstraction above containers. It is a distributed system that controls/manages containers.
My advice: because the landscape is huge... start learning and putting the pieces of the puzzle together by following a course. Below I have added some information from the:
Introduction to Kubernetes, free online course from The Linux Foundation.
Why do we need Kubernetes (and other orchestrators) above containers?
In the quality assurance (QA) environments, we can get away with running containers on a single host to develop and test applications. However, when we go to production, we do not have the same liberty, as we need to ensure that our applications:
Are fault-tolerant
Can scale, and do this on-demand
Use resources optimally
Can discover other applications automatically, and communicate with each other
Are accessible from the external world
Can update/rollback without any downtime.
Container orchestrators are the tools which group hosts together to form a cluster, and help us fulfill the requirements mentioned above.
Nowadays, there are many container orchestrators available, such as:
Docker Swarm: Docker Swarm is a container orchestrator provided by Docker, Inc. It is part of Docker Engine.
Kubernetes: Kubernetes was started by Google, but now, it is a part of the Cloud Native Computing Foundation project.
Mesos Marathon: Marathon is one of the frameworks to run containers at scale on Apache Mesos.
Amazon ECS: Amazon EC2 Container Service (ECS) is a hosted service provided by AWS to run Docker containers at scale on its infrastructrue.
Hashicorp Nomad: Nomad is the container orchestrator provided by HashiCorp.
Kubernetes is built on Docker technology. It is an orchestration tool for Docker container whereas Docker is a technology to create and deploy containers.
Docker, starting with a platform-as-a-service (PaaS) provider named dotCloud.
All in all, Kubernetes is related to the Docker container, allowing you to implement application portability and extensibility in container orchestration.
DOCKER
Easy and fast to install and configure
Functionality is provided and limited by the Docker API
Quick container deployment and scaling even in very large clusters
Automated internal load balancing through any node in the cluster
Simple shared local volumes
Kubernetes
Require some work to get up and running
Client, API and YAML definitions are unique to Kubernetes
Provides strong guarantees to cluster states at the expense of speed
To Enable load balancing requires manual service configuration
Volumes shared within pods
This is just a basic idea which at least explains the difference.If you want to go in depth see my posts
http://www.thecreativedev.com/an-introduction-to-kubernetes/
http://www.thecreativedev.com/learn-docker-works/
Docker and Kubernetes are complementary. Docker provides an open standard for packaging and distributing containerized applications, while Kubernetes provides for the orchestration and management of distributed, containerized applications created with Docker. In other words, Kubernetes provides the infrastructure needed to deploy and run applications built with Docker.
We are currently moving towards microservices with Docker from a monolith application running in JBoss. I want to know the platform/tools/frameworks to be used to test these Docker containers in developer environment. Also what tools should be used to deploy these containers to this developer test environment.
Is it a good option to use some thing like Kubernetes with chef/puppet/vagrant?
I think so. Make sure to get service discovery, logging and virtual networking right. For the former you can check out skydns. Docker now has a few logging plugins you can use for log management. For virtual networking you can look for Flannel and Weave.
You want service discovery because Kubernetes will schedule the containers the way it sees fit and you need some way of telling what IP/port your microservice will be at. Virtual networking make it so each container has it's own subnet thus preventing port clashes in case you have two containers with the same ports exposed in the same host (kubernetes won't let it clash, it will schedule containers to run until you have hosts with ports available, if you try to create more it just won't run).
Also, you can try the built-in cluster tools in Docker itself, like docker service, docker network commands and Docker Swarm.
Docker-machine helps in case you already have a VM infrastructure in place.
We have created and open-sourced a platform to develop and deploy docker based microservices.
It supports service discovery, clustering, load balancing, health checks, configuration management, diagnosing and mini-DNS.
We are using it in our local development environment and production environment on AWS. We have a Vagrant box with everything prepared so you can give it a try:
http://armada.sh
https://github.com/armadaplatform/armada