home.social

#knativeserving — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #knativeserving, aggregated by home.social.

  1. I have to admit I’ve been looking for a problem to solve with #serverless as an excuse to use #KnativeServing or maybe #fission at work.

    At work, as part of infra ops we have a handful of webhooks and controllers that could be a function.

    I normally talk myself out of it because of the perceived complexity of ingress.

    My intangible line of thinking is if that tool is there it would be reached for more often for adhoc Jenkins jobs, crons, potentially webhooks.

  2. I have to admit I’ve been looking for a problem to solve with #serverless as an excuse to use #KnativeServing or maybe #fission at work.

    At work, as part of infra ops we have a handful of webhooks and controllers that could be a function.

    I normally talk myself out of it because of the perceived complexity of ingress.

    My intangible line of thinking is if that tool is there it would be reached for more often for adhoc Jenkins jobs, crons, potentially webhooks.

  3. I have to admit I’ve been looking for a problem to solve with #serverless as an excuse to use #KnativeServing or maybe #fission at work.

    At work, as part of infra ops we have a handful of webhooks and controllers that could be a function.

    I normally talk myself out of it because of the perceived complexity of ingress.

    My intangible line of thinking is if that tool is there it would be reached for more often for adhoc Jenkins jobs, crons, potentially webhooks.

  4. Currently trying to get #knative in my homelab going. Stumbling into issues with getting kourier running. Somehow the envoy keep crashing due to now reachable upstreams. Using the knative operator for getting the knative-serving up an running. Does someone else ran into the same issue?

    config-wise its pretty easy currently
    ```
    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
    name: knative-serving
    spec:
    ingress:
    kourier:
    enabled: true
    service-type: "ClusterIP"
    ```

    tags for visibility: #kubernetes #knative #KnativeServing

  5. Currently trying to get #knative in my homelab going. Stumbling into issues with getting kourier running. Somehow the envoy keep crashing due to now reachable upstreams. Using the knative operator for getting the knative-serving up an running. Does someone else ran into the same issue?

    config-wise its pretty easy currently
    ```
    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
    name: knative-serving
    spec:
    ingress:
    kourier:
    enabled: true
    service-type: "ClusterIP"
    ```

    tags for visibility: #kubernetes #knative #KnativeServing

  6. Currently trying to get in my homelab going. Stumbling into issues with getting kourier running. Somehow the envoy keep crashing due to now reachable upstreams. Using the knative operator for getting the knative-serving up an running. Does someone else ran into the same issue?

    config-wise its pretty easy currently
    ```
    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
    name: knative-serving
    spec:
    ingress:
    kourier:
    enabled: true
    service-type: "ClusterIP"
    ```

    tags for visibility:

  7. Currently trying to get #knative in my homelab going. Stumbling into issues with getting kourier running. Somehow the envoy keep crashing due to now reachable upstreams. Using the knative operator for getting the knative-serving up an running. Does someone else ran into the same issue?

    config-wise its pretty easy currently
    ```
    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
    name: knative-serving
    spec:
    ingress:
    kourier:
    enabled: true
    service-type: "ClusterIP"
    ```

    tags for visibility: #kubernetes #knative #KnativeServing

  8. Currently trying to get #knative in my homelab going. Stumbling into issues with getting kourier running. Somehow the envoy keep crashing due to now reachable upstreams. Using the knative operator for getting the knative-serving up an running. Does someone else ran into the same issue?

    config-wise its pretty easy currently
    ```
    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
    name: knative-serving
    spec:
    ingress:
    kourier:
    enabled: true
    service-type: "ClusterIP"
    ```

    tags for visibility: #kubernetes #knative #KnativeServing

  9. Played with #Knative on #Kubernetes today, it's pretty nifty

    I used `oha` to stress-test a basic health-check service, and it's cool that #KnativeServing can scale from 0 service pods, to 1 pod, and eventually up to 10 pods, all without dropping any requests (the requests are queued if there aren't enough service pods)

    It's like having my very own AWS Lambda at home (and honestly easier for me to use than AWS Lambda)

    These are the results for running `oha -c 1000 -z 30sec` against my cluster which has 3x Raspberry Pi 4B nodes (all nodes are control-plane nodes but with pod-scheduling enabled):

    ```
    Summary:
    Success rate: 1.0000
    Total: 30.0055 secs
    Slowest: 6.2945 secs
    Fastest: 0.0264 secs
    Average: 0.5445 secs
    Requests/sec: 1793.4723

    Total data: 0 B
    Size/request: 0 B
    Size/sec: 0 B

    Response time histogram:
    0.146 [2198] |■■■■
    0.292 [10205] |■■■■■■■■■■■■■■■■■■■■■■
    0.438 [14373] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
    0.584 [9585] |■■■■■■■■■■■■■■■■■■■■■
    0.731 [10099] |■■■■■■■■■■■■■■■■■■■■■■
    0.877 [4081] |■■■■■■■■■
    1.023 [1561] |■■■
    1.169 [495] |■
    1.315 [257] |
    1.461 [140] |
    1.607 [820] |■
    ```

  10. Played with #Knative on #Kubernetes today, it's pretty nifty

    I used `oha` to stress-test a basic health-check service, and it's cool that #KnativeServing can scale from 0 service pods, to 1 pod, and eventually up to 10 pods, all without dropping any requests (the requests are queued if there aren't enough service pods)

    It's like having my very own AWS Lambda at home (and honestly easier for me to use than AWS Lambda)

    These are the results for running `oha -c 1000 -z 30sec` against my cluster which has 3x Raspberry Pi 4B nodes (all nodes are control-plane nodes but with pod-scheduling enabled):

    ```
    Summary:
    Success rate: 1.0000
    Total: 30.0055 secs
    Slowest: 6.2945 secs
    Fastest: 0.0264 secs
    Average: 0.5445 secs
    Requests/sec: 1793.4723

    Total data: 0 B
    Size/request: 0 B
    Size/sec: 0 B

    Response time histogram:
    0.146 [2198] |■■■■
    0.292 [10205] |■■■■■■■■■■■■■■■■■■■■■■
    0.438 [14373] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
    0.584 [9585] |■■■■■■■■■■■■■■■■■■■■■
    0.731 [10099] |■■■■■■■■■■■■■■■■■■■■■■
    0.877 [4081] |■■■■■■■■■
    1.023 [1561] |■■■
    1.169 [495] |■
    1.315 [257] |
    1.461 [140] |
    1.607 [820] |■
    ```