IoT Edge deployed into Kubernetes and managed with Azure Arc - azure-iot-edge

Working with a partner who want to use K8s across cloud and edge and potentially use Azure Arc to manage this. Azure IoT Edge will be deployed into K8s with the K8s cluster managed with Arc.
Has anyone done this? Any potential problems people see?
Thanks!
BTW - couldn't find a # for azure-arc and I don't have sufficient reputation points to create it. Gah.

You can deploy and manage iotedged via Arc however workload config still needs to be configured via IoT Hub. See: https://learn.microsoft.com/azure/azure-arc/kubernetes/deploy-azure-iot-edge-workloads

Related

How Amazon Elastic Container Service is Different from Kubernetes when we want to deploy our dockerize application over it?

I am planning to start my project but a bit confuse between choosing Amazon ECS and Kubernetes perhaps I am really a beginner with Micro-services architecture.
I would really appreciate if someone can show some path for deploying my docker container on a fast easier to handle platform.
Thanks
Here a list of differences from the top of my head:
AWS ECS / Kubernetes:
Proprietary AWS implementation / Open source solution
Runs on AWS / Supported by most cloud providers and on premise
Task Definitions / PODs have different features
Runs on your EC2 machines or allows for serverless with Fargate (in beta) / Runs on any cluster of (physical/virtual/cloud) machines running the kubernetes controller.
Support for AWS VPCs / Support for multiple networking models
I would also argue that kubernetes has a slightly steeper learning curve but ultimately provides more freedom and is probably a safer bet for the future given the wide adoption.
Features supported in both systems:
Horizontal application scalability
Cluster Scalability
Load Balancing
Rolling upgrades
Logging (with additional logging systems)
Container Health Checks
APIs
Amazon has bowed to customer pressure and currently has a managed kubernetes support in beta (EKS).
*edit: EKS is released now - but with an upcharge for the cluster controller nodes, as compared to google GKE for example.
Here is one article about the topic.

What is the simplest reasonable Kubernetes setup?

I'm interested in getting started with Kubernetes, but my needs are simple and it does not look simple. I have a number of containerized applications that I deploy to container servers. I use nginx as a reverse proxy to expose these applications.
As far as I can tell, Kubernetes is meant to simplify management of setups like this. But I'm not sure the setup investment is worth it, given that I only realistically need one instance of each app running.
What is the simplest reasonable Kubernetes setup that I can deploy a few containerized applications to?
EDIT: If I start using Kubernetes, it will be using only on-site servers. The applications in question are ones I’ve developed for my employer, who requires that everything stays on-site.
On developers machine; you should use minikube.
On Azure / Google / Amazon ..etc; you should use managed kubernetes services
On Prem you should deploy kubernetes with on your own setup.
3.1. https://github.com/kelseyhightower/kubernetes-the-hard-way
3.2. with kubeadm
3.3 with ansible scripts like kubespray
If you choose kubeadm installation,while you are upgrading kubernetes cluster, again you should use kubeadm again. Best way to deploy on prem is using kubeadm, kube-spray or automating it with Pivotal's Bosh scripts
As you want to get started with Kubernetes, I assume that you want to set-up for your local development, I think that minikube is a best candidate for this purpose. You can also take a look at interactive tutorials from official Kubernetes website, I find it very helpful.
Take a look at this opinionated cluster setup k8s-snowflake and deploy it somewhere like Azure, or Google Compute.
It's a great exercise to figure out how kubernetes clusters work at a low level, but when you're ready to go to production, take a look at Google's Container Engine or AWS Elastic Container Engine. These ease the management of clusters immensely and exposes all the other benefits of the cloud platform to your kubernetes workloads.
Well according to previous answers you should start with minikube on your machine.
Regarding the futher dev/test/staging/prod deployment it depends. There are a couple of solutions:
use clusters provided by Google, Azure or AWS (AWS EKS is not ready yet - https://aws.amazon.com/eks/)
the hard way - setup own cluster or EC2 machines or similar
use tools like Rancher - some additional abstration over k8s for easy start, from version 2.0 k8s will be default mechanism orchiestration for Rancher
Update 31-01-2018:
regarding the hard way - there are of course some tools which helps with that approach like helm
The Kubernetes docs provide an excellent page to choose between the different options to setup kubernetes. The page is found under Picking the Right Solution.
If you want a simple way for setting a kubernetes cluster on premise, check kubeadm.

Can I use docker to automatically spawn instances of whole microservices?

I have a microservice with about 6 seperate components.
I am looking to sell instances of this microservice to people who need dedicated versions of it for their project.
Docker seems to be the solution to doing this as easily as possible.
What is still very unclear to me is, is it possible to use docker to deploy whole instances of microservices within a cloud service like GCP or AWS?
Is this something more specific to the Cloud provider itself?
Basicly in the end, I'd like to be able to, via code, start up a whole new instance of my microservice within its own network having each component be able to speak to eachother.
One big problem I see is assigning IP's to the containers so that they will find each other, independent of which network they are in. Is this even possible or is this not yet feasible with current cloud techonology?
Thanks a lot in advance, I know this is a big one...
They is definitely feasible and is nowadays one of the most popular ways to ship and deploy applications. However, the procedure to deploy varies slightly based on the cloud provider that you choose.
The good news is that the packaging of your microservices with Docker is independent from the cloud provider you use. You basically need to package each component in a Docker image, and deploy these images to a cloud platform.
All popular cloud platforms nowadays support deployment of docker containers. You can use in addition popular frameworks such as Docker swarm or Kubernetes on these cloud platforms to orchestrate the microservices deployment.

Will istio add support for docker swarm?

istio An open platform to connect, manage, and secure micro-services looks very interesting, but supports only Kubernetes. I couldn't find a roadmap or mention of future support for other container management platforms, specifically Docker Swarm
The project's github site does state the following explicitly:
Istio currently only supports the Kubernetes platform, although we
plan support for additional platforms such as Cloud Foundry, and Mesos
in the near future.
I don't know about the plans for Docker Swarm however I believe it probably would figure in the plans.
The roadmap at https://istio.io/docs/reference/release-roadmap.html shows that VM support is planned for 0.2
You can see that work is happening in the Cloud Foundry world when you see issues such as this.
The docker team indicated recently they are very interested in looking at istio and docker swarm integration so stay tuned this may happen in the next few quarters before you know it :)

