There is such a moment when a client with a very slow Internet and an old slow system, when opening a web page, it shows some defects, which are not visible on fast machines because a person does not have time to notice them. How can you simulate such a slow loading to see such defects in manual web testing?

Figured out a way, but it might not be the most elegant.

First, we render the chart locally and then use tree to print out the subdirectories with their sizes in a human-readable format.

helm template . --output-dir=file-size-test
tree --du -h file-size-test

This produces an output similar to:

[340M]  testing123
└── [340M]  chart_name
    ├── [ 91K]  charts
    │   ├── [ 58K]  sub-chart
    │   │   └── [ 58K]  templates
    │   │       ├── [1.3K]  deployment.yaml
    │   │       ├── [ 411]  config.yaml
    │   │       ├── [ 579]  service.yaml
    │   │       └── [ 359]  serviceaccount.yaml

    └── [340M]  templates
        ├── [ 68M]  deployment.yaml
        ├── [136M]  config1.yaml
        ├── [136M]  config2.yaml
        └── [1.3K]  ingress.yaml

So now I've found that the issue seems to be the massive config1.yaml and config2.yaml files.

While this doesn't exactly answer the question of how to find which have been ignored, it at least points to which might not have been ignored.

I am following a tutorial to set Kubernetes with an ingress managed service. The cluster is,

• 1 controller
• 2 worker Kubernetes cluster
• kubeadm built
• running Kubernetes v1.25.3 (latest at the time of writing)
• running weave-net
• running ingress-nginx
• EC2, not EKS

I am just expecting to see the nginx default page when I access the AWS Application Load Balancer, ALB, DNS name - nothing fancy.

I first used this helm chart to deploy nginx-ingress, as per the " https://kubernetes.github.io/ingress-nginx/deploy/#quick-start " docs.

helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

I then deployed the following in the default namespace.

ingress.yaml

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: ***alb***.elb.amazonaws.com
    http:
      paths:
      - backend:
          service:
            name: nginx-service
            port:
              number: 8080
        path: /
        pathType: Exact

service.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
    svc: test-nginx
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80

deployment.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
    svc: test-nginx
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80

k get svc -A

NAMESPACE       NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
default         demo                                 ClusterIP      *****                    80/TCP                       7h53m
default         kubernetes                           ClusterIP      *****                    443/TCP                      2d6h
default         nginx-service                        ClusterIP      *****                    8080/TCP                     26h
ingress-nginx   ingress-nginx-controller             LoadBalancer   *****                 80:32573/TCP,443:32512/TCP   35h
ingress-nginx   ingress-nginx-controller-admission   ClusterIP      *****                    443/TCP                      35h
kube-system     kube-dns                             ClusterIP      *****                    53/UDP,53/TCP,9153/TCP       2d6h

Two AWS security groups are in effect, one for the controller and one for the workers. Both these security groups have ports 6783 - 6784 open as required by ingress-nginx.

The ALB is set with the following.

• same Availability Zones as the worker nodes
• default (open) security group
• Listener protocol:port = HTTP:80
• same VPC as the EC2 instances.
• Scheme = internet-facing
• IP address type = ipv4

The target group for this ALB is set as follows.

• both worker nodes
• Protocol : Port = HTTP: 32573
• Protocol version = HTTP1
• same VPC as the EC2 instances.
• Health path = /

On the assumption that the target group would block traffic to "unhealthy" nodes, I previously deployed a separate service directly on a different NodePort, rather than via Ingress, to fudge the health check to Healthy, but this made no difference.

I have,

• double checked that I have followed the steps in the tutorial exactly
• looked through the logs but cannot find anything that would suggest an error.
• terminated all the pods.
• restarted the nodes.

When I run

k logs ingress-nginx-controller-***** -n ingress-nginx

It returns

-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.4.0
  Build:         50be2bf95fd1ef480420e2aa1d6c5c7c138c95ea
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.19.10

W1021 13:49:00.607448       7 client_config.go:617] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.

I1021 13:49:00.607678       7 main.go:209] "Creating API client" host="https://10.96.0.1:443"

I1021 13:49:00.613511       7 main.go:253] "Running in Kubernetes cluster" major="1" minor="25" git="v1.25.3" state="clean" commit="434bfd82814af038ad94d62ebe59b133fcb50506" platform="linux/amd64"

I1021 13:49:00.776507       7 main.go:104] "SSL fake certificate created" file="/etc/ingress-controller/ssl/default-fake-certificate.pem"

I1021 13:49:00.788407       7 ssl.go:533] "loading tls certificate" path="/usr/local/certificates/cert" key="/usr/local/certificates/key"

I1021 13:49:00.807812       7 nginx.go:260] "Starting NGINX Ingress controller"

