Single-node Kubernetes deployment

[Edited]

In order to test k8s you can always deploy a single-node setup locally using minikube, however it is a bit limited if you want to test interactions that require your services to be externally accessible from a mobile or web front-end.

While I wrote this post long time ago this is still a need that I come across when doing training or testing small projects.

I have updated my script to work with kubeadm and Ubuntu 16.04+, this should also help you deploying the lastest k8s version. While the old method should still work, this would be simpler.

Also, we took this concept to production in Bitnami. We have created a kubernetes sandbox that comes with all bells and whistles. You can run this in most mayor public cloud providers.

Look forward to your feedback!

;old-post ———————————

For this reason, I created a basic k8s setup for a Core OS single node in Azure using https://coreos.com/kubernetes/docs/latest/getting-started.html . Once I did this, I decided to automate its deployment via script.

It requires a Core OS instance running, then connect to it and:

git clone https://github.com/vtuson/k8single.git k8
cd k8
./kubeform.sh [myip-address] –> ip associated to eth, you can find it using ifconfig

This will deploy k8 into a single node, it sets up kubectl in the node and deploys skydns add on.

It also includes a busybox node file that can be deployed by:

kubectl create -f files/busybox

This might come useful to debug issues with the set up. To execute commands in busybox run:
kubectl exec busybox — [command]

The script and config files can be access at https://github.com/vtuson/k8single

If you hit any issues while deploying k8s in a single node a few things worth checking are:


sudo systemctl status etcd
sudo systemctl status flanneld
sudo systemctl status docker

Also it is worth checking what docker containers are running and if necessarily check the logs

docker ps -a
docker logs [container-id]

Deploying Heapster to Kubernetes

I recently blogged about deploying kubernetes in Azure.  After doing so, I wanted to keep an eye on usage of the instances and pods.

Kubernetes recommends Heapster as a cluster aggregator to monitor usage of nodes and pods. Very handy if you are deploying in Google Compute (GCE) as it has a pre-build dashboard to hook it to.

Heapster runs on each node, collects statistics of the system and pods which pipes to a storage backend of your choice. A very handy part of Heapster is that export user labels as part of metadata, which I believe can be used to create custom reports on services across nodes.

monitoring-architecture

If you are not using GCE or just don’t want to use their dashboard, you can deploy a combo of InfluxDB and Grafana as a DIY solution. While this seems promising the documentation, as usual, is pretty short on details..

Start by using the “detailed” guide to deploy the add on, which basically consists of:

**wait! don’t run this yet until you finished reading article**

git clone https://github.com/kubernetes/heapster.git
cd heapster
kubectl create -f deploy/kube-config/influxdb/

These steps exposes Grafana and InfluxDB via the api proxy, you can see them in your deployment by doing:

kubectl cluster-info

This didn’t quite work for me, and while rummaging in the yamls, I found out that this is not really the recommended configuration for live deployments anyway…

So here is what I did:

  1. Remove env variables influxdb-grafana-controller.yaml
  2. Expose service as NodePort or LoadBalancer depends of your preference in grafana-service.yaml. E.g. Under spec section add: type: NodePort
  3. Now run >kubectl create -f deploy/kube-config/influxdb/

You can see the expose port for Grafana by running:
kubectl --namespace=kube-system describe service grafana-service

In this deployment, all the services, rc and pods are added under the kube-system namespace, so remember to add the –namespace flag to your kubectl commands.

Now you should be able to access Grafana on any external ip or dns on the port listed under NodePort. But I was not able to see any data.

Login to Grafana as admin (admin:admin by default), select DataSources>influxdb-datasource and test the connection. The connection is set up as http://monitoring-influxdb:8086, this failed for me.

Since InfluxDB and Grafana are both in the same pod, you can use localhost to access the service. So change the url to http://localhost:8086, save and test the connection again. This worked for me and a minute later I was getting realtime data from nodes and pods.

Proxying Grafana

I run an nginx proxy that terminates https  requests for my domain and a created a https://mydomain/monitoring/ end point as part of it.

For some reason, Grafana needs to know the root-url format that is being accessed from to work properly. This is defined in a config file.. while you could change it and rebuild the image, I preferred to override it via an enviroment variable in the influxdb-grafana-controller.yaml kubernetes file. Just add to the Grafana container section:

