| 'use strict'; | |
| const fs = require('fs') | |
| const http = require('http') | |
| const K8S_HOST = process.env['K8S_HOST'] || '10.100.0.1' | |
| const K8S_SECRET = process.env['K8S_SECRET'] || | |
| fs.readFileSync('/var/run/secrets/kubernetes.io/serviceaccount/token', 'utf-8') | |
| var req = http.request({ |
Useful kubectl commands not in the kubectl Cheat Sheet:
List all nodes and their external IP
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.addresses[?(@.type=="ExternalIP")].address}{"\n"}{end}'
List all running Pods and their IP
kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.status.phase=="Running")]}{.metadata.name}{"\t"}{.status.podIP}{"\n"}{end}'
| diff --git a/hack/local-up-cluster.sh b/hack/local-up-cluster.sh | |
| index 92b13eab89..9a85c463c5 100755 | |
| --- a/hack/local-up-cluster.sh | |
| +++ b/hack/local-up-cluster.sh | |
| @@ -22,12 +22,14 @@ KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. | |
| DOCKER_OPTS=${DOCKER_OPTS:-""} | |
| DOCKER=(docker ${DOCKER_OPTS}) | |
| DOCKERIZE_KUBELET=${DOCKERIZE_KUBELET:-""} | |
| +DOCKERIZED_KUBELET_IMAGE=${DOCKERIZED_KUBELET_IMAGE:-"gcr.io/google_containers/kubelet:local-up-cluster"} | |
| ALLOW_PRIVILEGED=${ALLOW_PRIVILEGED:-""} |
First and foremost, this is not a document on how to create an environment for developing applications targeting Kubernetes as its runtime. This document is to outline the steps required to create an environment for contributing to Kubernetes based on recently setting up both Linux and Mac development environments. This document is written as if you will be creating your development enivonment on OS X but just know that things are basically the same when on other OSes. Of course, the installation and configuration of these tools will changed based on which OS you're on, and possibly other things, but the gist is that in this guide when you see that tool X is required, you follow whatever steps to install tool X on your OS.
Recently at Apigee we have started using [Kubernetes][kubernetes] and while working on securing access to it, we learned a few things that we felt could be useful to other Kubernetes consumers. This post will discuss how we were able to use CloudFoundry's [UAA][uaa] as an [OpenID Connect Provider][oidc] for Kubernetes authentication. If you are not using UAA but you are using an [OAuth2][oauth2] provider for your authentication needs, stick around because this post could be useful to you as well.
Note: This post provides background on the process we took and how we successfully wired things up. If you do not care about this and just want to know the steps required to use UAA, and possibly other OAuth 2.0 providers, as an OIDC
When developing against/for Kubernetes, there are two major technologies that you need to have setup:
I have what I believe to be a very, very simple local development setup using these two technologies that I want to share with you. That being said, let's get started.
Imagine you are an API Management company and your business depends on your ability to be involved in the request/response lifecycle for HTTP-based API traffic. Also imagine that you've got a Kubernetes cluster that runs both your company's applications and even some client applications. This means when it comes to doing API Management for all necessary traffic, you need to be involved in the request/response lifecycle for targets running within Kubernetes for both requests originating outside the cluster and even some (if not all) requests originating within the cluster. To continue this conversation, let's establish some terminology:
| ;; Linum mode | |
| (global-linum-mode t) | |
| ;; Custom face/function to pad the line number in a way that does not conflict with whitespace-mode | |
| (defface linum-padding | |
| `((t :inherit 'linum | |
| :foreground ,(face-attribute 'linum :background nil t))) | |
| "Face for displaying leading zeroes for line numbers in display margin." | |
| :group 'linum) |
I was recently building a release of json-refs when I realized that the on disk file size was much larger than I expected. I use browserify to build my browser builds since I write json-refs for io.js/node.js. I started looking into the browserify build graph and that is when I noticed something interesting. Below are my findings.
Note: I realize I might be fixing a problem that does not matter and there could even be flaws in how json-refs is using browserify. I also realize that removing lodash is not something you can always do. This is just one of those cases where I wasn't using anything in lodash that wasn't in ES5 and I didn't need json-refs to work in pre-ES5 environments. This is not a hit on lodash, lodash is awesome. Please leave any feedback in the comments.
| -- This file resides at /Applications/Visual Studio Code.app/Contents/Resources/app/client/vs/workbench/contrib/debug/bin/TerminalHelper.scpt | |
| on run argv | |
| set working_dir to missing value | |
| set runtimeArgs to missing value | |
| set runtimeName to missing value | |
| set programArgs to missing value | |
| set env_vars to "" | |
| repeat with i from 1 to (count of argv) | |
| set a to (item i of argv) |