Is CloudFoundry compatible with Docker/CoreOS?

I am interested in installing OpenStack to a couple of physical we have lying around, and then, somehow, deploying CloudFoundry on top of of it, as the PaaS.
I am also interested in playing around with Docker and CoreOS, and see that an integration between OpenStack and CoreOS already exists.
My question: if I have OpenStack/Nova spinning up VMs running CoreOS, and hence be Docker/container-based, will this be compatible with CloudFoundry, or is CloudFoundry somehow incompatible with Docker containers?
Cloud Foundry is installed using a specialised tool called Bosh. It has support for Openstack and I think would require deployment using Ubuntu VMs (open to correction on this point). Cloud Foundry has not integrated Docker yet, that is coming in the next version, google "Cloud Foundry" and "Diego".
maybe I'm not fully understanding here, but I was under the impression
that containers can't just stand on their own. They would require
living inside a VM. So my thinking/hope was that I could use
CloudFoundry to spin up VM instances, and inside those instances,
deploy containers. Thoughts?
Containers are completely standalone, they are a form of lightweight virtualization. Cloud Foundry is a platform for deploying your application. It runs on virtual machines (or physical servers) and instances of your application are compiled and run on the CF hosts within containers. Currently the container tech used by CF is something called Warden. Diego is a new CF component coming in 2015 that will offer Docker support.
then what is the difference between CF Diego and Kubernetes, which
also seems to be about deploying/distributing your container across
pools of nodes? Do they serve different, similar or identical
purposes? In other words, would there be a use case for having both CF
Diego and Kubernetes managing your app deployments, if so, what?
Kubernetes is a Google sponsored project for orchestrating containers across multiple hosts. Cloud Foundry goes further because it also contains features for building and versioning applications that are deployed. It's worth noting that Redhat have a competing PAAS solution called Openshift. The next version (already available in github) has integrated Kubernetes and added in all the missing application build support, making it comparable to what Cloud Foundry offers. Both CF Diego and Openshift V3 are due for delivery sometime in 2015.
Update
I see from your other questions, you're familiar with Camel. You'd be interested in the fabric8 framework which has recently integrated Openshift V3. (Fabric is the upstream project for the JBoss Fuse product)

Resources