env:
- name: GF_SERVER_ROOT_URL
value: "%(protocol)s://%(domain)s:%(http_port)s/monitoring"

You can do this with any of the Grafana config values, which allows you to reuse the official Grafana docker image straight from the main registry.

Deploying Kubernetes on Azure

I recently looked to do my first live deployment of kubernetes, after having playing succesfully with minikube.

When trying to deploy kubernetes in public cloud, there is a couple of base options. You could start from scratch or use one of the turnkey solutions.

You have two turnkey solutions fro Azure, Fannel or Weave based. Basically these are two different networking solutions, but the actual turnkey solutions differ more than just the networking layer. I tried both and had issues with both, yeay!! However, I liked the fannel solution over Weave’s straight away. Flannel’s seems to be able to configure and used Azure better. For example, It uses a VM scale sets for the slave nodes, and configures external ips and security groups. This might be because the Flannel solution is sponsored by Microsoft, so I ended up focusing on it over Weave’s.

The documentation is not bad, but a bit short on some basic details. I  did the deployment in both Ubuntu 14.04 and OSX10 and worked in both. The documetation details jq and docker as the main dependencies. I found issues with older versions of jq that are part of the 14.04 Ubuntu archive, so make sure to install the lastest version from the jq website.

Ultimately, Kube-up.sh seems to be a basic configuration wrapper around azkube, a link to it is burried at the end of the kubernetes doc. Cole Mickens is the main developer for azkube and the turnkey soultion. While looking around his github profile, I found this very useful link on the status of support for Kubernetes in Azure. I would hope this eventually lands in the main kubernetes doc site.

As part of the first install instructions, you will need to provide the subscription and tenant id. I found the subscription id easily enough from the web console, but the tenant id was a bit more elusive. Altough the tenant id is not required for installations of 1.3, the script failed to execute without it. It seems like the best way to find it is the Azure cli tool, which you can get from node.js


npm install azure
azure login
azure account show

This will give you ll the details that you need to set it up. You can then just go ahead or you can edit deatils in  cluster/azure/config-default.sh

You might want to edit the number of VMs that the operation will create. Once you run kube-up.sh, you should hopefully get a working kubernetes deployment.

If for any reason, you would like to change the version to be install, you will need to edit the file called “version” under the kubernetes folder setup by the first installation step.

The deployment comes with a ‘utils’ script that makes it very simple do a few things. One is to copy the ssh key that will give you access to the slaves to the master.

$ ./util.sh copykey

From the master, you just need to access the internal ip using the “kube” username and specify your private key for authentication.

Next, I would suggest to configure your local kubectl and deploy the SkyDNS addon. You will really need this to easly access services.

$ ./util.sh configure-kubectl
$ kubectl create -f https://raw.githubusercontent.com/colemickens/azkube/v0.0.5/templates/coreos/addons/skydns.yaml

And that is it, if you run kubectl get nodes, you will be able to see the master and the slaves.

Since Azure does not have direct integretion for loadbalancer, any services that you expose you will need to configure with a self-deployed solution. But it seems that version 1.4  ofKubernetes is comming with equivalent support for Azure that the current versions boast for  AWS and Co.

Standing up a private Docker Registry

First of all, I wanted to recommend the following recipe from Digital Ocean on how to rollout your own Docker Registry in Ubuntu 14.04. As with most of their stuff, it is super easy to follow.

I also wanted to share a small improvement on the recipe to include a UI front-end to the registry.

Once you have completed the recipe and have a repository secured and running, you extend your docker-compose file to look like this:

nginx:
 image: "nginx:1.9"
 ports:
 - 443:443
 - 8080:8080
 links:
 - registry:registry
 - web:web
 volumes:
 - ./nginx/:/etc/nginx/conf.d:ro

web:
 image: hyper/docker-registry-web
 ports:
 - 8000:8080
 links:
 - registry
 environment:
 REGISTRY_HOST: registry

registry:
 image: registry:2
 ports:
 - 127.0.0.1:5000:5000
 environment:
 REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
 volumes:
 - ./data:/data

You will also need to include a configuration file for web in the nginx folder.

file: ~/docker-registry/nginx/web.conf

upstream docker-registry-web {
 server web:8080;
 }