I1021 13:49:00.820423       7 event.go:285] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"ingress-nginx-controller", UID:"f4d537f7-2b89-4fe5-a9ed-c064533b08a2", APIVersion:"v1", ResourceVersion:"96138", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/ingress-nginx-controller

I1021 13:49:01.910567       7 store.go:430] "Found valid IngressClass" ingress="default/my-app-ingress" ingressclass="nginx"

I1021 13:49:01.910942       7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"my-app-ingress", UID:"9111168a-9dc8-4cf8-a0f6-fe871c3ada61", APIVersion:"networking.k8s.io/v1", ResourceVersion:"245885", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync

I1021 13:49:02.009443       7 nginx.go:303] "Starting NGINX process"

I1021 13:49:02.009750       7 leaderelection.go:248] attempting to acquire leader lease ingress-nginx/ingress-controller-leader...

I1021 13:49:02.010156       7 nginx.go:323] "Starting validation webhook" address=":8443" certPath="/usr/local/certificates/cert" keyPath="/usr/local/certificates/key"

I1021 13:49:02.010553       7 controller.go:168] "Configuration changes detected, backend reload required"

I1021 13:49:02.015673       7 status.go:84] "New leader elected" identity="ingress-nginx-controller-567c84f6f-8s5zv"

I1021 13:49:02.081076       7 controller.go:185] "Backend successfully reloaded"

I1021 13:49:02.081398       7 controller.go:196] "Initial sync, sleeping for 1 second"

I1021 13:49:02.081913       7 event.go:285] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-567c84f6f-52k47", UID:"fa2b26ad-0594-4e43-927a-11a9def12467", APIVersion:"v1", ResourceVersion:"249556", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration

I1021 13:49:43.652768       7 leaderelection.go:258] successfully acquired lease ingress-nginx/ingress-controller-leader

I1021 13:49:43.652910       7 status.go:84] "New leader elected" identity="ingress-nginx-controller-567c84f6f-52k47"

W1021 14:22:31.247404       7 controller.go:1112] Service "default/demo" does not have any active Endpoint.

I1021 14:22:31.283535       7 admission.go:149] processed ingress via admission controller {testedIngressLength:2 testedIngressTime:0.036s renderingIngressLength:2 renderingIngressTime:0s admissionTime:25.8kBs testedConfigurationSize:0.036}

I1021 14:22:31.283727       7 main.go:100] "successfully validated configuration, accepting" ingress="default/demo"

I1021 14:22:31.289380       7 store.go:430] "Found valid IngressClass" ingress="default/demo" ingressclass="nginx"

I1021 14:22:31.289790       7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"demo", UID:"50962ac3-d7f1-45bc-8e73-7baf6337331b", APIVersion:"networking.k8s.io/v1", ResourceVersion:"252977", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync

W1021 14:22:31.290058       7 controller.go:1112] Service "default/demo" does not have any active Endpoint.

I1021 14:22:31.290210       7 controller.go:168] "Configuration changes detected, backend reload required"

I1021 14:22:31.366582       7 controller.go:185] "Backend successfully reloaded"

I1021 14:22:31.367273       7 event.go:285] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-567c84f6f-52k47", UID:"fa2b26ad-0594-4e43-927a-11a9def12467", APIVersion:"v1", ResourceVersion:"249556", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration

I1021 14:25:34.757766       7 controller.go:168] "Configuration changes detected, backend reload required"

I1021 14:25:34.827908       7 controller.go:185] "Backend successfully reloaded"

I1021 14:25:34.828291       7 event.go:285] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-567c84f6f-52k47", UID:"fa2b26ad-0594-4e43-927a-11a9def12467", APIVersion:"v1", ResourceVersion:"249556", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration

I1021 14:25:41.191636       7 admission.go:149] processed ingress via admission controller {testedIngressLength:1 testedIngressTime:0.036s renderingIngressLength:1 renderingIngressTime:0s admissionTime:22.1kBs testedConfigurationSize:0.036}

I1021 14:25:41.191800       7 main.go:100] "successfully validated configuration, accepting" ingress="default/my-app-ingress"

I1021 14:25:41.195876       7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"my-app-ingress", UID:"9111168a-9dc8-4cf8-a0f6-fe871c3ada61", APIVersion:"networking.k8s.io/v1", ResourceVersion:"253276", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync

I1021 20:40:45.084934       7 admission.go:149] processed ingress via admission controller {testedIngressLength:1 testedIngressTime:0.049s renderingIngressLength:1 renderingIngressTime:0s admissionTime:22.1kBs testedConfigurationSize:0.049}

I1021 20:40:45.085124       7 main.go:100] "successfully validated configuration, accepting" ingress="default/my-app-ingress"

