A customer needs to access pods in legacy-fashioned style. We agreed that SFTP would be the method of choice as kubectl cp TUI is not an option for the customer and ftp for me neither.

I’d check how sftp-server actually works. It’s quite charming, that ssh execs the binary with STDIN/STDOUT connected. I added a little bit of configuration management and started a prototype written as shellscript for demonstrating and benchmarking.

Starting with statically linked binaries of su-exec  and sftp-server I added some glue code which processes Kubernetes pod events and derives configuration and credentials to access them via SFTP.

How does it work

  • Add a label sftp: enabledto a particular pod
  • The pod will be recreated and events regarding to its lifecycle catched by a pod called sftp-operator
  • The operator resolves the topmost resource (tr ) which created the pod (e.g.  its parent DaemonSet) and may create a secret holding the inbound sftp username, password and ssh private key, if there isn’t already one.
  • The real service pod named sftp-server picks up those secrets and creating a local user and a settings file for each of them
  • When connecting via sftp authentication is handled normally with public-key or password-based.  After a successful authentication, the sftp-server-container pushes su-exec  and sftp-server into the destination container and then runs them inside the container. The connection is forwarded via kubectl exec with STDIN and STDOUT  attached
  • Some simple benchmarks showed transfer-speeds which are fast enough for common ISP uplinks (e.g. xDSL, DOCSIS, or LTE) and defers routing to kubernetes

Source code, development, installation, bugs, and planned features

The source code is available at github. Eventually I’ll rewrite it in GO making operator and server more robust and resource friendly. In its current state this is a POC.

It can be installed via draft up.

At the moment the operator does not clean up secrets when the corresponding topmost resource is deleted. Healthchecks are missing, too. So there is quite some work left.

E.O.F.T. 17/18


the are ups and downs in life.

“Ice Call”

Just too fast.

“Follow The Fraser”⭐️

British Columbia is beautiful at winter and summer time.

“Into Twin Galaxies”⭐️⭐️

Seems to me Greenland is on my ‘must-visit’-list now!

“Dug Out”⭐️⭐️⭐️

The english men are still the most funny and real actors.


Really impressive skiing, but I like snowboarding.

“La Congenialita”

Always two there are no more no less a master and an apprentice.


Kubernetes Operators (Introduction)

Kubernetes Operators as introduced by CoreOS Inc. are admin-state-machines. Their purpose is to run some kind of software and maintain its operational state. It’s basically an admin in software.

A good set of requirements can be found here (“How can you create an Operator?”)

The very basic concept is grounded on custom resource definitions (CRD, since K8s 1.7, previously known as third party resources, TPR). They describe the to-operated service and its relation to other parts.

All resources the operator maintains should be actively watched. Each event should create one or more administrative task which then should be fed into a working queue to prevent race-conditions. There can be one queue per operated service or even more, depending on their operational impact (e.g. one for K8s-specific tasks like deployment, one for backup/restore and another one for user-management or something like that.)

Each task should check its prerequisites and postconditions and should be rather atomic. More advanced implementations may handle this inside the operator itself (e.g. block other queues during critical an operation).

There will be a PoC for, I think, MariaDB here soon.