Automate SSL/TLS Certificates for Kubernetes and Istio with Cert Manager

It’s been a lot easier nowadays to turn on full site SSL/TLS encryption with an ACME issuer such as the popular non-profit Let’s Encrypt which I’ve started using it a few months ago.

However the free certificates from Let’s Encrypt are only valid for 90 days and I have been notified to renew them already. I could run the cert-bot again to semi-automatically renew the certificates in my Kubernetes cluster, but there’s Cert Manager which claims to be able to fully automate the whole process. I have to give it a try.

The Cert Manager essentially is a bundle of a Kubernetes Operator + CRDs(Custom Resource Definition), I followed the installation steps and installed Cert Manager easily with default settings. I chose to install with plain manifests because I tried the Helm charts first but it had some issues with my FluxCD pipeline. The plain manifests include the Cert Manager operator, CRDs and relevant Kubernetes resources such as Namespace and Service Account.

To use the same CloudFlare DNS challenge I used with cert-bot, I created a secret containing my CF API token:

$ k create secret generic cloudflare-api-token -n cert-manager --from-literal=api-key=eQ9Ls6...

Note: it will take a while for the Cert Manager to self-signed certificate for itself and get ready for requests.

Then I created a ClusterIssuer using CloudFlare DNS challenge to verify domain authority:

$ cat <<EOF |k apply -f -
kind: ClusterIssuer
  name: letsencrypt-issuer
    email: <my email>
    # this is the new CA chain
    preferredChain: "ISRG Root X1"
    # a secret name to save the private key
      name: letsencrypt-issuer
    - dns01:
          email: <my cloudflare email>
          # the secret to provide CloudFlare API Token
            name: cloudflare-api-token
            key: api-key

Then I checked if the ClusterIssuer is up:

$ k get clusterissuer
NAME                 READY   AGE
letsencrypt-issuer   True    1m

Almost done! The Cert Manager is now ready to manage certificates. I then created a Certificate resource to request and manage a new certificate:

$ cat <<EOF |k apply -f -
kind: Certificate
  name: wordpress-raynix
  # the cert will be in istio-system namespace to be used by istio
  namespace: istio-system
  # the secret to hold this cert
  secretName: wordpress-raynix-cert
  duration: 2160h # 90d
  renewBefore: 360h # 15d
  isCA: false
    algorithm: RSA
    size: 2048
    - server auth
    - client auth
  # put all DNS names in the cert here
  # refer to the ClusterIssuer
    name: letsencrypt-issuer
    kind: ClusterIssuer

Then it usually takes a minute or longer to actually see the secret in the newly created secret. The DNS challenge process is now run by the Cert Manager pod instead of the cert-bot.

As a last step, the new cert can be used in an Istio Gateway:

# this is the existing gateway
kind: Gateway
  name: wordpress-gateway
  namespace: wordpress-raynix
    istio: ingressgateway
  - hosts:
      name: https
      number: 443
      protocol: HTTPS
      # use the new cert in the new secret!
      credentialName: wordpress-raynix-cert
      mode: SIMPLE
  - hosts:
      name: http
      number: 80
      protocol: HTTP
      httpsRedirect: true

That’s it! Cert Manager claims that it can manage that cert and renew it accordingly, let’s see if that’s true 🙂

I Farmed Some Chia(XCH)

Chia is a relatively new crypto currency which can be ‘mined’ with hard disks. It’s advertised as a green crypto because hard disks consumes way less energy comparing to mining rigs with high end graphic cards.

I installed Chia on my Ubuntu Linux desktop computer because it has some vacant SATA ports that I can use for mining. The official instructions for installation is here.

In a nut shell, the mining power of Chia is determined how many plots do I have on disks and they are huge – about 100GB each. The process to generate plots is very IO intensive so it’s better be done on the fastest SSDs( and expect that SSD wears out quickly).

I used an old 512GB m.2 SSD as plotting disk and 2 x 8TB HDDs to store generated plots, eg.
/var/chia/tmp –> 512GB SSD
/var/chia/barn1 –> 8TB HDD
/var/chia/barn2 –> 8TB HDD

At the moment 512GB isn’t big enough to do 2 plotting processes in parallel, so I used a simple bash loop to keep generating plots in a single threaded manner, until the disk is full and then start it with next storage destination.

# this can be run in a screen to keep it running in background
while chia plots create -k 32 -n 1 -t /var/chia/tmp -d /var/chia/barn1 ; do sleep 1; done

The chia command to check farming status is

chia farm summary

With 2 x 8TB ( 14T usable) of storage, I have put 138 plots in them. It sounds like a lot at first but with a lot of people doing this plotting including some professional miners, the estimate time to be awarded has kept increasing, from 2 months to nearly a year now. But I’ve got some serious luck here as I was awarded 2 XCH coin the other day!