server {
 listen 8080;
 server_name [YOUR DOMAIN];

# SSL
 ssl on;
 ssl_certificate /etc/nginx/conf.d/domain.crt;
 ssl_certificate_key /etc/nginx/conf.d/domain.key;

location / {

# To add basic authentication to v2 use auth_basic setting plus add_header
 auth_basic "registry.localhost";
 auth_basic_user_file /etc/nginx/conf.d/registry.password;

proxy_pass http://docker-registry-web;
 proxy_set_header Host $http_host; # required for docker client's sake
 proxy_set_header X-Real-IP $remote_addr; # pass on real client's IP
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_read_timeout 900;
 }
 }

docker-compose up and you should be able to have a ssl secured UI frontend in port 8080 (https://yourdomain:8080/)
If you have any improvement tips I am all ears!

PiGlow API: one small snap for humanity…

My first steps into snappifying, I have publish a RestApi for PiGlow (glowapi 0.1.2). I though it might be a good first step and mildly useful for people wanting to set up build notifications, twitter mentions, whatever you fancy!

You can find it in the webdm store…
Code is here: https://code.launchpad.net/~vtuson/+junk/glowapi

And here is how it works:
PiGlow Api exposes PiGlow in your board port 8000, so you can easy accessing by POST in port 8000.

remeber to do the hardware assign, something like: sudo snappy hw-assign glowapi.vtuson /dev/i2c-1

API calls , method POST:

v1/flare
turns all the leds on to max brightness
v1/on
turns all the leds on to med brigthness
v1/clear
turns off all leds
v1/legs/:id
turns all the leds in a leg (:id) to a given brightness
(if not specify it uses a default setting)
parms: intensity , range 0 to 1
eg: http://localhost:8000/v1/legs/1?intensity=0.3
v1/legs/:id/colors/:colid
turns on one led (colid) in a leg (:id) to a given brightness
(if not specify it uses a default setting)
parms: intensity , range 0 to 1
eg: http://localhost:8000/v1/legs/1/colors/green?intensity=0.3
v1/colors/:colid
turn on all leds for a color across all legs
if not specify it uses a default setting)
parms: intensity , range 0 to 1
eg: http://localhost:8000/v1/colors/green?intensity=0.3

ID ranges
legs range : 0 – 2
colors:
green
white
blue
yellow
orange
red

The fastest scope in the store… or Formula one in 5 minutes with Twitter

I recently blogged about making a scopes in 5 minutes using youtube. I have seen also a fair amount of new scopes being created using RSS. By far, my favourite way to use scopecreator is Twitter.

If you want to check a few examples, I have published previously twitter-based scopes like breaking news, la liga and a few others. Today, I give you Formula One:

f1 f1_2 f1_3

The interesting thing about twitter is that many brands upload minute by minute new updates, which make a really good source for scopes.

To create a Formula One scope,I started by going to twitter and creating a list under my scope account (you can use your personal account). The list contains several relevant “official” Formula One accounts.  Using Twitter, I can then update the sources by adding and removing accounts from the list without the user needing to download an update for the scope.

Again, it took me about 5 min to get a working version of the scope.  Here is what needed to do:

  • First, we followed Chris’ instructions to install the scope creator tool.
  • Once we had it set up on my laptop, I run:
    scopecreator create twitter vtuson f1
    cd f1
  • Next, I configured the scope. The configuration is done in a json file called manifest.json. This file describes the content of what you will publish later to the store. You need to care about: “title”, “description”, “version” and “mantainer”. The rest are values populated by the tool:
    scopecreator edit config
    {
    "description": "Formula One scope",
    "framework": "ubuntu-sdk-14.10",
    "architecture": "armhf",
    "hooks": {
    "f1": {
    "scope": "f1",
    "apparmor": "scope-security.json"
    }
    },
    "icon": "icon",
    "maintainer": "Your Name <yourname@packagedomain>",
    "name": "f1.vtuson",
    "title": "Formula One",
    "version": "0.2"
    }
  • The following step was to set up the branding: Easy! Branding is define on an .ini file. “Display name” will be the name listed on the “manage” window once installed, and also will be the title of your scope if you don’t use a “PageHeader.Logo”. the [Appearance] section describes the colours and logos to use when banding a scope.
    scopecreator edit branding
    [ScopeConfig]
    ScopeRunner=./f1.vtuson_f1 --runtime %R --scope %S
    DisplayName=Formula One
    Description=This is an Ubuntu search plugin that enables information from Yelp $
    Author=Canonical Ltd.
    Art=
    Icon=images/icon.png
    SearchHint=Search
    [Appearance]
    PageHeader.Background=color:///#D51318
    PageHeader.ForegroundColor=#FFFFFF
    PreviewButtonColor=#D51318
  • The final part is to define the departments (drop down menu) for the scope. This is also a json file and it is unique the twitter scope template. You can either use “list” or “account” (or both) as departments.  The id is the twitter handle for the list or the account. For lists you will need to specify in the configuration section what account holds the list. As I defined a single entry, the formula one scope will have no drop down menu.
    scopecreator edit channels
    {
    “departments”: [
    {
    “name”:”Formula One”,
    “type”:”list”,
    “id”:”f1″
    }
    ],
    “configuration”: {
    “list-account”:”canonical_scope”,
    “openontwitter”:”See in Twitter”,
    “openlink”:”Open”,
    “retweet”:”Retweet”,
    “favorite”: “Favourite”,
    “reply”:”Reply”
    }
    }

