sjenning

#!/bin/bash

set -eux

HC_NAMESPACE=sjenning
HC_NAME=sjenning-mgmt
NP_NAME=sjenning-mgmt-us-east-1a

IGNITION_ROUTE=$(oc get route -n $HC_NAMESPACE-$HC_NAME ignition-server -ojsonpath='{.status.ingress[0].host}')
NODEPOOL_TOKEN_SECERT=$(oc get secret | cut -f1 -d' ' | grep ^token-$NP_NAME)

sjenning

{
  "kind": "AuthenticationConfiguration",
  "apiVersion": "apiserver.k8s.io/v1alpha1",
  "jwt": [
    {
      "issuer": {
        "url": "https://login.microsoftonline.com/fa5d3dd8-b8ec-4407-a55c-ced639f1c8c5/v2.0",
        "audiences": [
          "fdd45692-2aa8-4c30-b472-b86b84e5ed1d"
        ],

sjenning

apiVersion: v1
kind: BuildConfig
metadata:
  name: nodejs-ex-pipeline
  labels:
    app: nodejs-ex
  annotations:
    pipeline.alpha.openshift.io/uses: '[{"name": "nodejs-ex", "namespace": "", "kind": "DeploymentConfig"}]'
spec:
  triggers:

sjenning

Linux Hugepages

Hugepages are a hardware feature designed to reduce pressure on the translation lookaside buffer (TLB) for applications that operate on large contiguous memory regions.

Take a program that operates on a large 2MB internal structure as an example. If the program accesses that space in such a way that one byte in each regular 4k page is accessed, 2M/4k = 512 TLB entries are needed. Each TLB miss at the hardware level requires and interrupt and kernel intervention to resolve. However, if the allocation is backed by a 2M hugepage by mmap()ing with MAP_HUGETLB, only 1 TLB entry is required.

On x86_64, there are two hugepage sizes: 2MB and 1G. 1G hugepages are also called gigantic pages. 1G must be enabled on kernel boot line with hugepagesz=1G. Hugeages, especially 1G ones, should to be allocated early before memory fragments (i.e. at/near boot time) to increase the likelihood that they can be allocated successfully with minimal memory migration (i.e. defreg) required

sjenning

package main

import (
	"bufio"
	"encoding/json"
	"log"
	"os"
	"strings"
)

sjenning

hypershift create cluster aws --endpointAccess=PublicAndPrivate --external-dns-domain=service.ci.hypershift.devcluster.openshift.com

  services:
  - service: APIServer
    servicePublishingStrategy:
      route:
        hostname: api-sjenning-guest.service.ci.hypershift.devcluster.openshift.com
      type: Route
  - service: OAuthServer

sjenning

apiVersion: v1
kind: Namespace
metadata:
  name: sjenning
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: hypershift
  namespace: sjenning

sjenning

#!/bin/bash

set -eux

NODEPOOL=${NODEPOOL:-'example'}
SECRET=$(oc get secret | grep ^token-${NODEPOOL} | cut -f1 -d' ')
TOKEN=$(oc get secret ${SECRET} -ojsonpath='{.data.token}')
IGNPOD=$(oc get pod | grep ignition-server | cut -f1 -d' ')
oc rsh ${IGNPOD} /bin/curl --insecure -H "Accept: application/vnd.coreos.ignition+json; version=3.2.0" -H "Authorization: Bearer ${TOKEN}" -k https://127.0.0.1:9090/ignition | jq > ${NODEPOOL}.ign

sjenning

Deploying AWS Private Cluster with Hypershift

Create a hypershift-operator IAM user in the management account

NOTE: An IAM Role can also be used but this is the simpliest method to document

Create the policy document

# cat << EOF >> policy.json
{

sjenning

---
apiVersion: v1
kind: Secret
metadata:
  name: heketi-secret
  namespace: default
data:
  key: YWRtaW5zZWNyZXQ=
type: kubernetes.io/glusterfs
---