chia farm summary
Farming status: Farming
Total chia farmed: 2.0
User transaction fees: 0.0
Block rewards: 2.0
Last height farmed: 185xxx
Plot count: 138
Total size of plots: 13.660 TiB
Estimated network space: 15766.681 PiB
Expected time to win: 7 months and 2 weeks

A typical HDD will consume around 10W of power, and it can be set to spin down when idle. To my understanding that is necessary because the plots very very rarely get challenged which means most of time the drives do not have activity. Comparing this to the power consumption of those PoW(Proof of Work) crypto currencies such as BTC, ETH(for now), Chia(XCH) is indeed much much greener.

A warning here though, the plotting disk will wear heavily and might even get expired during the process.


Ethereum(Crypto) Mining with Nvidia 3070(Ampere) on Ubuntu 20.04 with Renewable Energy

Snagged a pair of RTX 3070 cards. With only 2 cards this is more like an experiment than an investment.

I’ve done Crypto mining before and since the price is now almost all time high I’ll do that again, but only with my solar energy. Mining with dirty coal power isn’t ethical any more as the climate change has accelerated in the past few years.

To start ETH mining here are some prerequisites:

  • Energy efficient video cards, in this case I got RTX 3070. 3060TI is also a good choice but it was sold out already
  • A desktop computer where you can attach multiple video cards to PCI express slots. But I’m not focusing hardware installation here, ie. not showing how to install the card and connect cables, etc.
  • My OS is Ubuntu 20.04 so I choose t-rex miner which has better support for Nvidia Ampere architecture. The releases can be found here

Here are the steps with which I set up t-rex miner on my Ubuntu 20.04 desktop:

# as root user
sudo -i
# install nvidia 460 driver for Ubuntu
apt install nvidia-driver-460
# install t-rex to /opt/t-rex
mkdir /opt/t-rex
tar -zxvf t-rex-0.19.9-linux-cuda11.1.tar.gz -C /opt/t-rex
# change ownership for security reasons
chown -R nobody:nogroup /opt/t-rex

Now in directory /opt/t-rex there are many shell script(.sh) files. I was using so I had a look at, it has:

./t-rex -a ethash -o stratum+tcp:// -u <ETH wallet address> -p x -w <worker name>

Since I’m proudly an experienced Linux user, I choose to create a systemd service out of that shell script:

# cat /etc/systemd/system/ethminer.service 
Description=Ethereum Miner

ExecStart=/opt/t-rex/t-rex -a ethash -o stratum+tcp:// -u <my ETH wallet address> -p "" -w <my worker name, can be hostname>



I choose us2 node as it’s geologically close to me. The user is set to nobody so it won’t cause harm to my system if it wants to. Then the service can be enabled and started with systemctl command:

# reload systemd as a new service is added
# following commands run as root user
systemctl daemon-reload
# enable the service so it starts automatically
systemctl enable ethminer
# start the service
systemctl start ethminer
# check status
systemctl status -l ethminer
# watch the logs
journalctl -f |grep t-rex
Jan 24 13:55:30 hostname t-rex[6621]: 20210124 13:55:30 Mining at, diff: 4.00 G

According to other miners online, the TDP of 3070 is better set as 50%(130W), because it can run hotter with higher wattage but won’t make it compute faster. Here’s how I use a cronjob to set TDP to 130W except when I’m playing a game(assuming I’ll stop the miner when playing some game on it).

EDIT: 115W is good enough.

# still as root user, as only root can use nvidia-smi command
# crontab -l
*/10 * * * * /bin/ps -C t-rex && /usr/bin/nvidia-smi -i 0 -pl 115 2>&1 >>/var/log/nvidia.log

This can be verified in t-rex ‘s logs

journalctl -f |grep t-rex
Jan 24 13:55:30 hostname t-rex[6621]: 20210124 13:55:30 GPU #0: Gigabyte RTX 3070 - 52.07 MH/s, [T:53C, P:129W, F:60%, E:404kH/W], 1370/1370 R:0%
# it's running at 129W and temperature is 53 degree and fan speed cruising at 60%

Regarding mining solely with solar energy, there can be 3 approaches:

  • Switch electricity supplier to the renewable-friendly ones such as Ember, so you can use solar energy generated by community and enjoy the low wholesale price and mine crypto when the sun shines. This requires the API access supplier so you know when the energy is from renewables and cheap
  • Install and use your own solar energy to mine crypto when the sun shines. This requires API access from your inverter so know when to start mining with enough solar energy.
  • Install solar and battery so it’s guaranteed to mine with your own solar energy until the battery runs flat of course

I’m going with the last option 🙂