I1021 20:40:45.088698       7 controller.go:168] "Configuration changes detected, backend reload required"

I1021 20:40:45.088779       7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"my-app-ingress", UID:"9111168a-9dc8-4cf8-a0f6-fe871c3ada61", APIVersion:"networking.k8s.io/v1", ResourceVersion:"287850", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync

I1021 20:40:45.183140       7 controller.go:185] "Backend successfully reloaded"

I1021 20:40:45.184054       7 event.go:285] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-567c84f6f-52k47", UID:"fa2b26ad-0594-4e43-927a-11a9def12467", APIVersion:"v1", ResourceVersion:"249556", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration

I notice that the following appears in the logs for the weave-net pods.

k logs weave-net-*w1* -n kube-system

Where *w1* is the pod running on worker node1.

INFO: 2022/10/21 13:49:27.195158 ->[*controller*:6783] error during connection attempt: dial tcp :0->*controller*:6783: connect: connection refused

Where *controller* is the IP address of the control node.

After all of the above, when I navigate to the ALB DNS address, I just get,

internal error - server connection terminated

This is clearly a PEBKAC, but what am I missing?

1. After launching a EC2 instance, do I have to always log into the instance for the first time, by SSH with the default user for the image of the instance? Or is it possible to first time log into a new instance, by a user not the default one?

2. When launching a EC2 instance using either AWS CLI2 or Terraform, is it possible to specify a user to create and its authentication method (by specifying a EC2 private/public key pair created for AWS already), so that I will have a non-default user to log into the instance for the first time? Or creating a non-default user for a new instance can only be done under the default user's login session?

Thanks.

From the documentation:

https://istio.io/latest/docs/reference/config/telemetry/#Tracing https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/

Istio leverages Envoy’s distributed tracing feature to provide tracing integration out of the box. Specifically, Istio provides options to install various tracing backend and configure proxies to send trace spans to them automatically. See Zipkin, Jaeger and Lightstep task docs about how Istio works with those tracing systems.

Authentication works on crictl, when I use --creds

$ sudo crictl pull --creds "evancarroll:$TOKEN" docker.io/alpine:3

But when I try the same command ctr, I get an error:

$ sudo ctr images pull --user "evancarroll:$TOKEN" docker.io/alpine:3
docker.io/alpine:3: resolving
INFO[0000] trying next host error="pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed" host=registry-1.docker.io
ctr: failed to resolve reference "docker.io/alpine:3": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

---

You can see the --http-dump --http-trace,

$ sudo ctr images pull --http-dump --http-trace --user "evancarroll:$TOKEN" docker.io/alpine:3
INFO[0000] HEAD /v2/alpine/manifests/3 HTTP/1.1
INFO[0000] Host: registry-1.docker.io
INFO[0000] Accept: application/vnd.docker.distribution.manifest.v2+json, application/vnd.docker.distribution.manifest.list.v2+json, application/vnd.oci.image.manifest.v1+json, application/vnd.oci.image.index.v1+json, */*
INFO[0000] User-Agent: containerd/v1.5.11-k3s2
INFO[0000]
docker.io/alpine:3: resolving      |--------------------------------------|
elapsed: 0.1 s      total:   0.0 B (0.0 B/s)
INFO[0000] HTTP/1.1 401 Unauthorized
INFO[0000] Content-Length: 149
INFO[0000] Content-Type: application/json
INFO[0000] Date: Wed, 15 Jun 2022 16:00:59 GMT
INFO[0000] Docker-Distribution-Api-Version: registry/2.0
INFO[0000] Strict-Transport-Security: max-age=31536000
INFO[0000] Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:alpine:pull"
INFO[0000]
INFO[0000] POST /token HTTP/1.1
INFO[0000] Host: auth.docker.io
INFO[0000] Content-Type: application/x-www-form-urlencoded; charset=utf-8
docker.io/alpine:3: resolving      |--------------------------------------|
elapsed: 0.2 s      total:   0.0 B (0.0 B/s)
INFO[0000] client_id=containerd-client&grant_type=password&password=HIDDEN&scope=repository%3Aalpine%3Apull&service=registry.docker.io&username=evancarrollHTTP/1.1 200 OK
INFO[0000] Transfer-Encoding: chunked
INFO[0000] Content-Type: application/json; charset=utf-8
INFO[0000] Date: Wed, 15 Jun 2022 16:00:59 GMT
INFO[0000] Strict-Transport-Security: max-age=31536000
INFO[0000] X-Trace-Id: 5da4dacdeb208ead79e15a59f83499b2
INFO[0000]
INFO[0000] 833
INFO[0000] {"access_token":"HIDDEN","scope":"","expires_in":300,"issued_at":"2022-06-15T16:00:59.464114622Z"}
INFO[0000]
INFO[0000] 0
INFO[0000]
INFO[0000] HEAD /v2/alpine/manifests/3 HTTP/1.1
INFO[0000] Host: registry-1.docker.io
INFO[0000] Accept: application/vnd.docker.distribution.manifest.v2+json, application/vnd.docker.distribution.manifest.list.v2+json, application/vnd.oci.image.manifest.v1+json, application/vnd.oci.image.index.v1+json, */*
INFO[0000] Authorization: Bearer HIDDEN
docker.io/alpine:3: resolving      |--------------------------------------|
elapsed: 0.3 s      total:   0.0 B (0.0 B/s)
INFO[0000] HTTP/1.1 401 Unauthorized
INFO[0000] Content-Length: 149
INFO[0000] Content-Type: application/json
INFO[0000] Date: Wed, 15 Jun 2022 16:00:59 GMT
INFO[0000] Docker-Distribution-Api-Version: registry/2.0
INFO[0000] Strict-Transport-Security: max-age=31536000
INFO[0000] Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:alpine:pull",error="insufficient_scope"
INFO[0000]
INFO[0000] trying next host error="pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed" host=registry-1.docker.io
ctr: failed to resolve reference "docker.io/alpine:3": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