After this, the only thing left to do is replace the placeholder icon, with a relevant logo:
~/f1/f1/images/logo.png
And build, check and publish the scope:
scopecreator build

This last command generates the click file that you need to upload to the store. If you have a device (for example a Nexus4 or an emulator ), it can also install it so you can test it. If you get any issues getting the scope to run, you might want to check your json files on http://jsonlint.com/. It is a great web tool that will help you make sure your json doc is ship shaped!

It is super simple to create a scope for a twitter list! so what are you going to create next?

uBrick – a Lego Scope

Just a quick note to tell you that I have published a new scope called uBrick that brings you the awesomeness of Lego, as a catalogue powered by brickset.com, directly to your Ubuntu phone home screen.

I wrote the scope in Go cause I find it easier to work with for a quick scope ( took about 8 hours with interruptions over 2 days to write this scope).  The scope is now available at the store, just search for uBrick.

Here are some pics:

lego1lego2lego3 lego4

Also I have to congratulate the folks at Brickset for a very nice API, even if it is using SOAP 🙂

Ubuntu Touch: Building and testing a QML extension

Hi,

I found myself trying to build a QML Ubuntu Touch app project that includes a qml c++ extension and I found that I some how stumble a bit along the way. So, here are some of my notes on how I got it done. Hope that helps.

Creating the project.

Using QtCreator, create a new project and select – QML Extension Library + Tabbed Touch.  I found that it was easier to change the QML side of things than start with an extension and then add the whole project structure.

Build and Run your project locally

In QtCreator click on projects.  In Build, I set up the build path as my project root path. In run,  the executable is “/usr/bin/qmlscene” (make sure there is no spaces trailing) and then Arguments is set to “-I  ../backend/modules $@ yourapp.qml”, with a working directory of “projectroot/app”

Now if you try to run your project it should build it locally and run your app. After that you are on a roll.

Build on target device

Click Ctrl+f11 should install the platform developer tools in your device. However, I how found that this lately does not work.

Instead from the terminal:

first we will need to make the image in your device writeable:
adb shell touch /userdata/.writable_image  --> and reboot the phone.
then:
cd /usr/share/qtcreator/ubuntu/scripts
adb devices
./device_developertools_install <device_id>

Now you are ready to build, so back to QtCreator:

Build>Ubuntu>Build Application on Device

This should build the application with only some test problems, but the main binaries would be created. To package your app you will need to get

/home/phablet/dev_tmp/<yourapp>/backend/modules/lib<yourlib>.so

Creating a click package

create a manifest standard manifest file. Manifest.json

{
"description": "your text",
"framework": "ubuntu-sdk-13.10",
"hooks": {
"yourappname": {
"apparmor": "yourappname.json",
"desktop": "yourappname.desktop"
}
},
"maintainer": "your name<yourname@yourmail.com>",
"name": "com.ubuntu.developer.yourname.yourappname",
"title": "yourappname",
"version": "0.1",
"architecture": "armhf"
}

You will also need a yourapp.desktop file:

[Desktop Entry]
Name=yourappname
Comment=description
Exec=qmlscene -I plugin $@ yourapp.qml
Icon=icon.png
Terminal=false
Type=Application
X-Ubuntu-Touch=true

Note that Exec= has a -I plugin part to it. This is very important, will see later.

Now yourapp.json file that contains your confinement profile:

{
"policy_groups": [
"networking"
],
"policy_version": 1
}

Now time to setup a folder with all this stuff, not that the plugin folder is going to contain your lib which your are importing with -I option on the desktop file:
myproject>
-./click/
--icon.png
--manifest.json
--yourapp.json
--yourapp.desktop
--./plugin/
---./yourlib/
----lib(yourlibname).so
----qmldir

Now you are ready to build from your project root folder:
click build ./click

This should create a .click file in your project folder.

Installing in your device

adb pull your.click /home/phablet/
adb shell
su phablet
cd ~
pkcon -p install-local your.click

This should be enough, but sometimes I find that you need to restart unity:
pkill unity8 (you might need sudo)

Living on the edge: The campaign target

It has been over 2 months since the Ubuntu Edge campaign concluded, and I haven’t really blogged about it.  I must say, driving something like this was great fun but also a fully immersive 24-7 experience. For that reason, I wanted some time to pass before write some conclusions about it.

One of the things that made the Ubuntu Edge campaign to stand out from previous crowd funding projects was the target: $32 Million. Other successful projects (I will focus only on products) had much lower targets (~$100K). So, why was this the case?

If your company has already raised capital via “standard” funding routes or you are actively pursuing it, a successful crowd funding campaign will reduce the overall amount of equity you have to give away. It can also attract that elusive VC investment.  In this situation, your objectives are:

  • Proof the product viability 
  • Remove doubts from future investors minds
  • ensure your campaign and your product are perceived as a successes

An early achievement of your campaign target will tick all these boxes. A “sold out” effect in the first week will increase the confidence of future pledgers and investors. In that case, a campaign target of $100K can be the magic number for you. 

In the other hand, if crowd funding is your only or main avenue to finance your product, your objectives will be slightly different. These were ours:

  • Proof the product viability
  • Finance product design and factory tooling
  • Finance a fix/minimum production run
  • Market validation

An early achievement of your target is still desirable, but your main worry will be to raise enough money via the campaign to deliver on your promises to the pledgers.

Although we raised over $12 Million, we did not reach our intended target. The Ubuntu Edge was a unique proposition that was build on the premise of delivering the latest cutting edge technology.  Unfortunately, this meant that we could not pursue what I think is a better approach for 100% crowd funded products: a multi-campaign project.

In a crowd funding campaign, people contribute for different reasons:

  • The Angels: Angels are interested in supporting new innovation. They might not even necessarily want to own your product, but they appreciate the disruption you are trying to bring to the market.  For these reason, they are willing to contributed from a little as $1 to thousands of dollars to see your project succeed.
  • The Extended Team: These are passionate individuals that understand your product concept and they want one! Not only they are willing to part with some money to get one, but they are also willing to contribute their own time and energy to make your product successful. They are a great source of professional and amateur resources. The contributions we got for Ubuntu Edge ranged from advise on how to run the campaign by serious knowledge people, to PR (T-shirt designs, websites, ads) to product design.
  • The Pragmatists:  Your product might look good, but your project might just be too risky. Crowd funding projects are developing a bit of a reputation for shipping late or even worst, never happening.  Pragmatist might be put off from contributing to your project is the perceived risk is too high.  Some key questions they would like answer to are: Who are you? What is your proven record? Do you have a proto-type working?  Do you have suppliers ready to go? but they all ultimately boil down to one: Can I trust you?
  • The Shoppers: Although, it should be clear to everyone that crowd funding is not the same that shopping in Amazon, similar motivations may apply.  Shoppers will compare backing your project with buying a similar product online. Things they will care about: Are you offering a good deal? How long will it take for me get the product? What warranties do you offer?.

Pragmatists and shoppers form the bulk of the backer community out in the wild. If you are just getting started with your product development, you might find that addressing the concerns of pragmatists and shoppers is just not possible. In that case, financing your product development via multiple crowd funding projects might be a better option.

Target your first project to attract angels and extended-team. Set a campaign target that will allow you to build a prototype and start seriously talking to suppliers. Build up your credibility by delivering the first project on time.

For your second project, you will have had reduced the risk and the time to product delivery substantially. You might now be able to raise the rest of the funding or your might need a couple more iterations. Here is how the people at +Pool are doing it:

  1. First project
  2. second project

 

+POOL