Configuration management tools like Ansible, Chef, Puppet, and Saltstack allows us to configure a cluster of blank machines to help install and deploy an application. For example, with Ansible, we can set up a cluster of newly provisioned compute servers to e.g. install a specific version of Go, edit O.S. properties, or modify the firewall.

Are these tools still needed in today's world where we have cloud providers that offer managed k8s, docker registries, and machine images for us? For example, on AWS:

• We can configure an OS environment manually once and save it as an AMI, then simply just use this AMI for the cluster. Alternatively, we can just use Fargate.
• The Docker image will contain all needed dependencies, and will also have an entrypoint to run the application itself.
• Managed k8s like EKS mean we don't have to worry about setting up the control plane, and updating the cluster is as simple as issuing a kubectl command to the control plane.

Assuming one uses EKS + ECR + something like Terraform to provision the resources, what value would Ansible, Chef, etc. provide? Why would we want to include them into our stack? Or does modern cloud services make them unneccesary?

My question is inspired from https://medium.com/geekculture/how-to-deploy-the-kubernetes-application-to-aws-eks-using-terraform-and-ansible-7679a3a207a8 , which recommends using EKS + Terraform + Ansible... but the Ansible playbook is just 2 kubectl commands that can just be replaced by a shellscript, right? Why introduce an entirely new technology in our stack?

I'm setting up an EKS cluster using https://github.com/ManagedKube/kubernetes-ops

and, based on that code, when I do a terraform apply I'm getting a NodeCreationFailure error.

Specifically:

│ Error: error waiting for EKS Node Group (staging:staging-ng12022040211190144860000000d) to create: unexpected state 'CREATE_FAILED', wanted target 'ACTIVE'. last error: 1 error occurred:
│   * i-0d5c42031eaf061ff, i-0d9a073240fd29c45: NodeCreationFailure: Instances failed to join the kubernetes cluster

Admittedly, that's not much code, but does anyone have any pointers on where to start debugging?

I think that you forgot '.'(dot)

docker build -f $DOCKERFILE_BUILD . 

(In my case) Even with this command, I got the error ...

I love having them around me, but after 1 hour, their jiggling gets old very quick, and now I want to mute them, is this possible?

https://minecraft.fandom.com/wiki/Allay

Yes, you can play with your friends who bought the game ages ago.

The base game itself became free some years ago. Since then, it's like you bought the game "Starcraft II: Wings of Liberty".

Upon account creation, StarCraft II includes the following:

• The complete Wings of Liberty campaign
• Full use of Raynor, Kerrigan, and Artanis Co-Op Commanders, with all others available for free up to level five
• Full access to custom games, including all races, AI difficulties, and maps
• Unranked multiplayer, with access to Ranked granted after the first 10 wins of the day in Unranked or Versus A.I

Once you reach level 10 with a Commander, level 15 with a race, or make any purchase, you can also access public chat channels, and join or create Clans and Groups. Making any purchase also grants the ability to publish custom maps.

See also https://us.battle.net/support/en/article/27568 .

As described, this includes custom games and unranked/ranked(after 10 unranked) games. It doesn't matter if your friend is in the same LAN or anywhere else as SC2 does not support local-only multiplayer. You need a internet connection to join/make games.

Also, as far as I know you can play content from the expansions (Heart of the swarm and Legacy of the void) if your friend owns them [citation needed].